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.

Note

You need to
log in
before you can comment on or make changes to this bug.