People have been grumbing about this on and off for a while. It can only mean one thing... time for a Bugzilla report to track this sucker! :-) It seems that various bits of GNOME like creating mode 777 shared memory areas. This is at best a wart and and worst a minor security hole. To see this in action, log in to GNOME and type "ipcs -a". Here is what I get: ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 189443 chris 777 196608 2 dest 0x00000000 210948 chris 777 196608 2 dest 0x00000000 214021 chris 777 196608 2 dest 0x00000000 192518 chris 777 196608 2 dest 0x00000000 274439 chris 777 196608 2 dest 0x00000000 275464 chris 777 196608 2 dest There is an issue even without a console login, if you have graphical login running: ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 4205571 gdm 777 196608 2 dest Interesting things a malicious party might be able to do with these world-attatchable memory chunks: (quotes from recent discussion) --- > Can I prevent that section of memory going away by attaching to it? If > so, can I use it as a store for dodgy data which is not accounted to > me? Yes, and yes. --- --- I guess if you're prepared to ctrl-alt-backspace the gdm screen a few times, you can have all the shm you want. Or DoS it, at least. --- I'll add some things: - Snoop on potentially private data (images) of another user - Modify these images (you'd better hope the code that packs/unpacks this image data is safe!!)
FWIW, I believe Owen said that the bug lives in Gtk, and appears through its use of the X shared memory extension. The GIMP also does similar things, I believe independantly (when last I looked, it used mode 666 shm segments). The maintainers refused (or, at least, ignored a patch to obey umask when creating shm segments). Does imlib suffer similar issues?
Yes, this is (at least partially) a GTK+ thing. It should be noted "Modify these images (you'd better hope the code that packs/unpacks this image data is safe!!)" is not a problem, since the data is raw image data being fed to the X server - there is no interpretation at all of this data. Corrupting the displayed images is possible, though hard since it requires pretty careful timing.
The resolution on this is: * GTK+-1.2 is going to stick with 0777 SHM areas, since the practice is universal for other software as well, and we don't have the ability to beta-test changes to GTK+-1.2 that might break compatibility on obscure systems. * The GTK+-2.0 betas use 0700 SHM areas, and unless we get complaints will stay this way.