PAX: execution attempt by firefox in Intel 64-bit

[Carlos Carvalho]

I get this when I try to run iceweasel (the Debian-packged firefox):

Jun 13 09:50:45 chela kernel: grsec: From 192.168.3.128: denied RWX mmap of <anonymous mapping> by /usr/lib/iceweasel/iceweasel[iceweasel:32318]

So I did

setfattr -n user.pax.flags -v "mer" /usr/lib/iceweasel/iceweasel

and now

Jun 13 09:51:13 chela kernel: PAX: From 192.168.3.128: execution attempt in: <anonymous mapping>, 3eb8440e000-3eb84410000 3eb8440e000
Jun 13 09:51:13 chela kernel: PAX: terminating task: /usr/lib/iceweasel/iceweasel(iceweasel):32328, uid/euid: 577/577, PC: 000003eb8440ee98, SP: 000003ffb0f0a218
Jun 13 09:51:13 chela kernel: PAX: bytes at PC: 48 83 ec 70 48 8b 84 24 90 00 00 00 48 c1 e8 2f 81 f8 f7 ff
Jun 13 09:51:13 chela kernel: PAX: bytes at SP-8: 000003eb967f1698 000003eb85b0f368 0000000000000202 000003eb80bea700 0000000000000001 fffb83eb7ac28cc0 fff9000000000000 000003ffb0f0a2e0 000003eb808aae20 000003eb85b134f0 0000000000000801

This is a pure 64-bit install (no 32-bit emulation in the kernel) on a Xeon E5 processor, kernel 3.14.6 with grsecurity-3.0-3.14.6-201406101411.patch. It works with AMD Opteron(tm) Processor 2382 in 32-bit.

[PaX Team]

can you check the runtime PaX flags of iceweasel in /proc/pid/status?

[Carlos Carvalho]

