Malware can bypass host's firewall using firejail --net=...

[dandelionred]

Hey guys! I'm slightly :) paranoid mby but still.

Setup:

• openvpn client
• default output policy is DROP
• outgoing traffic is only allowed to
  • lo device
  • local networks
  • openvpn server
  • tun0 device

This way my external traffic either goes into tun0 or goes nowhere in case the openvpn connection dies whatever the reason, so my real external ip is never leaked.

Firejail present on my system opens an attack vector for malware to leak my real ip like this:

firejail --net=wlan0 --defaultgw=192.168.1.1 --dns=8.8.8.8 curl icanhazip.com

(because the newly created network namespace is absolutely independ of the host's network namespace were my firewall rules exist)

Basicly, it doesn't mean how much restrictive the host's firewall is, malware can bypass it if only it can exec firejail (=firejail is present and the user is allowed to use it).

Another point of view: the recommended way to sandbox x11 unintentionally ignores the host's firewall

firejail --x11 --net=wlan0 --defaultgw=192.168.1.1 --dns=8.8.8.8 firefox

Btw --net is not a must to disable the abstract x11 sockets. With this https://tstarling.com/blog/2016/06/x11-security-isolation/ I successfully shut those down in ubuntu 14.04:

/etc/lightdm/lightdm.conf.d/50-X-no-listen.conf

[SeatDefaults]
xserver-command=X -nolisten local

Is it possible to disable the "--net" feature at all at compile time?

[SkewedZeppelin]

This is already supported: uncomment and set restricted-network to yes in /etc/firejail/firejail.config. It is actually the default in Debian packages, see https://sources.debian.org/patches/firejail/0.9.58.2-1/config-hardening.patch/

malware can bypass it

at that point, you're already compromised anyway

Off-topic: instead of relying on fragile iptable rules to ensure your routing, consider using Qubes+Whonix or Tails

[veloute]

if malware on your system can run arbitrary commands, you've already got a much bigger problem than them getting your real ip address.

[dandelionred]

@SkewedZeppelin

This is already supported: uncomment and set restricted-network to yes in /etc/firejail/firejail.config. It is actually the default in Debian packages, see https://sources.debian.org/patches/firejail/0.9.58.2-1/config-hardening.patch/

I compiled it myself. Thanks for the tip, I'll use the config option.

malware can bypass it

at that point, you're already compromised anyway

I don't share your point of view. Thinking in terms of "compromised anyway" it would be OK having passwordless sudo.

@veloute

if malware on your system can run arbitrary commands, you've already got a much bigger problem than them getting your real ip address.

Do you use passwordless sudo?

[veloute]

Do you use passwordless sudo?

see https://xkcd.com/1200/

[dandelionred]

@veloute

Do you use passwordless sudo?

see https://xkcd.com/1200/

There is a big flaw in the comic: you have to have friends for someone to impersonate to.
Joking aside, the comic (while still hitting some point) is poor minded

[chiraag-nataraj]

see https://xkcd.com/1200/

This is why you don't remain logged in and make it easy to revoke authorization for programs that are logged in. For example, I run fetchmail, but it has its own app password which I can then revoke should the need arise.

Unfortunately, I end up remaining logged in to a bunch of chat services (Messenger, Slack, the like), but I can easily kick the computer off of those services should the need arise as well,

So yeah, the comic isn't really all that valid.

[veloute]

There is a big flaw in the comic: you have to have friends for someone to impersonate to.
Joking aside, the comic (while still hitting some point) is poor minded

This is why you don't remain logged in and make it easy to revoke authorization for programs that are logged in. For example, I run fetchmail, but it has its own app password which I can then revoke should the need arise.

Unfortunately, I end up remaining logged in to a bunch of chat services (Messenger, Slack, the like), but I can easily kick the computer off of those services should the need arise as well,

So yeah, the comic isn't really all that valid.

i see your point - it probably isn't the best example but was the best one i could think of at the time.
a better example of the point i was trying to make was maybe https://en.wikipedia.org/wiki/Principle_of_least_privilege

essentially, what i was trying to say is that a process doesn't necessarily need to have elevated privileges to wreak havoc for a user and cause all kinds of damage - generally speaking, most users have quite a lot of important documents stored in a regular, user-accessible directories.

if a process can run arbitrary commands on a system, they can, for example:

• force remove all files it has write access to.
• download and run anything.
• kill other user processes.
• etc.

from the op:

Basicly, it doesn't mean how much restrictive the host's firewall is, malware can bypass it if only it can exec firejail (=firejail is present and the user is allowed to use it).

it's a lot harder to stop malware from doing things once it's in, that's why we take precautions so it can't get in the system in the first place.

firejail is essentially an answer to that problem. if a process is isolated using firejail, it wouldn't be able to do the command first mentioned, so i'd argue the problem is moot.

[dandelionred]

that's why we take precautions so it can't get in the system in the first place.

Check this out:

• https://stackoverflow.com/questions/38236366/are-pip-packages-curated-is-it-safe-to-install-them
• https://searchsecurity.techtarget.com/news/252453398/Compromised-NPM-package-highlights-open-source-trouble

So it is pretty possible to have malware installed by just upgrading some application from pip/npm.

---

After all, I'd like to take back my thoughts about the horrible possibility for malware to leak my ip by means of firejail --net.

I'd even say more: it doesn't matter much if your sudo is passwordless or not on a generic xorg desktop (not speaking about qubes). As only malware can run anything under the user, in can either use the passwordless sudo OR keylog with xinput until you enter the password. Some creepy details: https://security.stackexchange.com/a/119420

[dandelionred]

Back to the stolen laptop story: you're not safe even in case you have the screen locked the stock way. That's why this exists https://github.com/google/xsecurelock

[chiraag-nataraj]

So it is pretty possible to have malware installed by just upgrading some application from pip/npm.

I mean, yeah. Just like it's possible to get malware on Windows by downloading random applications. I really don't see a difference here.

As for the other stuff, I'm not quite sure what your point is. Yeah, X11 is insecure - I feel like many people here already know that. We can try to use X11 isolation through firejail (using either xpra or xephyr), but everything's imperfect.

And yeah, all those environment variables are both useful and dangerous - one does not preclude the other. firejail strips many environment variables out of the environment passed to the child process, so that helps a bit.

I guess, fundamentally, I'm not quite sure what your point is anymore.

[smitsohu]

Regarding the original issue, I still wonder if there could be another way than disabling the networking features altogether.

For example, it might be possible to save the current ipfilter configuration into a file before the sandbox process is created, and then always apply this firewall in the new net namespace. This could be made configurable in firejail.config.