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 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.

Tuesday Nov 07, 2006

Xserver DTrace probes integrated

It's been a little over a year since I posted the initial open release of the DTrace probes for the X server. I've gotten busy with a number of other things since then but after a little prodding from the JDS team [1], I've finally run them by the Sun Architecture Review Committee (PSARC case id 2006/609), got their thumbs up, completed code review, and integrated into our Solaris builds of Xorg & Xsun (which due to code sharing also means they're in Xnest, Xvfb, and Xprt). If they pass QA testing, they should appear in Nevada Build 53. I've also put them into the X.Org community git master branch, so they should be in Xorg 7.3 when it ships next May. (The autoconf code for them only checks for the dtrace command needed to build, not for the OS, so when MacOS X & FreeBSD users get DTrace, they should be able to build the probes as well.)

I've also updated with the few changes made to the probes since initial release (added an event probe, and changed one of the arguments made available by the request-done probe) and to include a patch against the Xorg 7.2.RC1 tarball for the current state of the probes for those who don't want to wait.

[1] The conversation went something like this (slightly paraphrased):

  • me: These JavaScript DTrace Probes are cool! We should include them in the FireFox in Solaris!
  • jmr: Yes - and what about the XServer dtrace probes ;)
  • me: oh, um, well, yeah, okay...

[Technorati Tags: , , , ]

Sunday Feb 05, 2006

X11 Forwarding 102

Chris Gerhard wrote a post last week he called “X11 Forwarding 101” on using xauth to grant permissions to your X display when you su to root. I was all ready to write a response about how the complex steps he'd shown could be replaced by a simple, yet secure, command in Solaris 10 [1]:

xhost +si:localuser:root
but before I could, I got a mail from Casper asking why that feature wasn't working the same in Xsun as in Xorg. A few more e-mails exchanged and he had narrowed it down to it working with Xorg with all connection types, and Xsun with local TCP connections (“localhost:0”), but not with Xsun using Unix domain sockets (“unix:0”) or named pipes (“:0”)[2].

It turns out there was a bug in local connection type handling that I'd fixed when porting the localuser code from Xsun to Xorg for Xorg 6.8.0, but forgot to backport to Xsun. It was processing the list of hosts first, then exiting before checking the ServerInterpreted types so never saw the localuser type as allowable. I've filed this in Sun's bug database as 6380709 and am putting a fix into Nevada build 34.

Until that fix is out, I guess you'll have to stick with Chris' instructions for Xsun, unless you want to use the slower TCP transport for local connections, but if you are using Xorg on Solaris 10 or Nevada, you can try “xhost +si:localuser:username” when you want to grant another user on the same machine (in the same zone if on a multi-zone machine in Solaris 10) access to your display.

[1] Actually any OS with both Xorg 6.8.0 or later and support for a secure method of determining the identity of the user on the other end of a local connection, such as Solaris 10's getpeerucred or a similar interface such as getpeereid or SO_PEERCRED.

[2] At the level authentication is done, the shared memory transport in Solaris is treated as a named pipe connection, since that it how the connection is established.

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

Friday Jul 16, 2004

Wheel Mouse support for Solaris: Part 3: Configuring the mouse events

In my previous two posts I've described how to get the software to support the mouse scroll wheel and how to use it with applications. This post finishes up the series on the new wheel mouse support with a description of how to change the way the Xsun server reports the scroll wheel rolls to the applications. For almost all users, the default configuration will be what they want and there will be no need to change it. However, if the default settings don't quite match what you want, there are a variety of changes you can make to the scroll wheel handling by editing the class="XINPUT" entries in the OWconfig file. (Note that these instructions only cover the wheel mouse support in Xsun for directly connected PS/2 & USB mice, not Sun Rays or other X servers.)

For example, to make the mouse on a SPARC system roll in the opposite direction of the usual, you would change the "IMOUSE" entry in /usr/openwin/server/etc/OWconfig to look like this:

   # Sun Mouse module
   class="XINPUT" name="IMOUSE"
      wheelmaps="1=buttons 5 4"

