Firejail local root exploit(s)

[InactiveUser 188]

* Analysis: Sandboxing is cool, but it has to be done right.

 * Firejail has too broad attack surface that allows users

 * to specify a lot of options, where one of them eventually

 * broke by accessing user-files while running with euid 0.

 * There are some other similar races. Turns out that it can be

 * _very difficult_ to create a generic sandbox suid wrapper thats

 * secure but still flexible enough to sandbox arbitrary binaries.

 

by Sebastian Krahmer. Quoted from: http://seclists.org/oss-sec/2017/q1/20

 

 

I've kicked the tires a couple of times over the last year and

my feeling is that there remains a lot of low hanging exploitable fruit.

Although the devs have, with some encouragement, introduced macros to

permanently drop privs or drop euid 0 where possible there are still

places where that is not the case.

 

Setuid-root makes me sad, copy_file() worries me still and the ability

for a non-priv user to run any seccomp filter on anything feels like an

accident waiting to happen (assuming it cannot already be exploited).

 

by Martin Carpenter. Quoted from: http://seclists.org/oss-sec/2017/q1/25

 

 

As someone who has mentioned and recommended Firejail, I want to share a couple thoughts:

On one hand, Firejail is still in relatively early development, which means flaws are to be expected.

 

On the other hand, it is worrying that both of these security researchers have also raised serious concerns regarding Firejail's general design. It makes you wonder whether Firejail can still be a viable solution, even after these particular flaws are fixed.

 

What have I personally learned from this? Actually, there's nothing new here.

But there are certain "truths" of IT security that I tend do downplay, despite being aware of them. Probably because they are inconvienent truths:

 

1. using unaudited software is dangerous

2. audits are rare and if they do happen, they often produce scary results

3. setuid is dangerous

4. more security measures != more security

5. desktop security is in a dreadful state

 

Finally, I want to stress that the purpose of this thread is not to disparage Firejail. It's an awesome project, a lot of effort is being put into it. I hope it can be salvaged. But for the time being, I'm just not sure it's advisable to use it.

[zhang888 1066]

Firejail is going to be obsolete soon - Firefox is adding a native, long awaited sandbox in FF52:

https://wiki.mozilla.org/Security/Sandbox

 

More security focused forks like Tor Browser Hardened already use Selfrando, which is an additional layer against use-after-free whole class of vulnerabilities:

https://blog.torproject.org/blog/selfrando-q-and-georg-koppen

 

I don't think it's not advisable to use Firejail, it depends which class of vulnerabilities worries you most. What it aims to do is preventing any FF based

exploits gain persistence on your system, like the last years PDF.js exploit and the more recent FBI exploits against the Tor Browser.

So if this is your case, Firejail would come useful.

 

If someone will find an exploit in Firejail, and target you with it individually, knowing you are using it, it's an old question of who you are and what's you worth.

There was a nice talk on 33C3 about "Million Dollar dissidents" - if you are a worth target, then any well-funded adversary will find a way to target you without

difference of your software/hardware choices.

[InactiveUser 188]

Thanks zhang888, I agree you make a very valid point: Most of Firejail's flaws that are currently discussed don't concern sandbox escapes. Even in its current state, using firejail can go a long way to prevent certain classes of attacks. That said, I still feel squeamish about putting something on my system that is known to contain lots of avenues for privilege escalation.

[serenacat 83]

I don't have a high threat level and value, or much computer security expertise, more interested in personal protection from ransomware and identity theft, and also loosely a dissenter from some government activity.

But as well as a VPN with its identity hiding and port forwarding firewall etc, I also perform most activity including internet access inside a guest Virtual Machine (Oracle VirtualBox). Any VM provides an *extra* level of sandboxing although another "attack surface". Breaking through the Intel or AMD VM hardware is a rather different challenge than gaining uid 0 on Linux.

If I was more paranoid, I would likely use a separate "gateway system" for internet access, and just hygienically transfer payload to/from another "protected/no-internet" system. Perhaps a "secured" X server would be a convenient channel.

There is then 4 rings of protection, from the application security, to a system sandbox like Firejail, to a VM, to another physical system. Vladimir would not see what I bought people for Xmas.