When we SSH proxy a SPARC Solaris box to a Linux box and run "xcb-demo/tests/lissajoux 1" (try shared memory), it reports that shared memory is available and then hangs. Linux-to-linux results in the app claiming it has shared memory and working fine, which seems odd. Does the SSH X proxy really simulate shared memory?
No, but the proxy passes X protocol through unmodified, and the server correctly reports that *it* supports shared memory. The application is supposed to test whether the shmat and XShmAttach requests succeed, and fall back to non-shm if either fails. Xlib normally handles this internally, as I recall.
Uggh, this is horrible. I'd be tempted to file a bug against ssh; the proxy needs to watch the protocol for stuff like this. Isn't there a horrible security hole waiting for us here somewhere? Anyway, somebody should fix the utils shared memory stuff to properly fail if the extension is supported but SHM can't be connected to, I guess.
1) No, the SSH X proxy shouldn't touch the protocol it's forwarding. That would be weird. (If nothing else, some people 'ssh localhost' sometimes. You'd needlessly break their X setups.) 2) This challenge affects all network-based X connections, not just SSH-forwarded ones. I don't think either the client or server can reliably tell whether the other end is local or remote. There's iptables and multi-homed hosts and all sorts of things to screw up any test you might devise, *except* the test that just checks whether attaching to a particular shared-memory segment on both ends succeeds. 3) The xcb-util/image shared library doesn't actually do the shmat or ShmAttach calls for you, so it can't check them for errors. We should probably do a from-scratch API design here. In the meantime this is probably only an error-checking bug in the test_xcb_image_shm app. You're right that it would be worth checking whether there are security issues with the MIT-SHM extension, but I don't think there's anything specific to or fixable by the xcb-util libraries. I think that in the case that shared memory works, it's always possible for any user on the same system to read or modify the pixel data, because the segments are created with 777 permissions. You might consider that a bit of a hole. However, if shared memory *doesn't* work due to client and server being on different machines, you'd have to either subvert the kernel at the server or get extraordinarily lucky in order to be allocated the same shmid as the client got, and that's the only type of exploit I could think of for this in the remote case. So I think MIT-SHM is only dangerous when it works :-) and not when it's SSH-forwarded.
If this bug is still reproducible, would somebody please either fix it or delete the lissajoux demo?
Created attachment 67150 [details] [review] Patch fixing this bug The problem really still does exist. However, I'm not sure about the value of the lissajoux demo. Anyway, attached is a patch, feel free to commit it to the demo repo.
The demos are archived away, and unlikely to see any further changes.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.