[GH-ISSUE #1104] Does Firejail protect against ASLR bypasses?

gitea-mirror commented

2026-05-05 06:34:52 -06:00

Owner

Originally created by @curiosity-seeker on GitHub (Feb 16, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1104

This article reports about findings of Dutch researchers who detected that by executing javascript in a browser combined with an existing bug therein it was possible to bypass ASLR.

I wonder if Firejail protects against this threat. Are there any syscalls needed for this exploit which might be filtered by Firejail?

If not, is an implementation of a mitigation technique in Firejail conceivable?

Originally created by @curiosity-seeker on GitHub (Feb 16, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1104 [This](https://www.wired.com/2017/02/flaw-millions-chips-strips-away-key-hacking-defense-software-cant-fully-fix/) article reports about findings of Dutch researchers who detected that by executing javascript in a browser combined with an existing bug therein it was possible to bypass ASLR. I wonder if Firejail protects against this threat. Are there any syscalls needed for this exploit which might be filtered by Firejail? If not, is an implementation of a mitigation technique in Firejail conceivable?

gitea-mirror

2026-05-05 06:34:52 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 06:34:59 -06:00

Author

Owner

@Ferroin commented on GitHub (Feb 16, 2017):

Upstream article is here: https://www.vusec.net/projects/anc/

Firejail as it exists right now does not protect against this particular attack. As far as I can tell, the only to truly protect against it from software is to run on a purely emulated CPU, which I personally would argue is beyond the scope of Firejail.

That said, I'm inclined to agree with Intel and Microsoft's stance that this is not a hugely relevant bug because without a privilege escalation exploit, the most you can get out of this is arbitrary code execution with the same privileges as attacked process. Because of this, the ASLR bypass outlined in that article won't get you anything beyond what's in the container, so while Firejail doesn't protect against ASLR bypasses, it still protects against the only useful things you can do with the information gained from using such exploits.

@Ferroin commented on GitHub (Feb 16, 2017): Upstream article is here: https://www.vusec.net/projects/anc/ Firejail as it exists right now does not protect against this particular attack. As far as I can tell, the only to truly protect against it from software is to run on a purely emulated CPU, which I personally would argue is beyond the scope of Firejail. That said, I'm inclined to agree with Intel and Microsoft's stance that this is not a hugely relevant bug because without a privilege escalation exploit, the most you can get out of this is arbitrary code execution with the same privileges as attacked process. Because of this, the ASLR bypass outlined in that article won't get you anything beyond what's in the container, so while Firejail doesn't protect against ASLR bypasses, it still protects against the only useful things you can do with the information gained from using such exploits.

gitea-mirror commented

2026-05-05 06:35:03 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Feb 16, 2017):

Thanks, @Ferroin , this sounds reasonable.

As far as I understand all details are not yet available. So I still wonder if for those attacks triggered by malicious javascript syscalls are involved which could be filtered, possibly by a more efficient policy made available by Gosecco which has been integrated in Subgraph OS. Note, that I'm not a programmer, so what I'm saying could be utter nonsense.

EDIT: The scientific paper is available here.

@curiosity-seeker commented on GitHub (Feb 16, 2017): Thanks, @Ferroin , this sounds reasonable. As far as I understand all details are not yet available. So I still wonder if for those attacks triggered by malicious javascript syscalls are involved which could be filtered, possibly by a more efficient policy made available by [Gosecco](https://github.com/twtiger/gosecco) which has been [integrated](https://subgraph.com/blog/subgraph-dec2016-iso-availability/) in Subgraph OS. Note, that I'm not a programmer, so what I'm saying could be utter nonsense. EDIT: The scientific paper is available [here](http://www.cs.vu.nl//~herbertb/download/papers/anc_ndss17.pdf).

gitea-mirror commented

2026-05-05 06:35:05 -06:00

Author

Owner

@netblue30 commented on GitHub (Feb 17, 2017):

You are doing something wrong there. I downloaded avidemux appimage you linked to, and run it directly:

$ cd Downloads
$ ls avi*
avidemux_2.6.15.appImage
$ firejail --appimage avidemux_2.6.15.appImage 
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-common.local
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-passwdmgr.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 8475, child pid 8478
Dropping all Linux capabilities and enforcing default seccomp filter
Child process initialized
Directory /home/netblue/.avidemux6/ exists.Good.
Using /home/netblue/.avidemux6/ as base directory for prefs, jobs, etc.
 [isPortableMode] 13:33:40-650  Portable mode
  [ADM_initBaseDir] 13:33:40-650  Portable mode
  [ADM_initBaseDir] 13:33:40-650  Relative to install plugin mode : </run/firejail/appimage/.appimage-8475/usr/lib/ADM_plugins6/>
 *************************
  Avidemux v2.6.15 (0) .
*************************
...

It works just fine. Probably you forgot to put --appimage on firejail command line? Run appimages as they come, just extract them from the zip file if they are a zip file.

@netblue30 commented on GitHub (Feb 17, 2017): You are doing something wrong there. I downloaded avidemux appimage you linked to, and run it directly: ````` $ cd Downloads $ ls avi* avidemux_2.6.15.appImage $ firejail --appimage avidemux_2.6.15.appImage Reading profile /etc/firejail/default.profile Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-common.local Reading profile /etc/firejail/disable-programs.inc Reading profile /etc/firejail/disable-passwdmgr.inc ** Note: you can use --noprofile to disable default.profile ** Parent pid 8475, child pid 8478 Dropping all Linux capabilities and enforcing default seccomp filter Child process initialized Directory /home/netblue/.avidemux6/ exists.Good. Using /home/netblue/.avidemux6/ as base directory for prefs, jobs, etc. [isPortableMode] 13:33:40-650 Portable mode [ADM_initBaseDir] 13:33:40-650 Portable mode [ADM_initBaseDir] 13:33:40-650 Relative to install plugin mode : </run/firejail/appimage/.appimage-8475/usr/lib/ADM_plugins6/> ************************* Avidemux v2.6.15 (0) . ************************* ... ````` It works just fine. Probably you forgot to put --appimage on firejail command line? Run appimages as they come, just extract them from the zip file if they are a zip file.

gitea-mirror commented

2026-05-05 06:35:07 -06:00

Author

Owner

@xenopeek commented on GitHub (Feb 17, 2017):

@netblue30 I think your comment https://github.com/netblue30/firejail/issues/1104#issuecomment-280649535 is not for this issue but for issue #1102.

@curiosity-seeker I'm curious about the same. The source code for the JavaScript attack isn't public but the source code for the standalone attack is: https://github.com/vusec/revanc. It is easily compiled and run with the instructions there (if you're on Debian/Ubuntu or derivative install build-essential first).

The first test failed to run on my system because:

source/anc.c:53: error: transparent huge pages seem to be enabled.
please run 'echo "never" > /sys/kernel/mm/transparent_hugepage/enabled' as root.

After running echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled the test would run. Next I ran the test with Firejail using Firefox' profile firejail --profile=/etc/firejail/firefox.profile obj/anc and that test also failed:

source/buffer.c:36: Cannot allocate memory
source/anc.c:102: error: unable to allocate the target buffer.

I haven't looked into those errors. I'm hesitant to draw conclusions for the JavaScript attack from the two issues encountered with the standalone attack.

@xenopeek commented on GitHub (Feb 17, 2017): @netblue30 I think your comment https://github.com/netblue30/firejail/issues/1104#issuecomment-280649535 is not for this issue but for issue #1102. @curiosity-seeker I'm curious about the same. The source code for the JavaScript attack isn't public but the source code for the standalone attack is: https://github.com/vusec/revanc. It is easily compiled and run with the instructions there (if you're on Debian/Ubuntu or derivative install build-essential first). The first test failed to run on my system because: source/anc.c:53: error: transparent huge pages seem to be enabled. please run 'echo "never" > /sys/kernel/mm/transparent_hugepage/enabled' as root. After running `echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled` the test would run. Next I ran the test with Firejail using Firefox' profile `firejail --profile=/etc/firejail/firefox.profile obj/anc` and that test also failed: source/buffer.c:36: Cannot allocate memory source/anc.c:102: error: unable to allocate the target buffer. I haven't looked into those errors. I'm hesitant to draw conclusions for the JavaScript attack from the two issues encountered with the standalone attack.

gitea-mirror commented

2026-05-05 06:35:11 -06:00

Author

Owner

@Ferroin commented on GitHub (Feb 17, 2017):

Firejail should protect fine against most realistic native code versions of this.

The THP related error you got makes sense. Transparent hugepages are how Linux allows apps to use larger pages (4MB instead of 4KB on x86 IIRC) to reduce page table size and therefore improve MMU performance (in essence, it reduces the time needed to look up a given virtual-to-physical address mapping). Most Linux distros have support for this enabled by default because it gives a reasonable performance improvement to many applications and generally doesn't waste all that much memory. The larger page granularity and the higher performance both make this particular exploit much harder to use (the granularity in particular makes it near impossible if I understand the code correctly).

I'm actually surprised that I didn't think about this before, but force enabling that functionality ('always' instead of 'never') should provide a reasonable degree of mitigation. I'd be willing to bet that that's part of why Intel and Microsoft don't see this as a significant issue.

@Ferroin commented on GitHub (Feb 17, 2017): Firejail should protect fine against most realistic native code versions of this. The THP related error you got makes sense. Transparent hugepages are how Linux allows apps to use larger pages (4MB instead of 4KB on x86 IIRC) to reduce page table size and therefore improve MMU performance (in essence, it reduces the time needed to look up a given virtual-to-physical address mapping). Most Linux distros have support for this enabled by default because it gives a reasonable performance improvement to many applications and generally doesn't waste all that much memory. The larger page granularity and the higher performance both make this particular exploit much harder to use (the granularity in particular makes it near impossible if I understand the code correctly). I'm actually surprised that I didn't think about this before, but force enabling that functionality ('always' instead of 'never') should provide a reasonable degree of mitigation. I'd be willing to bet that that's part of why Intel and Microsoft don't see this as a significant issue.

gitea-mirror commented

2026-05-05 06:35:12 -06:00

Author

Owner

@xenopeek commented on GitHub (Feb 18, 2017):

I disabled the THP enabled check in the program, recompiled it, and ran the test again with THP enabled set to always (the system default). Test runs fine but with slightly different results — 75% slot errors instead of 50% slot errors with THP enabled set to never. What does any of this mean anyway.

Test results:

@xenopeek commented on GitHub (Feb 18, 2017): I disabled the THP enabled check in the program, recompiled it, and ran the test again with THP enabled set to always (the system default). Test runs fine but with slightly different results — 75% slot errors instead of 50% slot errors with THP enabled set to never. What does any of this mean anyway. Test results: * [THP enabled = always](http://dpaste.com/27AKN8S) * [THP enabled = never](http://dpaste.com/3EWZ22M)

gitea-mirror commented

2026-05-05 06:35:14 -06:00

Author

Owner

@netblue30 commented on GitHub (Feb 19, 2017):

Sorry for my previous message, it was supposed to go on a different thread. I don't think there is any fix on firejail level, it is too deep.

@netblue30 commented on GitHub (Feb 19, 2017): Sorry for my previous message, it was supposed to go on a different thread. I don't think there is any fix on firejail level, it is too deep.

Rows
Columns

[GH-ISSUE #1104] Does Firejail protect against ASLR bypasses? #754