Authorized clients

[Martin Peres]

On 09/01/2014 23:57, Maarten Baert wrote:
>
> 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

Hey, don't twist his question and my answer ;) The question was IF our 
protocol is wrong. Remember, we aren't addressing the security of 
desktop here. We are looking for a way to provide a service 
(screenshots) and trying to find a way to make it as difficult as 
possible to misuse it. Right?
>
> 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.
Out of scope ;)
> - The attacker has installed something like wayland-keylogger 
> <https://github.com/MaartenBaert/wayland-keylogger> that sends him a 
> list of all keys you pressed.
No such thing possible. The wayland compositor gets the input from the 
kernel or from a virtual keyboard it launched itself. Then, it dispatchs 
the input to the right app, not any other app. We had been thinking 
about an app requesting all the keys as hot keys, but solutions have 
been found against that ;)

> - 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.
These two require MAC, we can't do anything about it. Anyway, this is 
again out of scope. We are talking about not abusing the feature we want 
to add!

>
> 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.

If you can craft a VM that looks like the desktop of the person you are 
hacking ... without being able to get visual information for it, you are 
real good. This attack just isn't practical. Stop using fear mongering 
just so people wouldn't mind "a little more". You're obviously smart, so 
instead of denying the problem, we could work on it.
>
>> 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.

You know, I actually implemented something like that with a research 
team, PIGA-OS. As nice as I think it is, you need to accept this is 
COMPLETELY out of the scope and has nothing to do with Wayland. Wayland 
should be as difficult to abuse as possible. Whatever MAC policy or 
system the future may hold, the protocol we'll be proposing should still 
be good!

If you don't understand that, think about all the languages or protocols 
that sounded ok a while ago and how painful it is to get rid of them now 
to replace them with more secure ones.
>
>> 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.

We agree on a lot of things ;)