Bug 1801405 (CVE-2020-9366)

Summary: CVE-2020-9366 screen: Out of bounds access when setting w_xtermosc after OSC 49
Product: [Other] Security Response Reporter: Pedro Sampaio <psampaio>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: cbuissar, jridky, lnykryn, phracek, vdolezal
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: screen 4.8.1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-02-24 15:50:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1801406, 1801408    
Bug Blocks: 1801409    

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