Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1801405 (CVE-2020-9366) - CVE-2020-9366 screen: Out of bounds access when setting w_xtermosc after OSC 49
Summary: CVE-2020-9366 screen: Out of bounds access when setting w_xtermosc after OSC 49
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2020-9366
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1801406 1801408
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-02-10 19:57 UTC by Pedro Sampaio
Modified: 2021-02-16 20:36 UTC (History)
5 users (show)

Fixed In Version: screen 4.8.1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-02-24 15:50:01 UTC
Embargoed:


Attachments (Terms of Use)

Description Pedro Sampaio 2020-02-10 19:57:15 UTC
A flaw was found in screen before version 4.8.0. A out of bounds access in when using OSC 49 might end up in a big sized overwrite of memory. 

References:

https://www.openwall.com/lists/oss-security/2020/02/06/3

Comment 1 Pedro Sampaio 2020-02-10 19:57:51 UTC
Created screen tracking bugs for this issue:

Affects: epel-8 [bug 1801408]
Affects: fedora-all [bug 1801406]

Comment 2 Vaclav Dolezal 2020-02-11 16:28:15 UTC
Now I noticed I can't reproduce this issue on el7. Looking for culprits, I found commit https://git.savannah.gnu.org/cgit/screen.git/commit/?h=screen-v4&id=c5db181b6e017cfccb8d7842ce140e59294d9f62 (note the deletion of "--typ2"). This commit comes after screen v2.6.2 so only screen version 2.7.0 is affected. I can't reproduce this issue on f31 either.

Comment 3 Vaclav Dolezal 2020-02-19 12:43:51 UTC
re comment #2:
I meant versions v4.6.2 and v4.7.0, of course.

@psampaio
Since I didn't find any of the active package versions vulnerable, I cancelled the updates.
Unless you have some objections, I'll mark these bugs as CLOSED NOTABUG.

Comment 4 Pedro Sampaio 2020-02-20 22:07:20 UTC
In reply to comment #3:
> re comment #2:
> I meant versions v4.6.2 and v4.7.0, of course.
> 
> @psampaio
> Since I didn't find any of the active package versions vulnerable, I
> cancelled the updates.
> Unless you have some objections, I'll mark these bugs as CLOSED NOTABUG.

If you mean bugs 1801406 and 1801406, yeah sure, I have no objections.

Comment 5 Cedric Buissart 2020-02-21 07:33:28 UTC
Hi Vaclav,
per upstream, "This issue is present at least since v.4.2.0", so the commit you point may not be the culprit

Comment 6 Vaclav Dolezal 2020-02-21 10:00:19 UTC
Hi Cedric,
yes, I saw that comment, but
  - I was able to reproduce this issue in v.4.7.0 only
  - the commit I pointed to (c5db181) expands required size of w_xtermosc by 1, which is what the fixing commit (68386df) does

I have sent a mail to the upstream list, but I haven't received any reply yet.

Huh, now, reviewing c5db181, I noticed that d_xtermosc also needs to be expanded. (Luckily this doesn't seem serious.)

Comment 7 Cedric Buissart 2020-02-24 15:10:55 UTC
Yes, after looking at it, I think I would agree with you : at least as shipped in RHEL7, I dont see it impacted. c5db181 seems to be the first vulnerable commit.
Thx!

Comment 8 Cedric Buissart 2020-02-24 15:15:22 UTC
Statement:

It is believed that the vulnerability was caused by upstream commit c5db181. GNU screen versions prior to 4.7.0 do not seem to be impacted.

Comment 11 Cedric Buissart 2020-02-26 12:40:49 UTC
Fixed version & list of upstream fixes corrected per https://www.openwall.com/lists/oss-security/2020/02/25/7


Note You need to log in before you can comment on or make changes to this bug.