+++ This bug was initially created as a clone of Bug #196094 +++ +++ This bug was initially created as a clone of Bug #195555 +++ From: Marcus Meissner Subject: [vendor-sec] setuid security problems in X Hi, 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(g etuid()); 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 ac tual/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 Since we ship Xorg setuid it's possible, without futher examination that we've not done, that this could lead to privilege escalation. If so this calls for an immediate async Xorg advisory across all affected products and we'd need packages in the next couple of days to meet the goal of having this fixed within a week. ------------------------------------------------------------------------ The patches can be found in this mail: http://lists.freedesktop.org/archives/xorg/2006-June/016146.html
[From bug 195555] Comment #6 From Josh Bressers (Security Response Team) (bressers) on 2006-06-22 14:00 EST [reply] Private This is not a secuirty issue. It turns out the places that the setuid is used are not controlable by an attacker. The upstream advisory mentions unchecked suid usage in several places. We only ship the Xorg executable suid root, which is the only potentially vulnerable program. Here is a listing of the bad setuid() calls (provided by Marcus Meissner of Suse). The analysis was done by me. ./programs/Xserver/hw/xfree86/common/xf86Init.c: setuid(getuid()); After this "sh -c "vtinit"" is called, which might be exploitable. We don't enable the vtinit command by default, nor would I expect anybody to be using this configuration option. Even if this ran as root it will rely on a very insecure and poor configuration file option. ./programs/Xserver/hw/xfree86/parser/write.c: setuid(getuid()); Could corrupt any file on the system, like /etc/shadow. Only when Xorg is run as root can this codepath be reached; the setuid is a bit silly. ./programs/Xserver/hw/xfree86/os-support/shared/libc_wrapper.c: setuid(getuid()); In xf86execl(), which I do not know who calls it. (There are #define execl xf86execl in some files.) All calls to execl (that are dangerous) are preceded by a setuid call. They are the xf86Init.c call above, and the utils.c calls below. ./programs/Xserver/os/utils.c: setuid(getuid()); ./programs/Xserver/os/utils.c: setuid(getuid()); ./programs/Xserver/os/utils.c: setuid(getuid()); These are in Popen(), Fopen(), System(). The calls to Fopen should be safe. The server uses seteuid if it's there, otherwise it will fall back on setuid. (seteuid() is not vulnerable to this problem) The calls to Popen and System are used by the keyboard map loading bits of X. There is no way for a user to specify a keyboard file (There is a -kkbdb option which does nothing). I can specify an existing keyboard map (-kbmap), but the keymap file is verified and loaded long before the suid call happens.
Here is the list of package which have been updated and/or rebuilt for FC5 to pick up the setuid bugfixes: xorg-x11-xtrans-devel-1.0.0-3.2.FC5.0 libX11-1.0.0-3.FC5.0 xorg-x11-server-1.0.1-9.FC5.4 xorg-x11-xdm-1.0.1-2 xorg-x11-xfs-1.0.1-4.FC5.0 xorg-x11-xinit-1.0.1-2.FC5.0 xorg-x11-apps-7.0-1 These will be released as an aggregated bugfix release for FC5. While this issue was originally filed as a potential security issue, a close analysis of the code in question by the Red Hat security team seem to indicate that it is not vulnerable to attack, and as such the issue has been downgraded from "security" to "bugfix" severity.
xorg-x11-xtrans-devel-1.0.0-3.2.FC5.0 libX11-1.0.0-3.FC5.0 xorg-x11-server-1.0.1-9.FC5.4 xorg-x11-xdm-1.0.1-2 xorg-x11-xfs-1.0.1-4.FC5.0 xorg-x11-xinit-1.0.1-2.FC5.0 xorg-x11-apps-7.0-1 has been pushed for fc5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.