Saturday June 14, 2008
alanc @ sun.com
Alan Coopersmith’s blog
Random thoughts of a disorganized mind...
(and though it should be obvious, while Sun pays me to think about things, they disclaim any responsibility for these thoughts, nor do I claim what I say matches in any way what Sun thinks)
Loading...
Saturday June 14, 2008
June 11, 2008 X Server security advisories
On June 11, iDefense & the X.Org Foundation released security advisories for a set of issues in extension protocol parsing code in the open source X server common code base that iDefense discovered and X.Org fixed.
Their advisories/reports are at:
- X.Org Security Advisory June 2008 - Multiple vulnerabilities in X server extensions
- iDefense 718: Multiple Vendor X Server Render Extension AllocateGlyph() Integer Overflow Vulnerability
- iDefense 719: Multiple Vendor X Server Render Extension ProcRenderCreateCursor() Integer Overflow Vulnerability
- iDefense 720: Multiple Vendor X Server Render Extension Gradient Creation Integer Overflow Vulnerability
- iDefense 721: Multiple Vendor X Server Record and Security Extensions Multiple Memory Corruption Vulnerabilities
- iDefense 722: Multiple Vendor X Server MIT-SHM Extension Information Disclosure Vulnerability
Sun has released a Security Sun Alert for the X server versions in Solaris 8, 9, 10 and OpenSolaris 2008.05 at:
Preliminary T-patches are available for Solaris 8, 9, and 10 from the locations shown in the Sun Alert - these are not fully tested yet (hence the "T" in T-patch).
The fix for these issues has integrated into the X gate for Nevada in Nevada build 92, so users of SXCE or SXDE will get the fixes by upgrading to SXCE build 92 when it becomes available (probably in 3-4 weeks, though the first week of July is traditionally a holiday week in Sun's US offices, so may affect availability).
Fixes for OpenSolaris 2008.05 users following the development build trains will be available when the Nevada 92 packages are pushed to the pkg.opensolaris.org repo (also probably in about 3 weeks from now).
Fixes are planned for OpenSolaris 2008.05 users staying on the stable branch (i.e. nv_86 equivalent), but I do not have information yet on how or when those will be available.
Fixes for users building X from the OpenSolaris sources are currently available in the Mercurial repository of the FOX project in open-src/xserver/xorg/6683567.patch.
For users of all OS versions, the best defenses against this class of attacks is to never, ever, ever run “xhost +”, and if possible, to run X with incoming TCP connections disabled, since if the attacker can't connect to your X server in the first place, they can't cause the X server to parse the protocol stream incorrectly. This is not a complete defense, as anyone who can connect to the Xserver can still exploit it, so if you're in a situation where the X users don't have root access it won't protect you from them, but it is a strong first line of defense against attacks from other machines on the network.
Releases based on the Solaris Nevada train (including OpenSolaris & Solaris Express), default to “Secure by Default” mode, which disables incoming TCP connections to the X server. Current Solaris 10 releases offer to set the Secure by Default mode at install time. On both Solaris 10 & Nevada, the netservices command may be used to change the Secure by Default settings for all services, or the svccfg command may be used to disable listening for TCP connections for just X by running:
svccfg -s svc:/application/x11/x11-server setprop options/tcp_listen=false
and then restarting the X server (logout of your desktop session and log back in).
On older releases, the “-nolisten tcp” flag may be appended to the X server command line in /etc/dt/config/Xservers (copied from /usr/dt/config/Xservers if it doesn't exist) or in whatever other method is being used to start the X server.
See the Sun Alert for other prevention methods, such as disabling the vulnerable extensions if your applications can run effectively without them.
Posted at 09:30AM Jun 14, 2008 by Alan Coopersmith in X11 | Comments[2]
Subscribe!
Ummm, hang on.
I think it is somewhat specious reasoning to say that the best way to avoid attack on parsing untrusted data in all cases is to never parse untrusted data. I mean, yes, by all means disable features and services that are unnecessary - they just create risk and no benefit. However, security by sticking your head in the sand doesn't work.
In fact, I only expect this reasoning from people who want to justify their lack of interest in actually fixing the problem...
Posted by Matthew W. S. Bell on June 14, 2008 at 11:56 PM PDT #
Matthew: My intent was only to make sure people are aware how to disable it if they don't need it. As I mentioned, we are fixing the problems at hand, not just telling people to disable it - but as history has shown, there are likely to be more of these in the future. (X.Org has discussed having all the protocol handling code in the server be autogenerated like libxcb does on the client side now, instead of having each extension author manually write the code for handling their protocol extension, but that hasn't been done yet.)
When it comes to security issues, I'm a firm believer in defense-in-depth and am not using this as an excuse to not fix bugs, since I know there are places that cannot trust all users with X server access, whether they be local or remote. (Before coming to Sun, I was a sysadmin in a University computer lab, and had to protect our systems from our own users.)
Similarly, even though my car has airbags, I still use my seat belt and get my brakes fixed when they need it - though I know I'm safest from getting in a car crash when I'm not in a car.
Posted by Alan Coopersmith on June 18, 2008 at 04:08 PM PDT #