Bug 195555
Summary: | Potential X insecure suid calls | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Josh Bressers <bressers> |
Component: | xorg-x11 | Assignee: | Adam Jackson <ajax> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.0 | CC: | matthieu.herrb, sandmann, security-response-team, xgl-maint, zcerza |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | RHBA-2007-0317 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-05-01 17:33:53 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: | |||
Bug Blocks: | 176344 |
Description
Josh Bressers
2006-06-15 18:52:48 UTC
This issue does not affect RHEL2 or RHEL3. It should only affect RHEL4 and FC. I've not done any investigation if actual damage can be done with this issue. I don't understand the working of X well enough to say for sure. Taking ownership. We need to have bug reports for each OS release we need to do an update for. Right now, that looks like: - RHEL-4 - Fedora Core 4 - Fedora Core 5 - Fedora devel Is there a CVS for this issue? I couldn't find one online. Before we file bug reports for other releases we need to understand if this is actually an X secuirty issue. Nobody has done an actual analysis of attack vectors for this problem. The patches can be found in this mail: http://lists.freedesktop.org/archives/xorg/2006-June/016146.html 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. I can confirm this analysis. Unfortunatly it came after X.Org released its advisory. The only real world case where this is exploitable is the vtinit case, but it appears that no Linux system uses the 'vtinit' configuration option to run a program. However, OpenBSD developpers have brought to my attention that a systrace policy (and probably a SELinux policy or Solaris's DTrace) can make setuid() fail too for reasons other than process ulimit, so the checks are good to have anyways in case someone does something silly. In cvs. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0317.html |