| Summary: | {x11-base/xorg-x11|x11-terms/xterm} Unchecked set*uid() calls | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Sune Kloppenborg Jeppesen (RETIRED) <jaervosz> | ||||||||
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||||||
| Status: | RESOLVED FIXED | ||||||||||
| Severity: | major | CC: | dberkholz, dickey, dickey, exg, seemant, tcort, welp | ||||||||
| Priority: | High | ||||||||||
| Version: | unspecified | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| URL: | http://lists.freedesktop.org/archives/xorg/2006-June/016146.html | ||||||||||
| Whiteboard: | A1 [glsa] DerCorny | ||||||||||
| Package list: | Runtime testing required: | --- | |||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 143647 | ||||||||||
| Attachments: |
|
||||||||||
heya spyderous, this is from v-s, please have a look and recommend what you would like to do here. From the looks of it, it's certainly real bugs. I'll leave the question of how exploitable they are to upstream. For reference, the upstream bug is https://bugs.freedesktop.org/show_bug.cgi?id=7116 although none of you will have access to it. =) There have been no comments on it since June 5, but it does contain patches. Setting it to upstream until we have the patches. Created attachment 89172 [details, diff]
Most of modular
Created attachment 89173 [details, diff]
libX11
Note, the modular patches lack the patches against xterm. But they are in the monolith patch.
Created attachment 89174 [details, diff]
Monolith 6.9
With luck, will apply to 6.8 as well. Can pull xterm diff out of here.
btw, exg should probably be on here as xterm maintainer. Adding Emanuele. @Thomas: could you post a mail to vendor-sec saying when you will announce the new version (and give access to it so that vendors have a bit of time to prepare a package?) Alternatively you can let me know and I'll forward the information. Recommend no GLSA. From the advisory: "This can be used by a malicious local user to overwrite files and possibly elevate privileges in some corner cases." hmm, I'm not sure what you're trying to point out spyderous, I've seen a demonstration of an unprivileged user trashing /etc/shadow via X -configure, which certainly merits a GLSA, imho. Eh, whatever makes you happy. Link to advisory: http://lists.freedesktop.org/archives/xorg/2006-June/016146.html Ebuilds in portage for all issues now, with the exception of xterm because I don't maintain it. xorg-x11-6.8.2-r8 will require stabling on all arches, the rest were ~arch before. Complete list of "safe" versions: >=libX11-1.0.1-r1 >=xdm-1.0.4-r1 >=xf86dga-1.0.1-r1 >=xinit-1.0.2-r6 >=xload-1.0.1-r1 && ( >=xorg-server-1.0.2-r6 <xorg-server-1.1 ) >=xorg-server-1.1.0-r1 >=xtrans-1.0.0-r1 && ( >=xorg-x11-6.8.2-r8 <xorg-x11-6.9 ) >=xorg-x11-6.9.0-r2 xterm-215, which is fixed wrt the issue, is in the tree now. Opening since this is public now. Arches please test and mark stable. To clarify, xorg-x11-6.8.2-r8 and xterm-215 need stabling. sparc stable. xterm is stable..however xorg has at least one depend that needs to go first. x11-base/xorg-x11/xorg-x11-6.8.2-r8.ebuild: x86(hardened/x86) ['x11-misc/linuxwacom'] please advise. didn't mean to remove x86 ^.^;; The hardened/x86 2.4 kernel profile is currently broken wrt X because of this issue. I recommend you temporarily remove it from your profiles.desc, as it was just added earlier this month. Work is in progress to fix this. I think I'd rather just fix the problem. Removing -input_devices_wacom from use.mask on the hardened profile solves the issue. xorg-x11-6.8.2-r8 stable on x86 That just masks the breakage, it will still be pulled in on INPUT_DEVICES="" because we don't have a way to do dep strings depending on kernel in profile. stable on ppc64 ppc stable Emanuele Giaquinta pointed this out to me (there's some problem with email from this bugzilla to radix.net, so I subscribed from his.com). Stable on hppa. Stable on amd64 xterm is stable on amd64, but i can't stablize xorg-x11 for some reason, repoman gives me a huge load of RDEPEND.bad errors for modular X on all arches. can someone else from amd64 give it a try please? *** Bug 138458 has been marked as a duplicate of this bug. *** (In reply to comment #27) > xterm is stable on amd64, but i can't stablize xorg-x11 for some reason, > repoman gives me a huge load of RDEPEND.bad errors for modular X on all arches. > can someone else from amd64 give it a try please? Run cvs up in the other directories you're getting errors from (probably x11-drivers), and profiles and eclass. FYI libX11 1.0.2 missed one of the security fixes, so please don't GLSA this until I release and add 1.0.3. (In reply to comment #27) > xterm is stable on amd64, but i can't stablize xorg-x11 for some reason, > repoman gives me a huge load of RDEPEND.bad errors for modular X on all arches. > can someone else from amd64 give it a try please? I didn't get any RDEPEND.bad errors. xorg-x11-6.8.2-r8 stable on amd64. alpha stable. Back to ebuild status awaiting libX11 1.0.3 xterm-215 is stable on mips, and I believe we're de-keywording 6.*, since 7.1 is stable for us. Leaving on CC until resolved. AFAICT libX11-1.0.3 is in, time to mark stable, I guess. What exactly it is you want arches to test and stabilize? I haven't been following this issue. libX11-1.0.3 and xproto-7.0.7 (dependency) stable on ppc64 x86 needs x11-proto/xproto-7.0.7 and x11-libs/libX11-1.0.3 1) both emerge fine 2) pass collision test 3) libX11 passes test suite 4) X starts with Gnome, KDE and XSession 5) and please change subjects to the desired packages or give a useful cc comment Portage 2.1-r1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.17-gentoo-r4 i686) ================================================================= System uname: 2.6.17-gentoo-r4 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.6.15 app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict test" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo/" LANG="de_DE@euro" LC_ALL="de_DE@euro" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.informatik.rwth-aachen.de/gentoo-portage" USE="x86 3dnow 3dnowext X Xaw3d a52 alsa arts artworkextra asf audiofile avi bash-completion beagle berkdb bidi bitmap-fonts bootsplash branding bzip2 cairo cdda cddb cdparanoia cdr cli cracklib crypt css cups curl custom-cflags dbus dga directfb divx4linux dlloader dri dts dvd dvdr dvdread dvi eds emacs emboss encode esd evo exif expat fam fat fbcon ffmpeg firefox foomaticdb fortran ftp gb gcj gdbm gif gnome gpm gstreamer gtk gtk2 gtkhtml hal icq idn imagemagick imap imlib ipv6 isdnlog java javascript jikes jpeg jpeg2k ldap leim libg++ libwww lm_sensors mad maildir matroska mbox mikmod mime mmx mmxext mng mono motif mp3 mpeg mpeg2 mule nautilus ncurses nforce2 nls nocardbus nptl nptlonly nsplugin nvidia objc ogg opengl pam pcre pdf pdflib perl plotutils pmu png ppds pppd preview-latex print python qt3 qt4 quicktime readline reflection reiserfs samba sdk session slang spell spl sse ssl svg svga t1lib tcltk tcpd theora thunderbird tiff truetype truetype-fonts type1-fonts udev usb vcd videos vorbis win32codecs wmf wxwindows xine xml xorg xosd xv xvid zlib elibc_glibc input_devices_mouse input_devices_keyboard kernel_linux linguas_de userland_GNU video_cards_radeon video_cards_vesa video_cards_fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS remove us from cc. damn. that was the wrong bug. Readded. libX11 1.0.1-r1 is fine, so is libX11 1.0.3 -- 1.0.3 has lots of changes though, so please test carefully if you're stabilizing. 1.0.1-r1 is already stable on amd64, as it's secure we're out (In reply to comment #42) > 1.0.1-r1 is already stable on amd64, as it's secure we're out Same for ppc. (In reply to comment #42) > 1.0.1-r1 is already stable on amd64, as it's secure we're out Same for alpha x86 stable and gone ^.^;; stable on hppa also. sparc is clean since we don't have modular stable yet. It would be helpful if you could say in the GLSA that it's actually been available and stable for most architectures since 30 June, and the release has just been held up. Thanks teams (In reply to comment #48) > It would be helpful if you could say in the GLSA that it's actually been > available and stable for most architectures since 30 June, and the release has > just been held up. mmm, we'll try to add that. Thanks. Accepting bug. GLSA 200608-25 |
Dirk Mueller and I have been checking for setuid/seteuid without return checks. One offender who is exploitable we think is X. Both X.Org and XFree86. For the readers who just joined a brief summary: In kernel 2.6 it is possible that setuid(user_uid); can fail even if done from root a process. Reason is that there is the maximum processes "ulimit" which is honoured by setuid(), seteuid(), set*uid(). If you do not check the return value and continue as-is you have not dropped the privilege, but run as root. An example of this has been released in "vixie-cron". Since ulimits on maximum processes are set by the kernel by default, any Linux 2.6 system is default affected. Fix: Check the return value of setuid() and handle it and/or check with getuid() right after the setuid() if it worked. My evaluation might be off and it might not be exploitable in these places. If this is exploitable I would propose an embargo of 2 weeks. (Tue June 20th 12:00 UTC would be a nice date) Critical MUST FIX problems: ./programs/Xserver/hw/xfree86/common/xf86Init.c: setuid(getuid()); Security relevant and critical. After this "sh -c "vtinit"" is called, which might be exploitable. (SUSE has the X Server setuid root, so this would affect us.) ./programs/Xserver/hw/xfree86/parser/write.c: setuid(getuid()); Security relevant and critical. Can corrupt any file on the system, like /etc/shadow. (I think via: Xorg -configure --... /etc/shadow) ./programs/Xserver/hw/xfree86/os-support/shared/libc_wrapper.c: setuid(getuid()); Security relevant and critical. In xf86execl(), which I do not know who calls it. ./programs/Xserver/os/utils.c: setuid(getuid()); ./programs/Xserver/os/utils.c: setuid(getuid()); ./programs/Xserver/os/utils.c: setuid(getuid()); Security relevant and critical. These are in Popen(), Fopen(), System(). Leak file content, start called programs as root. All of them above are in the XServer. Normal problems, but should be fixed probably: ./lib/X11/lcFile.c: if (seteuid(0) != 0) { ./lib/X11/lcFile.c: seteuid(oldeuid); Obscure. ./lib/xtrans/Xtranslcl.c: setuid( getuid() ); /** sets the euid to the actual/real uid **/ Obscure, not used in modern systems. ./config/util/chownxterm.c: setuid(getuid()); ./config/util/chownxterm.c: setuid(getuid()); No setuid/setgid xterm used, we have utempter and devpts. ./programs/xdm/session.c: setuid (verify.uid); This needs to be fixed, but is not security critical. It is called before the KRB5 tickets are dropped and the user auth is removed. ./programs/xdm/xdmshell.c: setuid (geteuid()); Should be fixed. In common use scenarios it is not setuid-root, so not critical. ./programs/xinit/xinit.c: setuid(getuid()); Security relevant. Must be fixed. This is critical when xinit is setuid-root, but I do not know if anyone has it so. ./programs/xload/xload.c: setuid(getuid()); Security relevant. No one ships xload setuid root anymore, but it should be fixed. ./programs/xterm/main.c: seteuid(getuid()); ./programs/xterm/main.c: setuid(getuid()); ./programs/xterm/main.c: seteuid(getuid()); ./programs/xterm/main.c: setuid(getuid()); ./programs/xterm/main.c: seteuid(0); ./programs/xterm/main.c: seteuid(getuid()); ./programs/xterm/main.c: setuid(screen->uid); ./programs/xterm/main.c: if (setuid(screen->uid)) { ./programs/xterm/misc.c: setuid(uid); ./programs/xterm/misc.c: setuid(screen->uid); ./programs/xterm/os2main.c: setuid(screen->uid); ./programs/xterm/os2main.c: setuid(screen->uid); ./programs/xterm/print.c: setuid(screen->uid); No one ships xterm setuid root anymore, but it should be fixed for those who do. ./programs/xf86dga/dga.c: setuid(getuid()); The old DGA binary, not shipped setuid root at SUSE. It does not do much exploitable afterwards, but it usually destroys your X session anyway, so it is better to not run it. Ciao, Marcus