On x86, the mouse XINPUT entry is usually found in /etc/openwin/server/etc/OWconfig and would be changed in a similar fashion.

The format of the wheelmaps option is:

wheelmaps="wheel id=[times x ]action[,wheel id2=[times2 x ]action2...]mappings"

wheel id is an integer in the range 1-255 to specify a specific wheel or a \* to match all wheels without a specific entry.

An action of "axis X" or "axis Y" maps wheel rolls to movement along the specified axis. An action of "buttons A B " maps negative deltas to presses & releases of button A, and positive deltas to presses & releases of button B. A value of "keycodes A B " maps negative deltas to presses & releases of a key with keycode A, and positive deltas to presses & releases of a key with keycode B. (Mapping these keycodes to keysyms is left to the user, sysadmin, and/or desktop defaults.) An action of "discard" discards the events.

The optional times modifier specifies number of times a button or keyboard event should be generated for each delta unit of wheel motion, or the number of pixels the delta should be multiplied by when generating motion events. The value must be a positive number for button and keyboard events, but may be negative for motion events. (Normally rolling the wheel "up" generates motion towards the origin, so specifying a negative pixels value reverses the direction of the motion.) If the times modifier is not specifed, the default value of 1.0 is used for all types of event. If a non-integer value is specified, events may be buffered until enough are accumulated to represent a whole event. For example, if a value of 0.25 is specified, only one out of every 4 single-delta wheel events will be reported.

If not specified for a given mouse device, the default is equivalent to:

   wheelmaps="\*=1.0 x buttons 4 5"
for compatibility with the XFree86 defaults, Sun Ray implementation, and existing wheel mouse aware X applications. When one or more wheels on a mouse device are mapped to buttons, the mouse DDX will, if necessary, increase the number of buttons the mouse is reported as having to at least as many as the highest button id assigned to a wheel action.

For example, when testing with the Logitech MouseMan Wheel, I found it worked better with a slightly modified configuration. This mouse has 3 buttons plus a wheel, which can also be pressed as a button. In the default configuration, pressing the wheel button is reported as button 2, while the button on the side where the thumb normally rests is button 4. The default configuration resulted in the thumb button presses scrolling up, just as rolling the scroll wheel up did. To make the buttons more usable it was simply necessary to set the wheelmap action to "buttons 5 6" and then run

    xmodmap -e "pointer = 1 6 3 2 4 5"
which mapped the "thumb" button to button id 2, the wheel as a button to button 6, and the turns of the wheel to buttons 4 & 5 where the clients expect them.

Thursday Jul 15, 2004

Wheel Mouse support for Solaris: Part 2: Using it with applications

The default configuration of the wheel mouse support in Solaris (both the new support for workstations in my previous post and the existing support in the Sun Ray 2.0 software) is to map the wheel rolls to presses of buttons 4 & 5, as done in XFree86 and other X servers. Because of this, software written to support scroll wheels in those other servers often just starts working on Solaris as soon as you install the wheel mouse support, and much other software can be easily configured to do so as well. Software that should just work includes GNOME 2.0 and other software using the GTK+ toolkit, Mozilla, Netscape 7.0, and StarOffice 7. The Xsun patch for Solaris 9 that introduces workstation wheel mouse support also includes an update to the Solaris xterm to support scroll wheels as well.

There's an existing site with tips for many applications, including older versions of Netscape, at

Additionally, you can add scroll wheel support to some of the existing CDE & X applications on Solaris by adding entries to your $HOME/.Xdefaults file such as these:

\*DtTerm\*Translations: #override \\
        Shift<Btn4Down>:        scroll(-1,page) \\n\\
        Shift<Btn5Down>:        scroll(1,page) \\n\\
        None<Btn4Down>:         scroll(-5,line) \\n\\
        None<Btn5Down>:         scroll(5,line)