It only runs for a few seconds while it checks for add-on compatility (it's the first run after upgrade to version 30). I cannot get the pid and list the status file in this interval...

I checked another graphical program, xpdf. In this case the flags are PeMRs.

In the 32-bit server, which is still in production, the flags are pemRs. xpdf has the same flags in this machine.

[N8Fear]

Firefox needs -m (and Iceweasel therefore should need the same), especially when compiled with jit support (which afaik is default).

[KDE]

I have got similar crash with Firefox 29.0.1, but not during start-up. It worked certain time and crashed.
PaX: PemRs

[Carlos Carvalho]

Firefox needs -m

I think this is what the m in "mer" of the setfattr above does.

[PaX Team]

It only runs for a few seconds while it checks for add-on compatility (it's the first run after upgrade to version 30). I cannot get the pid and list the status file in this interval...

start it from the command line and suspend it with ctrl-z (or strace+suspend) then you'll have time to take a look .

[jbł c ps]

Jun 13 09:51:13 chela kernel: PAX: From 192.168.3.128: execution attempt in: <anonymous mapping>, 3eb8440e000-3eb84410000 3eb8440e000
Jun 13 09:51:13 chela kernel: PAX: terminating task: /usr/lib/iceweasel/iceweasel(iceweasel):32328, uid/euid: 577/577, PC: 000003eb8440ee98, SP: 000003ffb0f0a218

the same problem on Intel 32-bit (Atom Z520) with kernel 3.14.8, grsecurity-3.0-3.14.8-201406191347.patch and firefox 30

crash:

Code: Select all

PaX: pemRS

works:

Code: Select all

PaX: pemRs

with javascript.options.baselinejit set to false in firefox (about:config), works:

Code: Select all

PaX: pemRS

the crash occurs after entering some websites, not on application start

[Lonintly]

Hello,
I've been experiencing the same crashes with iceweasel 31 on a x86_64 system with JIT enabled.

Code: Select all

PAX: execution attempt in: <anonymous mapping>, 7ff98c550000-7ff98c580000 7ff98c550000

The PAX flags I set on the binary are: PSmEXr. I checked in /proc/PID/status at runtime and they are set properly.

I tried debugging with strace, and I see that the incriminated memory area is repeatedly mprotect()'ed with PROT_NONE and then with PROT_READ|PROT_WRITE|PROT_EXEC.
The last call before the crash is mprotect(0x7ff98c550000, ..., PROT_NONE) meaning the memory area isn't executable.

I dug in firefox's source code and found out they are actually causing this segfault on purpose and have a signal handler set up to handle it:
https://github.com/mozilla/gecko-dev/bl ... n.cpp#L450

Code: Select all

// When requesting an interrupt from off the main thread, protect
// Ion code memory so that the main thread will fault and enter a
// signal handler when trying to execute the code. The signal
// handler will unprotect the code and patch loop backedges so
// that the interrupt handler is invoked afterwards.
jitRuntime->ensureIonCodeProtected(rt);

The ensureIonCodeProtected method will call mprotect(..., PROT_NONE)

Then, the segfault is handled in this signal handler:
https://github.com/mozilla/gecko-dev/bl ... s.cpp#L894

Code: Select all

if (rt->jitRuntime() && rt->jitRuntime()->handleAccessViolation(rt, faultingAddress))
return true;

I'm guessing grsec interfere with this and doesn't let their signal handler do its job ?
The only way I found to make it work is to disable jit or disable PAGEEXEC/SEGMEXEC as pointed out by jbł c ps...

[N8Fear]

I have the same issue with Firefox 31.0 (build with jit disabled) on my hardened Gentoo box. Firefox does actually start if started in safe mode (e.g. firefox -safe-mode). Since one of the "features" of safe mode is disabling the jit engine I guess that disabling jit at build time doesn't work properly.

[dunker]

can you check the runtime PaX flags of iceweasel in /proc/pid/status?

From what I can see of my last post and the problem I described, my situation and the information I provided were on a par with the one this reply was intended for. I am still waiting for a response to see whether I can get this problem solved as well. Not sure if you need additional information from me, but I would like to make some headway on it. What would you suggest I can do or provide to get a little help?

I have Firefox on Linux, running in a VM. The whole system is 64-bit, hardened Gentoo, both host and guest. I did not compile JIT into Firefox. Thanks.

[N8Fear]

I did not compile JIT into Firefox. Thanks.

How did you do that. As far as I can tell the -jit USE flag causes Firefox to be build with ion and yarr-jit, both of which aren't options in Firefox' configure script anymore...
In conclusion I guess that you van set USE="-jit" but it simply doesn't affect the build.

Edit: I may have a hack that disables it. I'm building right now, if it works I'll post that hack here...

Edit2: Firefox-31.0 is working fine for me with the following patch applied:

Code: Select all

diff --git a/js/src/configure.in b/js/src/configure.in
index f1a2ca1..8446d42 100644
--- a/js/src/configure.in
+++ b/js/src/configure.in
@@ -1960,20 +1960,20 @@ dnl Configure JIT support
 
 case "$target" in
 i?86-*)
-    ENABLE_ION=1
-    ENABLE_YARR_JIT=1
+    ENABLE_ION=0
+    ENABLE_YARR_JIT=0
     AC_DEFINE(JS_CPU_X86)
     AC_DEFINE(JS_NUNBOX32)
     ;;
 x86_64*-*)
-    ENABLE_ION=1
-    ENABLE_YARR_JIT=1
+    ENABLE_ION=0
+    ENABLE_YARR_JIT=0
     AC_DEFINE(JS_CPU_X64)
     AC_DEFINE(JS_PUNBOX64)
     ;;
 arm*-*)
-    ENABLE_ION=1
-    ENABLE_YARR_JIT=1
+    ENABLE_ION=0
+    ENABLE_YARR_JIT=0
     AC_DEFINE(JS_CPU_ARM)
     AC_DEFINE(JS_NUNBOX32)
     ;;


Note: This is kind of a hacky way to do this. The better way would likely be to find the commit that removed that options and ideally try to get it reverted upstream.

[martinvegter]

I have exactly the same problem: Firefox (Iceweasel) starts and works OK, until I visit some website. Then it crashes.

PAX: execution attempt in: <anonymous mapping>
PAX: terminating task: /usr/lib/iceweasel/iceweasel(iceweasel)

I have set PaX flags with:

paxctl -cem /usr/lib/iceweasel/iceweasel

and runtime flags are:

cat /proc/PID/status | grep PaX
PaX: PemRs

What do I have to do to fix this problem ?
Recompiling Firefox without jit is not an option for me

[PaX Team]

you'll have to disable PAGEEXEC (and i guess SEGMEXEC on i386 if anyone's still using it) to work around this unfortunate firefox misfeature for now. longer term, firefox must be fixed to not behave as a successful exploit itself would.

[martinvegter]

by disabling PAGEEXEC, will I make my Firefox less secure ?
(my system is x86_64, so if I understand correctly, I don't need to disable SEGMEXEC)