Bug 17796 - Various GNOME programs use mode 777 SHM areas
Various GNOME programs use mode 777 SHM areas
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: gnome-libs (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Owen Taylor
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-09-22 16:05 EDT by Chris Evans
Modified: 2008-05-01 11:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-10-06 12:19:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Evans 2000-09-22 16:05:33 EDT
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!!)
Comment 1 Matthew Kirkwood 2000-09-23 12:43:38 EDT
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?
Comment 2 Owen Taylor 2000-10-06 12:18:55 EDT
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.
Comment 3 Owen Taylor 2001-07-17 18:41:25 EDT
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.