\*DtEditor.textTranslations: #override \\
        Shift<Btn4Down>:        previous-page() \\n\\
        Shift<Btn5Down>:        next-page() \\n\\
        None<Btn4Down>:        process-up()process-up()process-up()process-up()process-up() \\n\\
        None<Btn5Down>:        process-down()process-down()process-down()process-down()process-down()

\*DtHelpDialog\*textTranslations: \\
           <Btn4Down>:	       PageUpOrDown(1)\\n\\
           <Btn5Down>:	       PageUpOrDown(0)

Xman\*help\*Paned.manualPage.translations:#override \\
				<Key>Prior: Page(Back) \\n\\
				<Key>Next : Page(Forward)  \\n\\
      				Shift<Btn4Down>,<Btn4Up>: Page(Line,-1) \\n\\
			        Shift<Btn5Down>,<Btn5Up>: Page(Line,1) \\n\\
			        Ctrl<Btn4Down>,<Btn4Up>: Page(Back) \\n\\
				Ctrl<Btn5Down>,<Btn5Up>: Page(Forward) \\n\\
				None<Btn4Down>,<Btn4Up>: Page(Line,-5) \\n\\
				None<Btn5Down>,<Btn5Up>: Page(Line,5)

Xman\*manualBrowser\*manualPage.translations:  #override \\
				<Key>Prior: Page(Back) \\n\\
				<Key>Next : Page(Forward) \\n\\
				Ctrl<Key>s: PopupSearch() \\n\\
      				Shift<Btn4Down>,<Btn4Up>: Page(Line,-1) \\n\\
			        Shift<Btn5Down>,<Btn5Up>: Page(Line,1) \\n\\
			        Ctrl<Btn4Down>,<Btn4Up>: Page(Back) \\n\\
				Ctrl<Btn5Down>,<Btn5Up>: Page(Forward) \\n\\
				None<Btn4Down>,<Btn4Up>: Page(Line,-5) \\n\\
				None<Btn5Down>,<Btn5Up>: Page(Line,5)

(You won't need any of these entries on Solaris Express 5/04 and later, or Solaris 10, since they're already included in the default X resource sets for those applications in those releases. You can add them though if you want to customize the rates at which the wheel scrolls the text in those applications, or mappings of the modifier keys to effects.)

Tuesday Jul 13, 2004

Wheel Mouse support for Solaris: Part 1: Getting the software

After years of talking about it, we finally got the input device driver group and the X group together late last year to add support for mouse scroll wheels to Solaris. The support first appeared in Solaris Express 4/04 for USB mice on SPARC systems, and Solaris Express 5/04 for USB & PS/2 mice on x86 systems, and has now been backported to patches for Solaris 9 (which will be incorporated in the next Solaris 9 update release).

To get the support for Solaris 9, you need to install these patches or later releases, which should all be on SunSolve soon:

Solaris 9 sparc
112785-36X11 6.6.1: Xsun patch
115553-08SunOS 5.9: USB Drivers and Framework Patch
115004-02SunOS 5.9: /kernel/misc/kbtrans patch
117418-01SunOS 5.9: consms patch
S9 x86Needed for
112786-25X11 6.6.1_x86: Xsun patchUSB or PS/2
115554-10SunOS 5.9_x86: USB Drivers and Framework patchUSB
117417-01SunOS 5.9_x86: consms patchUSB
115003-02SunOS 5.9_x86: kbtrans patchUSB
117419-01SunOS 5.9_x86: wheel mouse support vuid PatchPS/2

If you use the Xorg or XFree86 servers instead of Xsun, you should already have support for PS/2 wheel mice from the raw PS/2 support in those servers directly. To get support for USB wheel mice, you'll need the updated drivers from the above patches or Solaris Express, and either get the latest Xorg source from CVS or apply the patch from Xorg Bugzilla #434.

For Sun Rays, the support was included directly in Sun Ray Server Software 2.0, and none of the above is needed.

For Solaris 8, there are freeware drivers written by two members of the Solaris community:

Later this week I'll write more about how to configure it and using it in applications.


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


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


« July 2016