[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170518022415.ygonweucssnxmazg@schmorp.de>
Date: Thu, 18 May 2017 04:24:15 +0200
From: Marc Lehmann <schmorp@...morp.de>
To: "Jason A. Donenfeld" <Jason@...c4.com>
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 Wed, May 17, 2017 at 01:41:32PM +0200, "Jason A. Donenfeld" <Jason@...c4.com> wrote:
> This email thread concerns my request to Marc to include the attached
> patch inside rxvt-unicode upstream. My own downstream -- Gentoo's
> jer@, also CCd -- won't include the patch until the agreement of
> upstream. Thus, it's important we come to a good conclusion.
I don't think we will include this patch upstream.
> On Wed, May 17, 2017 at 3:17 AM, Marc Lehmann <schmorp@...morp.de> wrote:
> This patch was part of a larger discussion on which you were CCd from
> distros. It seems possible that either those messages didn't make it
> to you, or you didn't have time to read them.
I only received a single message.
> In any case, the attached patch would be a useful defense in depth
> measure to prevent future integer overflow bugs, such as the one that
> was recently found in rxvt.
I am not convinced it is.
> Briefly looking though the code, it seems
> like there is a considerable amount of unchecked integer arithmetic,
> often passing between several functions in several files.
Likely, yes.
> somehow auditing every arithmetic call path, a considerable
> undertaking, Alexander and I would recommend simply limiting the range
> of input from users.
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.
> As Alexander wrote in a recent email to you, the general opinion of
> this list is that terminal emulators should not support the most
> dangerous uses of escape sequences, even if they're technically valid.
> The attached patch falls into that category.
I can't see why this patch somehow "unsupports" the most dangerous uses of
escape sequences.
> You seem to have made the
> argument that the patch "might break valid uses".
The parameter range is severely limited. This makes the patch rather
disadvantageous, without any demonstrated benefit.
> you a bit of the backstory and recent basis which motivates this
> patch. If this is compelling, I'd rest well knowing it's accepted
> upstream. If this is not compelling, could you indicate to the list
> why "might break valid uses" outweighs the potential security
> mitigations?
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.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@...morp.de
-=====/_/_//_/\_,_/ /_/\_\
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.
