Authorized clients

[Maarten Baert]

On 09/01/14 21:54, Martin Peres wrote:
> The worse thing that can happen is an application running with the
> user's uid grabbing and sending periodical screenshots to a distant
> server running OCR and waiting for you to enter your bank details on
> amazon.com. As for how this application got installed in the first
> plase, do I really have to list all the ways or can we both agree this
> is out of scope?
Is that the worst case scenario you can come up with? :D

Let me help:
- The attacker has installed a Firefox plugin that sends him a copy of
all forms that you fill out.
- The attacker has messed with your PATH and has installed an infected
Firefox binary in a folder you own, and you're running that instead of
the real firefox, without realizing it.
- The attacker has messed with your init files and you are actually in a
chroot that he set up.
- The attacker has created a virtual machine that looks just like your
real computer, and he configured it to launch automatically, in fullscreen.
- The attacker has installed something like wayland-keylogger
<https://github.com/MaartenBaert/wayland-keylogger> that sends him a
list of all keys you pressed.
- The attacker is watching /run/user/1000 with inotify so he can quickly
open any files that appear there and if he is lucky, he gets access to
some SHM buffers.
- The attacker has renamed /run/user/1000/wayland-0 to something else
and is running his own Wayland proxy that now listens on
/run/user/1000/wayland-0. He uses this proxy to do a MITM attack on all
Wayland applications.

All these can be done right now, no screenshot API needed ;). I'm sure I
can come up with more attacks if I you give me some time.

How do I mitigate this? Most of them can be stopped with Android-style
sandboxing. The one with the VM relies on social engineering and is
harder to avoid, but you could do what browsers do with fullscreen
requests - show a big and obvious warning that the application is being
displayed in fullscreen. Or by making the fullscreen interface
restricted as well. The fullscreen interface is starting to look far
more dangerous than the screenshot API, actually.

> I'm a big fan of these permission-set. I see them as the only way for
> a user to know what is going on. The permission set is a contract that
> a user either accepts or refuses. However, and we need to be very
> clear about this, no other application should be able to (ab)use the
> right of this application unless there is a direct consent of the user
> (and this is getting sketchy).
And this is actually pretty easy once you have sandboxing. The
screenshot program has access to the screenshot API and your files
(because it needs to save the screenshot somewhere). The screenshot
program allows fully automated screenshots, but they always end up in a
fixed 'Screenshots' location (maybe ~/Pictures/Screenshots). Untrusted
applications will obviously NOT get access to your files, because many
of those files are likely private. Applications that aren't trusted will
only get access to their own folder (maybe
~/.local/share/someapplication/). The attacker can trigger screenshots,
but can't get the automated screenshots from the 'Screenshots' folder,
and he can't force the user to save them to a folder that he has access
to. Problem solved.

> UAC is a piece of shit. Even as a security engineer, I cannot make a
> good decision because they just basically say "I need more privilege,
> do you agree?".
> Because users don't seem to care anymore, the little security benefit
> it could have renders the whole system useless. UAC is just proving
> that an MLS security policy ultimately resolves into running
> everything into the highest privileged mode.
It's nice to see that we can at least agree on that :P.

Maarten Baert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140109/56fef1b8/attachment.html>