OpenSnitch can not protect against hostile X11 clients

[xorgy]

If the process initiating the connection has access to the user's X11 session, it can simply whitelist itself either before or after attempting to connect. If OpenSnitch stops the process before displaying the prompt, the application can still have whitelisted itself ahead of time.

[evilsocket]

Hey @xorgy thanks for reporting this. Yes we know there are a few limitations to the type of security the software can offer to the user, as described in the README, this is still mostly PoC to see if it's doable and how.

If we consider a malicious process (thus, previously "implanted"), it's pretty much game over from a lot of points of view if you only rely on OpenSnitch for the security of your computer :)

Also, finding a relatively safe to use IPC mechanism between the daemon and the UI is not trivial, again, we're hacking code together to see if we can find a solution somehow :)

We're open to ideas ... ? :)

[evilsocket]

Hey @xorgy thanks for reporting this. Yes we know there are a few limitations to the type of security the software can offer to the user, as described in the README, this is still mostly PoC to see if it's doable and how.

If we consider a malicious process (thus, previously "implanted"), it's pretty much game over from a lot of points of view if you only rely on OpenSnitch for the security of your computer :)

Also, finding a relatively safe to use IPC mechanism between the daemon and the UI is not trivial, again, we're hacking code together to see if we can find a solution somehow :)

We're open to ideas ... ? :)

[xorgy]

Sorry if I came off as judgemental. This just came to mind very quickly when I found this (very cool) project, started wondering how one could work around this and I'm realizing that it's really hard.

[xorgy]

Sorry if I came off as judgemental. This just came to mind very quickly when I found this (very cool) project, started wondering how one could work around this and I'm realizing that it's really hard.

[evilsocket]

No worries, I totally got your intent ;) Yes, it is hard ... that is why I strongly believe using just one software is not the solution, but using X good softwares together, maybe is.

I'll leave this open, never say never! 👍

[evilsocket]

No worries, I totally got your intent ;) Yes, it is hard ... that is why I strongly believe using just one software is not the solution, but using X good softwares together, maybe is.

I'll leave this open, never say never! 👍

[xorgy]

Maybe we need some form of XSnitch to allow users to whitelist X clients which should be doing input spoofing (such as accessibility tools, voice controlled mouse movement etc.). Seems like heaps of work in itself, since if the store is accessible to the user whose processes may be untrusted, then it becomes pointless again.

[xorgy]

Maybe we need some form of XSnitch to allow users to whitelist X clients which should be doing input spoofing (such as accessibility tools, voice controlled mouse movement etc.). Seems like heaps of work in itself, since if the store is accessible to the user whose processes may be untrusted, then it becomes pointless again.

[adisbladis]

@xorgy There is no way to solve this using X11, that protocol was not designed with security in mind at all..
This is one of the pain points Wayland addresses.

On X11 you can pretty much tell any window to do anything you want and everything is trusted by default. This security situation on X11 is absolutely horrible..

Martin Gräßlin (author of the KDE window manager Kwin) occasionally writes on this subject and it's quite interesting:
https://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/

I wouldn't say this is an issue we can solve from the Opensnitch side of things.. The only way forward is Wayland which is actually designed with security in mind.

I have not personally tested running Opensnitch on Wayland but it should work fine considering we are just using Qt5 without any X11 specifics.

[adisbladis]

@xorgy There is no way to solve this using X11, that protocol was not designed with security in mind at all..
This is one of the pain points Wayland addresses.

On X11 you can pretty much tell any window to do anything you want and everything is trusted by default. This security situation on X11 is absolutely horrible..

Martin Gräßlin (author of the KDE window manager Kwin) occasionally writes on this subject and it's quite interesting:
https://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/

I wouldn't say this is an issue we can solve from the Opensnitch side of things.. The only way forward is Wayland which is actually designed with security in mind.

I have not personally tested running Opensnitch on Wayland but it should work fine considering we are just using Qt5 without any X11 specifics.

[adisbladis]

Maybe the solution here is simply to document that X11 is insecure and that Opensnitch can't protect against X11 clients?

[adisbladis]

