[VULNERABILITY] Application path manipulation.

[evilsocket]

Hi, since you're solely relying on the /proc filesystem in order to correlate connections to pids and pids to application paths, your software is vulnerable to path manipulation.

Long story short, let's say the user whitelisted the chrome process, from my malicious payload I could just:

memcpy(argv[0], "/path/to/trusted/chrome\0", ... )

To bypass the Subgraph application firewall since its info mapped to /proc would be altered.

I suggest instead to use fexec kernel extension to monitor for executions from userland and build your pidCache that way ( example python code )

[brl]

This isn't really a vulnerability since the threat model of the firewall does not include an attacker who can already run arbitrary code on the host. We do not claim that our application firewall can defend against malicious local code execution (and neither should you [*]). Since this misunderstanding happens so frequently, we need to do a better job of communicating it in the documentation.

1) The purpose of the firewall is not to defend against attacks at all, even though it is occasionally accidentally helpful for this purpose:

http://news.softpedia.com/news/zero-day-ffmpeg-vulnerability-lets-anyone-steal-files-from-remote-machines-498880.shtml

2) The reason the firewall exists is to provide awareness to the user about applications which, for non-malicious purposes, are making connections to the network and to enforce policy to prevent applications from network activity which would be unsafe. This is especially important in our case where we allow users to send network traffic over Tor by default.

3) Our firewall is not vulnerable to the technique exactly as you propose it since we use /proc/PID/exe to map the rules to the executable. Then again we have recently added an exception to improve usability for rules based on script interpreters such as Python. So, the example would work with Python but not with Chrome. As always, the best proof of concept code to send along with these bug reports is code that works :smiley:

4) Even though defending against this is out of scope and not a realistic general objective we may consider also implementing the kprobe technique, but as you already know this introduces a new problem of how to handle applications which are started before the firewall.

[*] If you are going to assume that an attacker can execute code locally then opensnitch is still vulnerable to at least 3 more easy general bypass techniques, not including just using the network access of the application you originally exploited (ie in shellcode). See if you can find them all. :trollface:

[evilsocket]

Our firewall is not vulnerable to the technique exactly as you propose it since we use /proc/PID/exe to map the rules to the executable.

I know, I thought you guys were smart enough to get my example and figure the actual PoC out, since this page is public I didn't want to publish the working code.

Even though defending against this is out of scope and not a realistic general objective we may consider also implementing the kprobe technique.

Easy fix, so why not :)

but as you already know this introduces a new problem of how to handle applications which are started before the firewall.

In which case you can fallback to /proc ... it's not perfect, but it's an easy improvement IMHO.

If you are going to assume that an attacker can execute code locally then opensnitch is still vulnerable to at least 3 more easy general bypass techniques.

This is not a Subgraph FW / OpenSnitch comparision, mostly becaue OpenSnitch is, at its current state, just a python PoC which needs to be reimplemented from scratch in order to be slightly more secure than it is :)

While developing it, I just found a relatively easy way to improve connection->process lookup, I reminded about your project, I checked the code and I just gave you the hint.

Now it's up to you guys, if you prefer, just close this issue :)

if you are going to assume that an attacker can execute code locally then opensnitch is still vulnerable to at least 3 more easy general bypass techniques

Assuming code exec with same user as the UI:

1. Kill the UI -> free the IPC channel -> all packets have to be accepted now.
2. Write directly in the UI process memory area and fuck with it.
3. Replace the UI with a fake one which silently accepts everything.

Those are just the first 3 ideas I had, I'm sure there're plenty of other methods, we're working to prevent this stuff from happening.

But if sharing our methodologies with you creates such kind of criticism and bothering, just state it clearly and we won't ever open an issue again :trollface:

[brl]

This is not a Subgraph FW / OpenSnitch comparision

To be clear, I'm talking about ways to bypass Subgraph FW too. Like I said, we have good reasons to exclude claims that we can stop a local attacker.

Assuming code exec with same user as the UI:

Nope, no need to tamper with the firewall at all. Also no special privileges needed.

I reminded about your project, I checked the code and I just gave you the hint.

Oh you just got curious and remembered our project so you went and checked.

Actually, you cribbed your whole project off of our code including direct copy/paste of iptables rules and during your recent PR spree you didn't mention our project even once.

