Xulrunner + Iceweasel3 + flash killed by grsec

[specs]

My configuration:
i386 (VIA Nehemiah) with Debian unstable
Kernel 2.6.27.7 with grsec applied
Patch version: grsecurity-2.1.12-2.6.27.7-200811201849.patch
Interdiff pax-linux-2.6.27.7-test21.patch pax-linux-2.6.27.7-test22.patch applied
ii xulrunner-1.9 1.9.0.4-2 XUL + XPCOM application runner
ii iceweasel 3.0.4-1 lightweight web browser based on Mozilla
Also installed: Shockwave Flash 9.0 r31

Iceweasel starts, but is killed after flash won't start (xulrunner?).

Code: Select all

$ iceweasel http://www.tokyopop.com
LoadPlugin: failed to initialize shared library /usr/lib/jvm/java-6-sun-1.6.0.10/jre/plugin/i386/ns7/libjavaplugin_oji.so [/usr/lib/jvm/java-6-sun-1.6.0.10/jre/plugin/i386/ns7/libjavaplugin_oji.so: cannot enable executable stack as shared object requires: Permission denied]
LoadPlugin: failed to initialize shared library /usr/lib/jvm/java-6-sun-1.6.0.10/jre/plugin/i386/ns7/libjavaplugin_oji.so [/usr/lib/jvm/java-6-sun-1.6.0.10/jre/plugin/i386/ns7/libjavaplugin_oji.so: cannot enable executable stack as shared object requires: Permission denied]
LoadPlugin: failed to initialize shared library /usr/lib/jvm/java-6-sun-1.6.0.10/jre/plugin/i386/ns7/libjavaplugin_oji.so [/usr/lib/jvm/java-6-sun-1.6.0.10/jre/plugin/i386/ns7/libjavaplugin_oji.so: cannot enable executable stack as shared object requires: Permission denied]
Killed


After applying execstack on java I get a clean kill right after starting iceweasel (and giving time to fire up flash):

Code: Select all

# execstack -c /usr/lib/jvm/java-6-sun/jre/plugin/i386/ns7/libjavaplugin_oji.so
# execstack -c /usr/lib/jvm/java-6-sun/jre/lib/i386/libjavaplugin_nscp.so

Dmesg output:

Code: Select all

# dmesg
...
grsec: signal 11 sent to /usr/lib/xulrunner-1.9/xulrunner-stub[firefox-bin:22608] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:22316] uid/euid:1000/1000 gid/egid:1000/1000
grsec: signal 11 sent to /usr/lib/xulrunner-1.9/xulrunner-stub[firefox-bin:22608] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:22316] uid/euid:1000/1000 gid/egid:1000/1000
PAX: execution attempt in: <anonymous mapping>, 4b44c000-4b44d000 4b44c000
PAX: terminating task: /usr/lib/xulrunner-1.9/xulrunner-stub(firefox-bin):22608, uid/euid: 1000/1000, PC: 4b44c000, SP: 5f0a488c
PAX: bytes at PC: 81 fc 68 3b 04 5f 0f 82 85 00 00 00 55 8b ec 81 ec 10 00 00
PAX: bytes at SP-4:
grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/lib/xulrunner-1.9/xulrunner-stub[firefox-bin:22608] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:22316] uid/euid:1000/1000 gid/egid:1000/1000

Tried it on another pc (AMD64X2) where unfortunately flash was not installed properly. At least it did not crash:

Code: Select all

We're sorry, but your current browser or Flash version does not meet the minimum site requirements listed below:

Browsers:

    * PC: Internet Explorer 6 or higher
    * PC: Netscape 7 or higher
    * PC/Mac: Firefox 1.2 or higher
    * PC/Mac: Mozilla 1.5 or higher
    * Mac: Safari 1.0 or higher


Flash:

    * PC/Mac: Flash 8 or higher

Since iceweasel crashes I think I will submit a bugreport to xulrunner.
Flash is a closed source propriotary plugin, but I will have to submit a bugreport there also.

[specs]

Some with adobe flashplayer 10.0 r12:

Code: Select all

# execstack -c ~user/.mozilla/plugins/libflashplayer.so

(necessary for else flash won't start and I get the same message as above.)

After starting iceweasel I see the same messages in dmesg.

Code: Select all

# dmesg
...
PAX: execution attempt in: <anonymous mapping>, 45ecf000-47f9c000 45ecf000
PAX: terminating task: /usr/lib/xulrunner-1.9/xulrunner-stub(firefox-bin):23375, uid/euid: 1000/1000, PC: 45ecf000, SP: 5f17192c
PAX: bytes at PC: 81 fc 28 13 11 5f 0f 82 85 00 00 00 55 8b ec 81 ec 10 00 00
PAX: bytes at SP-4:
grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/lib/xulrunner-1.9/xulrunner-stub[firefox-bin:23375] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:23021] uid/euid:1000/1000 gid/egid:1000/1000


[PaX Team]

Code: Select all

PAX: execution attempt in: <anonymous mapping>, 45ecf000-47f9c000 45ecf000
PAX: terminating task: /usr/lib/xulrunner-1.9/xulrunner-stub(firefox-bin):23375, uid/euid: 1000/1000, PC: 45ecf000, SP: 5f17192c

flash can generate code at runtime (and i think future javascript engines will do so as well) so you'll have to disable MPROTECT on the affected binaries, i'm afraid. very bad for browser security of course but i don't know if there's a way to disable this just-in-time compilation feature.

[specs]

Thanks for the reply. I tested it and it worked.

Funny thing is that this is I ran into the problem only with iceweasel 3. Perhaps there are only a few sites which do try to use flash to the fullest.

Another thing that worries me more is that flash crashes iceweasel (or firefox as originally called). Especially a program like iceweasel should distuinguish between the program and the plugins, add-ons, etc.. It should not crash on a plugin. Makes me look out for the google chrome since that program is said to be using threads. Hope it brings a little extra security...

Are there any sandbox structures known to work with grsecurity and pax?
Seems like the security for the complete program needs to be more relaxed, but in other places the security could be enhanced.

[PaX Team]

Another thing that worries me more is that flash crashes iceweasel (or firefox as originally called). Especially a program like iceweasel should distuinguish between the program and the plugins, add-ons, etc.. It should not crash on a plugin. Makes me look out for the google chrome since that program is said to be using threads.

chrome uses processes for browser content separation, which is unlike FF. i don't know however how chrome will handle plugins, ideally they'd be loaded only into the browser process that actually needs them. in FF plugins are executed in the same address space so the whole process is at their mercy.

Are there any sandbox structures known to work with grsecurity and pax?

i don't know what would not work, sandboxes are pretty orthogonal to PaX at least, and grsec has its own features (chroot hardening, RBAC) that can be used for sandboxing.