Maybe the solution here is simply to document that X11 is insecure and that Opensnitch can't protect against X11 clients?

[knowak]

For those of us who are still stuck on X11, an out-of-band solution might work, e.g. have the UI on your phone and talk with the server. Or a silly arduino hardware device. Or whatever that gives you a UI bypassing X11.

As @evilsocket said you should try hard not to run a malicious process on your account anyway. Better to use a VM if you're testing something new and suspicious.

Other than that, Linux security is not there yet.

[knowak]

For those of us who are still stuck on X11, an out-of-band solution might work, e.g. have the UI on your phone and talk with the server. Or a silly arduino hardware device. Or whatever that gives you a UI bypassing X11.

As @evilsocket said you should try hard not to run a malicious process on your account anyway. Better to use a VM if you're testing something new and suspicious.

Other than that, Linux security is not there yet.

[xorgy]

@adisbladis I'm aware that it's not possible to solve this properly on X11 as it stands, but an extension could be sufficient. I work on Wayland almost exclusively since I use so few GUI applications, but I don't think it's going to be standard until maybe 2019.

That said, with XWayland, having OpenSnitch on Wayland directly would definitely be sufficient to isolate it from X protocol oversights. GNOME's wayland session works pretty well these days.

[xorgy]

@adisbladis I'm aware that it's not possible to solve this properly on X11 as it stands, but an extension could be sufficient. I work on Wayland almost exclusively since I use so few GUI applications, but I don't think it's going to be standard until maybe 2019.

That said, with XWayland, having OpenSnitch on Wayland directly would definitely be sufficient to isolate it from X protocol oversights. GNOME's wayland session works pretty well these days.

[cwh1te]

Personally, I value this project more for privacy than security. I like to know what is trying to make connections and to where. For example, it can help identify and block the spyware that Canonical likes to include in their distribution.

I feel like a lot of other attack models would need to be addressed before the GUI could be considered a primary vulnerability of this project. Right now a malicious process can simply kill the daemon and go about its business. Similar to what @evilsocket said, you shouldn't rely on any one tool to protect you if you're running untrusted (potentially malicious) code.

[cwh1te]

Personally, I value this project more for privacy than security. I like to know what is trying to make connections and to where. For example, it can help identify and block the spyware that Canonical likes to include in their distribution.

I feel like a lot of other attack models would need to be addressed before the GUI could be considered a primary vulnerability of this project. Right now a malicious process can simply kill the daemon and go about its business. Similar to what @evilsocket said, you shouldn't rely on any one tool to protect you if you're running untrusted (potentially malicious) code.

[ei8fdb]

@xorgy I'm going to try and add some explanation into the README.

I understand the technical meaning of the 1st line in your 1st message above. (Although, I don't understand what happens to allow it to happen!):

process initiating the connection has access to the user's X11 session, it can simply whitelist itself either before or after attempting to connect.

I'm trying to think of a use case to explain this behaviour. Would this be valid -

1. A user clicked on a HTTP link in an email
   (The web browser hasn't been used before)

2. The web browser is opened to render the link
   (I guess at this point the web browser can do what you mentioned "simply whitelist itself either before or after attempting to connect")

Outcomes:

• the web browser whitelists itself (without the users knowledge)
• the web browser opens
• the URL is rendered

Any thoughts? If this is incorrect, could you help me to get a better example?

[ei8fdb]

@xorgy I'm going to try and add some explanation into the README.

I understand the technical meaning of the 1st line in your 1st message above. (Although, I don't understand what happens to allow it to happen!):

process initiating the connection has access to the user's X11 session, it can simply whitelist itself either before or after attempting to connect.

I'm trying to think of a use case to explain this behaviour. Would this be valid -

1. A user clicked on a HTTP link in an email
   (The web browser hasn't been used before)

2. The web browser is opened to render the link
   (I guess at this point the web browser can do what you mentioned "simply whitelist itself either before or after attempting to connect")

Outcomes:

• the web browser whitelists itself (without the users knowledge)
• the web browser opens
• the URL is rendered

Any thoughts? If this is incorrect, could you help me to get a better example?