Bug 11080

Summary: X attempts to use shared memory even for ssh-proxied connections
Product: xorg Reporter: Mark Seaborn <mseaborn>
Component: Server/GeneralAssignee: Xorg Project Team <xorg-team>
Status: NEW --- QA Contact: Xorg Project Team <xorg-team>
Severity: minor    
Priority: lowest CC: ajax, esigra
Version: 7.1 (2006.05)   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 44202    
Attachments:
Description Flags
Patch against libXext/src/XShm.c to detect remote connections none

Description Mark Seaborn 2007-05-29 06:23:14 UTC
Occasionally we have seen corruption of all of a Gtk-based X client's images when it connects across ssh.  Images are replaced by image data that clearly comes from another client connected to the server.

It appears that the client and server are attempting to send image data via the MIT-SHM shared memory extension, even though the two are on different machines.

When the problem occurred I did some checks.  The X client was mapping a SysV shared memory segment:

betamax:~$ grep SYSV /proc/17565/maps
b550b000-b556b000 rw-s 00000000 00:08 425985     /SYSV00000000 (deleted)

Normally, no SysV segments are mapped.  Furthermore, the "nattch" parameter was 1 (no server had also mapped the segment).  For correctly-working X clients, nattch=2.

betamax:~$ ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 425985     conductor 600        393216     1          dest

Listing shared memory segments on the machine running the X server reveals that the server happens to have a shared memory segment with the same ID (shmid=425985):

tonytheprawn:~$ ipcs -m
------ Shared Memory Segments --------
key        shmid   owner    perms bytes  nattch status
0x00000000 393216  mseaborn 600   393216 2      dest
0x00000000 425985  mseaborn 600   393216 2      dest
... 

It appears that the X server and client do not check to see whether they are really on the same machine.  The client sends the server a memory segment ID.  If the server fails to map the segment, it fails silently and the two fall back to the remote case.  However in this case, the server is succeeding accidentally and is seeing an unrelated process's image data.

This is not surprising considering that the connection is proxied by ssh:  both the server and client believe they are connected to a local process via a Unix domain socket.

I can see two ways to fix this:

 * Add more checks to the client or server to check that they are on the same machine.  May involve adding parameters to the MIT-SHM X requests.
 * Provide a way for ssh to switch off the MIT-SHM extension on the connections it sets up.  Also requires some sort of protocol extension.

This may not be worth fixing.

There may be some security issues here.  Maybe an X client can use this to read unrelated processes' SysV shared memory segments on the X server's machine?
Comment 1 Alan Coopersmith 2007-05-29 19:01:44 UTC
Created attachment 10127 [details] [review]
Patch against libXext/src/XShm.c to detect remote connections

We've had the attached code in the Solaris libXext for a while, to check 
if an X connection is local or remote, and then return that MIT-SHM is 
unavailable to remote - but the ssh proxy would probably confuse this
code as well.   (And I'm not sure how portable it is.)
Comment 2 Adam Jackson 2008-02-24 18:54:00 UTC
So I hacked up server-side support for this:

http://cvs.fedoraproject.org/viewcvs/*checkout*/rpms/xorg-x11-server/devel/xserver-1.4.99-ssh-isnt-local.patch?rev=1.2

It's not pretty, and it's certainly a linuxism, but it does reject ssh client processes correctly.

I think, ideally, we'd just redact MIT-SHM from the extension list for non-local clients (and the DRI extensions too), _and_ fix the non-local extensions to throw BadRequest should a client attempt to guess at the hidden extension anyway.
Comment 3 Eric Anholt 2009-01-30 21:40:33 UTC
Can we commit this already?
Comment 4 Daniel Stone 2009-08-31 18:32:32 UTC
(In reply to comment #3)
> Can we commit this already?

apparently not.  i'm sure it'll definitely be done properly in 1.8 though, for serious reals.
Comment 5 Alan Coopersmith 2009-08-31 19:16:48 UTC
Ideally the X tunnelling in ssh would intercept the extension requests itself
for MIT-SHM and reject them (probably would want to have a blacklist in the
ssh config of extensions like this to hide from tunneled clients), but that's
something to address with the OpenSSH community.
Comment 6 Alan Coopersmith 2012-03-12 17:56:41 UTC
(In reply to comment #4)
> apparently not.  i'm sure it'll definitely be done properly in 1.8 though, for
> serious reals.

Or maybe 1.13 if ajax's latest patch gets accepted.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.