|Summary:||X attempts to use shared memory even for ssh-proxied connections|
|Product:||xorg||Reporter:||Mark Seaborn <mseaborn>|
|Component:||Server/General||Assignee:||Xorg Project Team <xorg-team>|
|Status:||NEW ---||QA Contact:||Xorg Project Team <xorg-team>|
|i915 platform:||i915 features:|
|Bug Depends on:|
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.