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.
Created screen tracking bugs for this issue:
Affects: epel-8 [bug 1801408]
Affects: fedora-all [bug 1801406]
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.
re comment #2:
I meant versions v4.6.2 and v4.7.0, of course.
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.
In reply to comment #3:
> re comment #2:
> I meant versions v4.6.2 and v4.7.0, of course.
> 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.
per upstream, "This issue is present at least since v.4.2.0", so the commit you point may not be the culprit
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.)
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.
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.
upstream fixes :
Fixed version & list of upstream fixes corrected per https://www.openwall.com/lists/oss-security/2020/02/25/7