Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 18 May 2017 11:31:13 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Marc Lehmann <schmorp@...morp.de>
Cc: oss-security <oss-security@...ts.openwall.com>, rxvt-unicode@...morp.de, 
	"jer@...too.org" <jer@...too.org>
Subject: Re: Defense in depth patch for rxvt-unicode

On Thu, May 18, 2017 at 4:24 AM, Marc Lehmann <schmorp@...morp.de> wrote:
> This sounds big, but I don't quite see the patch achieving that, as input is
> processed at many places, yet the patch only changes one place.

The intent was to limit the bounds on the number at the very beginning
of the call chain. I believe this patch does that, but if I've missed
additional entry points, please let me know, and I'll roll another
revision of the same technique.

> I can't see why this patch somehow "unsupports" the most dangerous uses of
> escape sequences.

It prevents potential integer overflows during subsequent additions or
multiplications. The range in the patch was chosen to be especially
forgiving in that regard.

> The parameter range is severely limited. This makes the patch rather
> disadvantageous, without any demonstrated benefit.

Could you list a valid use for a range larger than that?


> Valid uses outweigh "potential security mitigations" simply because
> "potential security mitigations" is pretty weightless in itself.
>
> If you are aware of an actual security problem, that would be something to
> attack.

That's not quite how "defense in depth" works.

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