alanc @ sun.com

X Changes in Nevada Build 36

Another two weeks, another list of fixes checked in. The one with the biggest share of attention is also the one with the smallest code change - two missing pairs of parentheses - four simple characters that closed one big security hole.

6387822 Wrong library path in xft.pc file

Simple fix to the pkg-config data file we ship for libXft2 so it produces the right library path flags for linking so that GNOME 2.14 builds correctly.

6383556 Problem in allocating pixmap

The last security fix in X servers added checks to both Xsun & Xorg to prevent pixmap allocations from overflowing. Unfortunately one of the checks in Xsun clamped down too far - preventing pixmaps with dimensions larger than 8192 instead of the intended 32k limit.

6390864 nevada removal of ddxSUNWdials

We bow our heads for SunButtons and SunDials - faithful servants of almost two decades, now sent to permanent retirement. The hardware for these hasn't been sold for several years now and the kernel driver for them was removed, so we had to remove the Xsun support as well. (The official end of support notice should appear in the Solaris 10 Update 2 release notes, warning of removal in the a future release - but we normally don't remove support in update releases, so users still attached to theirs can stay on Solaris 10 without fear.)

If you've never seen these they were additional input devices - SunButtons offered a big pad of extra buttons, like a jumbo set of keyboard function keys, and SunDials offered a bunch of knobs you could twist. These were accessed via the X Input Extension by software such as CAD programs for more efficient interaction with their features.

6368334 common postscript-derived font names are no longer recognized

An updated set of font aliases to fix some problems reported with the ones added in build 34.

6390453 SUNWxorg-mesa has broken links in snv nightly build for 2/24/2006

The script integrated into build 34 to make symlinks to either the nVidia or Mesa OpenGL libraries was failing to create the right links to the Mesa libraries in certain cases.

6395871 integrate Solaris Trusted Extensions to X Windows (Xsun)
6395892 integrate Solaris Trusted Extensions to X Windows (X.org)

Sun's previous Trusted Solaris product is being replaced for Solaris 10 with the Trusted Extensions to Solaris. Instead of a separate fork of the OS, it will instead run standard Solaris 10, but with additional modules loaded to provide the multi-level security features. For X, this means shipping a new library (libXtsol) and putting hooks into the X server that the XTSOL extension loadable modules delivered in the Trusted Extensions for Xsun & Xorg can use to implement their own security checks as needed. We'll be offering this back to the open source X.Org community in the near future under the standard MIT/X11 license.

6396593 [Xorg Bug 6213] local user DoS and arbitrary code execution as root [CVE-2006-0745]

See previous blog post.

[Technorati Tags: Xorg, X11, Solaris, OpenSolaris]

Posted at 07:15PM Mar 20, 2006 by Alan Coopersmith in Solaris  | 

Security hole in Xorg 6.9/7.0

[CVE-2006-0745] X.Org Security Advisory: privilege escalation and DoS in X11R6.9, X11R7.0

X.Org announced this morning a security hole in the Xorg 6.9 & 7.0 releases that allows a local user to create or overwrite files as root or to run code as root. More details can be found in the X.Org Security Advisory.

This bug affects Solaris users who have installed Xorg 6.9 or 7.0, either on their own or from Sun's releases. Xorg 6.9 is included in Solaris 10 patches 118966-14 and later and in Nevada builds 28 and later, which have been released via the Solaris Express programs.

The fix for Solaris 10 is available in a preliminary T-patch from the SunSolve web site - it's the same we plan to release as the permanent fix, it just hasn't finished the QA cycles required for official release yet. See SunAlert 102252 for details and the links to the patch. The fix for Solaris Express was integrated into Nevada build 36, which should be out via the SX: Community Edition in a couple of weeks.

There's also a simple workaround you can apply now to make it impossible to exploit the bug - remove the setuid bit from the /usr/X11/bin/Xorg binary. X servers on x86 need root access for accessing the video hardware directly - but it only has to be setuid root if you want a non-root user to be able to start the X server directly, such as via the xinit program. Most Solaris installs that use X don't do this, but have a display manager such as gdm or dtlogin start X with a login screen. Since those programs run as root, they can start the X server with the needed privileges without having the Xorg binary be setuid root.

Behind the Hole: The Untold Story of this Bug

A couple of weeks ago, the CTO of Coverity sent mail to the X.Org Developers offering access to the results of a code scan of the X.Org code base by their Coverity Prevent code scanner (which is based on the Stanford Checker project). Their scan of the entire X11R6.9 code base found 1681 potential issues, so about a dozen of us have been working our way through the list, triaging the real bugs from the false alarms, and determining which need to be fixed.

While I was working on this one day, I got tired of looking at yet another memory leak (there are tons in programs like xset, xauth, xhost, etc. - but since the programs only run for less than a second before exiting, how much do you care?), and went to the menu to search by report type to see what other bugs it had found. One of the bug types was "BAD_COMPARE" which I hadn't see yet so I went to look at what it found. Someone had already triaged 3 of these as false alarms and 2 as actual bugs, so I went to look at one of the bugs. It showed (and this is a very cut down version of what the actual report looks like in the browser, displayed in the context of the full source file):

1378 	  /* First the options that are only allowed for root */
Event func_conv: Suspicious implicit conversion to function pointer: "&geteuid != 0"; 
did you intend to call the function?
1379 	  if (getuid() == 0 || geteuid != 0)

While I remember looking at the code around here a couple of times during the Xorg 6.9 release cycle, I had never before noticed that the parentheses were missing from the geteuid call. I think my brain simply subconciously autocorrected and inserted the parentheses for me when I read it. Fortunately, the Coverity checker has no subconcious to fool it, and automated attention to detail, so it found what we hadn't seen. Since without the parentheses, the code is simply checking to see if the geteuid function in libc was loaded somewhere other than address 0 (which is pretty much guaranteed to be true), it was reporting it was safe to allow risky options for all users, and thus a security hole was born.

So far that's the only security hole we've found in the Coverity reports - but we're only a little over half way through triaging the reports so far. (Of the 1681 potential issues found, our developers have determined 688 are actual bugs compared to 191 false alarms. Memory leaks are the biggest category, with NULL pointer comparison issues probably second. 63 bugs are already marked as fixed in the coverity reports, and anyone watching the xorg-commit traffic the last couple of weeks has seen a number of those fixes going into CVS for inclusion in the upcoming Xorg 7.1 release.)

P.S. Congratulations to the team at Red Hat and the members of the Fedora community on the release of Fedora Core 5 today, with the Xorg 7.0 modular codebase included. I know having a release-day security advisory isn't how you wanted to celebrate the FC5 launch, but I hope you're finding the new Xorg modular release model is making it much easier to get the fix out for it.

[Technorati Tags: Xorg, Solaris, OpenSolaris, security, Coverity, CVE-2006-0745 ]

Posted at 04:51PM Mar 20, 2006 by Alan Coopersmith in X11  |  Comments[2]