[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKG8Do5sO4b9qVzU=zTFF52fDRNNvtoCknnNoPBmd1VRGgnfvA@mail.gmail.com>
Date: Tue, 25 Feb 2020 08:12:26 +0100
From: Cedric Buissart <cbuissar@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: Re: GNU screen "out of bounds access when setting
w_xtermosc after OSC 49"
On Mon, Feb 24, 2020 at 2:27 PM Cedric Buissart <cbuissar@...hat.com> wrote:
>
> Hi all,
>
> On Thu, Feb 6, 2020 at 5:55 PM Amadeusz Sławiński <amade@...blr.net> wrote:
> >
> > Hi,
> >
> > >
> > > The fix commit is:
> > >
> > > ---
> > > commit 68386dfb1fa33471372a8cd2e74686758a2f527b
> > > Author: Amadeusz Slawinski <amade@...blr.net>
> > > Date: Thu Jan 30 17:56:27 2020 +0100
> > >
> > > Fix out of bounds access when setting w_xtermosc after OSC 49
> > >
> > > echo -e "\e]49\e; \n\ec"
> > > crashes screen.
> > >
> > > This happens because 49 is divided by 10 and used as table index
> > > resulting in access to w_xtermosc[4], which is out of bounds with table
> > > itself being size 4. Increase size of table by 1 to 5, which is enough
> > > for all current uses.
> > >
> > > As this overwrites memory based on user input it is potential security
> > > issue.
> > >
> > > Reported-by: pippin@...p.org
> > > Signed-off-by: Amadeusz Slawinski <amade@...blr.net>
> > > ---
> > >
> > > This is followed by another related commit:
> > >
> > > ---
> > > commit 0dd53533e20d2948351a99ec5336fbc9b82b226a
> > > Author: Amadeusz Slawinski <amade@...blr.net>
> > > Date: Wed Feb 5 21:05:28 2020 +0100
> > >
> > > Increase permitted length of OSC
> > >
> > > hyperlink feature used by some terminals requires lots of characters
> > > https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda#length-limits
> > > mentions around 2083 characters, set it to a bit more.
> > >
> > > Bug: 57718
> > >
> > > Signed-off-by: Amadeusz Slawinski <amade@...blr.net>
> > > ---
> > >
> > > Combined, these two commits change:
> > >
> > > char w_xtermosc[4][MAXSTR]; /* special xterm/rxvt escapes */
> > >
> > > (where MAXSTR is 768) to:
> > >
> > > char w_xtermosc[5][2560]; /* special xterm/rxvt escapes */
> > >
> >
> > The report which resulted in second commit just happened to be reported
> > at similar time and is not related to the issue at hand apart from same
> > location in source code.
> >
> > > These are as seen on the screen-v4 branch. On that branch, and thus in
> > > all screen releases so far, the bug appears to be exposed only when
> > > building with the "--enable-rxvt_osc" option. Builds and packages made
> > > without that option appear to be safe. Amadeusz, can you confirm this?
> >
> > Yes builds without this option should be safe, however do note that
> > as far as I know most distributions do enable it (I checked Debian,
> > Arch Linux, Fedora and Gentoo).
> >
> > >
> > > On master branch, the functionality is always enabled (and the option is
> > > dropped), thus (not too ancient) builds from that branch are vulnerable
> > > (until the above fixes, which were also made to that branch).
> >
> > Yes, however do note that all v4 releases are done from screen-v4 branch.
> Has a CVE been requested already ?
> I do not see one on cve.mitre.org
CVE-2020-9366 was assigned to this flaw via mitre.org
> >
> > Amadeusz
> >
>
>
> --
> Cedric Buissart,
> Product Security
--
Cedric Buissart,
Product Security
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.