But if sharing our methodologies with you creates such kind of criticism and bothering

Remember when you complained publicly on twitter that we hadn't immediately fixed a bug that just said "Please fix on debian stable" with no further information provided even when we asked for it.

You disparaged our project in public unreasonably and then you copied our work without acknowledging it. How friendly do you expect me to be when the next interaction we have is that you show up and post [VULNERABILITY] in all-caps on our issue tracker for something we don't agree is in scope to try to prevent.

[evilsocket]

Nope, no need to tamper with the firewall at all.

We both know there are a lot of ways, like interfering with the IPC mechanism, DoSing the fw with packet fragmentation, using sidechannels, using udp, etc etc etc

Actually, you cribbed your whole project off of our code including direct copy/paste of iptables rules.

Please tell me how I copied a GO project into a Python project XD YES I copied your iptables rules (3 LoC, that's all I copied) ... but let me tell you what happened in reality since you look very confined into your own fantasy instead :D

I recently switched (after years) from macOS to Linux, I was searching for something like LittleSnitch and almost immediately found your project on GitHub.

I cloned it, I tried to compile it on my distro ( Ubuntu ... yeah i know ... ), it failed, I opened github to file an issue about that, I found another issue which never got a reply, I gave up and started working on my implementation on top of those 3 iptables rules .... OMG I'VE STOLEN 3 LINES OF YOUR CODE WHICH ARE JUST IPTABLES RULES, I'M SO EVIL ... cmon, take it easy dude.

Remember when you complained publicly on twitter that we hadn't immediately fixed a bug.

Yes I do remember.

with no further information provided

How hard can it possibly be just to verify yourself on a debian stable vm or docker instance? Come on, don't play word games on me, we both know you guys just didn't care enough :)

You disparaged our project in public unreasonably.

LOL I just said it can't be easily compiled/ported to other distros and that you guys don't give enough attention to issues ... this is an opinion and I have all the rights to have one.

then you copied our work without acknowledging it.

Again, I copied only 3 lines of 3 iptables rules, your project is in Go, mine in Python, there's no way I could have copied actual code and you know it.

How friendly do you expect me to be

As friendly as someone who realized I could have just wrote a blog post about it ( if harming your project's reputation was my interest, which is not ) but instead I just reported it ... yeah I know, sometimes I just put too much faith in humans.

you show up and post [VULNERABILITY] in all-caps on our issue tracker

As I already said, there's history of you not caring a lot about issues, so I thought that those caps would have caught your attention on something I thought it was worth it ... lol

for something we don't agree is in scope to try to prevent.

Just say "we don't agree is in scope to try to prevent" ?

Dude I have no idea what's wrong with you, it looks like for some reason you strongly believe I stole something from your project, that I want it to be shut down or god-knows-what ... I can assure you this is not the case, actually I fucking love your project and I would gladly switch to it and shut OpenSnitch down if there was a way for me to use it.

Calm down and keep it easy <3

[evilsocket]

TL;DR; I just reported you a problem, gave you the code I wrote to fix it for for free because I wanted to thank you and repay you of the 3 fucking iptables rules I took from your code weeks ago, and you're acting like a crazy dude ... just saying.

[Zerokami]

@brl

This isn't really a vulnerability since the threat model of the firewall does not include an attacker who can already run arbitrary code on the host

Please consider making it a threat model then, because your firewall could as well become the Comodo Firewall of Linux.

You seem to have developed the first application based firewall for Linux, which is quite a feat. I've been looking for one forever.

Linux not having n application based firewall and a HIPS firewall is one of the things that keep me from thinking Linux Desktop is not really usable

If Comodo Firewall could be bypassed by a non-UAC firewall, then it wouldn't be that popular.

A secure application based firewall that works on all distros is my wet dream.

Linux users just don't know the potential of app based firewalls cos there isn't much malware for Linux.

Remember UNIX has a root system for a reason. Non root users shouldn't be able to mess with stuff especially the firewall.

Please make it atleast so that sandboxed processes and non-root processes can't get internet without the users permission.

What if Microsoft said we can't do anything about software run by the computer and not implement UAC at all.

Please do it so that sandboxed processes and non-root user processes can't mess with the firewall.

Non-root processes and sandboxed processes bypassing a firewall is a threat. Linux is said to have good user seperation and security. Please consider anything that breaks this a threat model.