[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHmME9ra5WDz77HHzY3mQwRUoxeOUh5yVLxw1VD-SbeqOHafNg@mail.gmail.com>
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
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
