Saturday Jun 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:

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.

Monday Oct 08, 2007

X Font Server (xfs) Security Hole in Solaris

As noted in the ZDNet posting X Font Server flaw hits Sun Solaris hard, the recently announced X font server vulnerabilities not only affect Solaris, but are exposed to the network by default in some Solaris installs.

What the article fails to mention is that it's only older installs that are vulnerable by default - Solaris versions up through Solaris 10 6/06 run xfs by default from inetd listening to the network. Solaris 10 11/06 and later Solaris 10 releases ask you at install time if you want your network services to default to being open or closed. Solaris Nevada/Express just closes them all by default and requires you to turn back on the ones you want. (These changes came from the Solaris Secure by Default project, which has more information on its project pages.)

Our sustaining teams are producing patches and a Sun Alert covering this issue, but until then, if you don't need the X font server (on Solaris it's really only used for remote desktop sessions from computers without the standard Solaris fonts already installed - unlike some Linux'es, local sessions don't use it), you can easily turn it off in several ways:

  • On all Solaris releases: “/usr/openwin/bin/fsadmin -d”, which will either break the link that inetd uses (Solaris 2.6-Solaris 9) or use inetadm to disable the svc:/application/x11/xfs service (Solaris 10 & later).
  • On Solaris 10 and later, you can do the same thing explicitly with “/usr/sbin/inetadm -d svc:/application/x11/xfs:default”.
  • On Solaris 2.6 through 9, you can do the traditional editing of /etc/inetd.conf to disable it, then “pkill -HUP inetd”.
  • If you'll never need it, and want to be sure it's gone, remove the xfs package with “pkgrm SUNWxwfs”.

Update: Oops, had a typo in one of the instructions above - should have been “pkill -HUP inetd”, not kill. Also, as Paul noted in the comments the Sun Alert is now published, with interim fixes soon to follow, at http://sunsolve.sun.com/search/document.do?assetkey=1-26-103114-1.

Monday Feb 19, 2007

What programmers look like...

Apparently, programmers look like me & Gary, according the Flickr title Alec put on the snapshot of us in his photos from last week's Sun Security Ambassador beerbash. At least I didn't get caught in a funny hat like the distinguished gentleman to our right (who was actually only a couple feet to our right when the photo was taken):

There's nothing like realizing you're surrounded by one of the inventors of public-key crypto and the architects of Trusted Solaris, having your photo taken by the developer of Crack, to make a X guy feel like he stepped into the wrong party. Though I wasn't feeling out of place for long, since just before Jim came down the hall and summoned me with the magic words “Free Beer” I had been working on the putback for the Xorg 7.2 vs. Trusted Extensions bug I'd been working on most of the week, so was answering questions about that, and then I got to meet a whole bunch of people who responded with “Oh! I know your posts on the [Sun internal] security-interest list.” In the end, I was once again feeling lucky to be able to work with such an amazing collection of talented and friendly engineers.

[If you couldn't tell, I'm the one just starting to show grey in his beard - or the one who is in most need of a trip to the gym. Maybe I should try Gman's new workout plan.]

Monday Mar 20, 2006

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: , , , , , ]

Friday Sep 16, 2005

Solaris patches for CAN-2005-2495

A security hole in processing XCreatePixmap requests in the Xserver (known as “CAN-2005-2495”) was announced this week. This affects most X servers based on the original X11R6 code from the X Consortium at MIT, so we've released preliminary patches for the Xsun & Xorg servers in Solaris. These haven't had time to go through the full patch regression test process yet, so aren't in the main patch site for now, but in the special Preliminary Security T-patches area on SunSolve.

Further details, including the list of which patches to use for each Solaris release, can be found in Security Sun Alert #101926. (And yes, there is a slight mistake in the current version since it references XPM files, which are not involved in this exploit - that was an accidental copy of the description from the previous libXpm security alerts. Unfortunately, I didn't notice that until after I told the Sun Alert team the draft alert was correct. I let them know it was wrong, so hopefully they can fix that. It should say something more like “A program that has access to the X server (via xhost or xauth authentication) can make calls that may allow it to execute arbitrary code with the privileges of the X server.” Which is of course, just another reason you should just say no to “xhost +”.)

[Technorati Tags: , , , ]

About

Engineer working on Oracle Solaris and with the X.Org open source community.

Disclaimer

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle, the X.Org Foundation, or anyone else.

See Also
Follow me on twitter

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today