Hi From my morning reading of bugtraq: Date: Thu, 27 Nov 2003 03:29:05 +0200 From: Timo Sirainen <tss@iki.fi> To: bugtraq@securityfocus.com Subject: GNU screen buffer overflow Summary ------- Buffer overflow in GNU screen allows privilege escalation for local users. Usually screen is installed either setgid-utmp or setuid-root. It also has some potential for remote attacks or getting control of another user's screen. The problem is that you have to transfer around 2-3 gigabytes of data to user's screen to exploit this vulnerability. 4.0.1, 3.9.15 and older versions are vulnerable. Details ------- ansi.c: case '0': case '1': case '2': case '3': case '4': case '5': case '6': case '7': case '8': case '9': if (curr->w_NumArgs < MAXARGS) { if (curr->w_args[curr->w_NumArgs] < 100000000) curr->w_args[curr->w_NumArgs] = 10 * curr->w_args[curr->w_NumArgs] + (c - '0'); } break; case ';': case ':': curr->w_NumArgs++; break; w_NumArgs is signed integer, so after you've sent 2GB of ';' characters in escape sequence it wraps to negative and the < MAXARGS protection fails. Then it's only a matter of finding a position in memory where the next if check passes and does something useful. I would guess there are multiple such possibilities, but I didn't try to find any. Window sizes ------------ I didn't really check this, but the code looked like there could be some problems with large window sizes (eg. ESC[100000;100000t). Vendor status ------------- Sent a mail to screen@uni-erlangen.de (16.10), no reply. Sent a mail to screen mailing list (24.10), didn't help much. Patch ----- --- ansi.c.old 2003-11-15 18:04:12.000000000 +0200 +++ ansi.c 2003-11-15 18:04:51.000000000 +0200 @@ -559,7 +559,7 @@ { case '0': case '1': case '2': case '3': case '4': case '5': case '6': case '7': case '8': case '9': - if (curr->w_NumArgs < MAXARGS) + if (curr->w_NumArgs >= 0 && curr->w_NumArgs < MAXARGS) { if (curr->w_args[curr->w_NumArgs] < 100000000) curr->w_args[curr->w_NumArgs] = --- resize.c.old 2003-11-27 02:55:07.000000000 +0200 +++ resize.c 2003-11-27 02:58:33.000000000 +0200 @@ -682,6 +682,17 @@ if (wi == 0) he = hi = 0; + if (wi > 1000) + { + Msg(0, "Window width too large, truncated"); + wi = 1000; + } + if (he > 1000) + { + Msg(0, "Window height too large, truncated"); + he = 1000; + } + if (p->w_width == wi && p->w_height == he && p->w_histheight == hi) { debug("ChangeWindowSize: No change.\n"); Reproducible: Always Steps to Reproduce:
The patch should be fine!
screen on Gentoo does not install setuid/setgid by default which should reduce the impact of the bug effecting us, however as it's good idea to have a sane userland as and some users will want take advantage of multi-user mode I added the patch and bumped screen to 4.0.1-r1. Please test.
~arh keywords so ACCEPT_KEYWRODS="~x86" emerge -pv '>=app-misc/screen-4.0.1-r1'
lets try this again.. :) ~arch keywords so ACCEPT_KEYWORDS="~x86" emerge -pv '>=app-misc/screen-4.0.1-r1'
screen marked stable on x86, sparc team is testing and marking stable on sparc. hppa already marked it as stable. waiting on ppc team before package masking.
app-misc/screen-4.0.1-r1 works fine here. Portage 2.0.49-r18 (default-ppc-1.4, gcc-3.2.3, glibc-2.3.2-r3, 2.4.22-ben2) ================================================================= System uname: 2.4.22-ben2 ppc Gentoo Base System version 1.4.3.12 ACCEPT_KEYWORDS="ppc ~ppc" AUTOCLEAN="yes" CFLAGS="-Os -pipe -mcpu=750" CHOST="powerpc-unknown-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-Os -pipe -mcpu=750" DISTDIR="/usr/portage/distfiles" FEATURES="ccache" GENTOO_MIRRORS="ftp://gentoo.linux.no/pub/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://192.168.3.3/gentoo-portage" USE="X aalib acl alsa apache2 apm arts artswrappersuid berkdb crypt cups curl dga directfb encode esd ethereal faad fbcon ffmpeg flac foomaticdb gd gdbm gif gnome gtk gtk2 imagemagick imap imlib imlib2 java javascript joystick jpeg kde kerberos lcd lcms ldap libwww mad maildir matroska mbox mdb mikmod mitshm motif mozsvg mpeg mysql ncurses nls offensive oggvorbis opengl oss pam pcap pdflib perl pic png postgres ppc ppds python qt quicktime rage128 readline samba sdl slang spell ssl tcltk tcpd tetex tiff transcode truetype unicode usb xfs xml2 xmms xosd xv xvid zlib"
Ive been using -r1 for the last weeks so yes, seems to work fine. I dont know much about this gentoo bugtracking system, should I (the requestor) close it or should I always leave that to the gentoo team ?
Mihai, Thank you for your enthusiasm in into the process of our bug tracking system. It's usually ideal for our team to close such bugs, more so in the case of security ones. As of right now this bug is remaining open as it has uncovered another bug possible in chown(1) and the preservation of file permissions that is under investigation currently. -- Re on my comment #2 <-- I was very badly mistaken here. screen does install setgid. The reason I drew this conclusion was by reading the misleading informational comments about the the setuid bits in the post install section of the ebuild.
see bug 35785 for tracking of the chown issue. is screen ready for a glsa? (i do not think all archs have updated/tested.)
all supported arches have tested and verified.
What about a GLSA as Debian now bumped out an advisory?
No GLSA sent. Silent Vendor fix. :) No seriously we lack the resources to send out every GLSA that should be sent. If anybody dislikes this then join the security team and help out.
IMO every 'major' package in at least stable should get a GLSA if a security problem is spotted and fixed. Where should be a sense of GLSA in general if it's that incomplete. I saw almost no GLSA recently. And it should be published on a website like just every other vendor does. (Should be easy with XML anyway!?) Just my few thoughts.
Please try out http://dev.gentoo.org/~plasmaroo/glsa-test and paste the XML in here :-)
Please use the Attachment feature of bugzilla vs pasting inline.
What's a 'GLSA keyword'?
Not really sure either: the DTD says a "keyword for the issue"; if it is an ebuild it would be the product name, e.g. "OpenSSL".
GNU screen then. Warning: fopen(/home/plasmaroo/public_html/glsa-test/pool/5dbe02f45d8e59eb5ec4d46e1a638638.xml): failed to open stream: Permission denied in /home/plasmaroo/public_html/glsa-test/includes/io.filegrepper on line 222 on 'Submit'... Interessting ;) Ok. Attached.
Created attachment 24548 [details] GLSA for GNU screen
Okay, we have a GLSA ready, but it still hasn't gone anywhere... really, this should go out ASAP, if possible, shouldn't it?
Would someone remove the affected versions (4.0.1 and earlier) so we can close this bug? Thanks.
Done.
Vulnerable versions removed, bug closed.
