74302 - World readable and writeable shared memory segments

Status: NEW

(Core :: XUL, defect)

Description

[tenthumbs]

I'm not sure where this bug really belongs. I hope some one will direct it
appropriately.

On Linux, run ipcs, start mozilla, and run ipcs again. You will see that 
some shared memory segments appear. Strace shows that some other 
transient segments are created along the way. Note that all the segments 
are created with 777 permissions. Anyone can read and write to them 
which can't possibly be good.

These segments are created by gdk which has 777 hard-coded into it.

The question is whether these segments are necessary. I can start 
mozilla with "./mozilla --no_xshm ..." and the segments do not appear 
nor does there appear to be any impact on performance.

If IPC shared memory isn't necessary, there's is a "gdk_set_use_xshm" 
call in the library which mozilla should use as early as possible. If 
shared memory is necessary then this is a huge security hole.

Comment 1

[timeless]

isn't this the point of shared memory?

Comment 2

[tenthumbs]

It's one thing to share memory among different programs owned by the same user.
It's quite another to allow *any* user to read and write to my program.

BTW, why is this assigned to an XP component? This is about GTK.

Comment 3

[Stuart Parmenter]

anyone have any clues here?  blizzard?

Comment 4

[Asko Tontti]

http://www.xfree86.org/pipermail/xpert/2001-February/005716.html

Comment 5

[Asko Tontti]

Places where shared memory is used:

http://lxr.mozilla.org/seamonkey/search?string=gdk_pixmap_create
http://lxr.mozilla.org/seamonkey/search?string=gdk_pixmap_colormap

So it used by xpinstall wizard (checkboxes), splash screen and SetIcon.

Comment 6

[Asko Tontti]

Attachment: patch: disable gdk's shared memory

Comment 7

[Asko Tontti]

Attachment: patch: prev + same for installer

Comment 8

[Christopher Blizzard (:blizzard)]

The only thing that it allows you to do is to read and write to mozilla's image
data.  Someone could slap some porn or something into your page load without you
knowing it.  What other risk is there?

Comment 9

[tenthumbs]

Unfortunately, command line tricks run afoul of bug 74303 so the current
patches would be worse than the cure.

The problem, as always, is that there's no way to guarantee that all IPC
implementations are sufficiently robust so that these shared segments
cannot be exploited. This becomes particularly important if a privileged
user runs mozilla.

Since this is a GTK policy issue, the correct solution would be for GTK
to have a function to set premission bits on any shared segments it
creates. Perhaps someone can convince the GTK maintainers that this is a
good thing.

Until that happens, mozilla obviously has to turn this off. I suggest
that mozilla call gdk_set_use_xshm as early as possible.

Comment 10

[Christopher Blizzard (:blizzard)]

You didn't answer my question.  What is the risk?  This is a major performance
hit for us since we use those shared memory segments for drawing.

Comment 11

[Asko Tontti]

Christopher: this is NOT performance hit because we only disable gdk's
shared memory for pixmaps. They are used to present the application's icons
to window manager.

Comment 12

[Christopher Blizzard (:blizzard)]

OK but if mozilla is embedded into another application then we are disabling it
for that application as well.  Once again, what is the risk here?  No one has
answered my question.

Comment 13

[Asko Tontti]

risks are small because feature is little used (icons for wm, splash window,
checkbox images for installer).

And next release of gtk+ will probably fix this. More on this and risks
can be found from

  http://www.xfree86.org/pipermail/xpert/2001-February/005716.html

I recommend wontfix unless somethink more serious comes up.

(BTW my comments and analysis are based on gtk+ 1.2.9)

Comment 14

[Stuart Parmenter]

uh, the shared segments are created for gdkrgb's scratch buffers... anything 
(read everything) that goes through gdkrgb to draw will use these shared 
segments.

Comment 15

[Asko Tontti]

Yes, you are right. For some reason I didn't notice that :(

Comment 16

[Christopher Blizzard (:blizzard)]

Also see:

http://bugzilla.gnome.org/show_bug.cgi?id=50810

Comment 17

[Stuart Parmenter]

so can i close this as invalid since it is technically a bug in gtk?

Comment 18

[tenthumbs]

That's a bad idea.

Mozilla purposely avoids creating disk files with lax permissions.
Why is the running program allowed more leniency? If an attacker can
corrupt a running program then the attacker can probably corrupt
disk files as well. No, I can't demonstrate a risk currently but I
cannot also demonstrate that mozilla is safe. Prudence dictates that
known loopholes be plugged.

I realize that this is GTK's fault but there is a way to turn this
off programatically (not with a command-line hack). It's an interim
solution until GTK gets its act together. Moreover, I can't see any
appreciable time difference in page loading. I suspect layout time
masks the shared memory issue.