Authorized clients

[Jasper St. Pierre]

On Thu, Jan 9, 2014 at 7:05 PM, Martin Peres <martin.peres at free.fr> wrote:

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

My question was not meant to be taken in a vaccuum. In fact, quite the
opposite. My question was about thinking whether it made sense to do access
control at the Wayland level, or at the


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

Here, run this program. You can audit it, it won't steal your credentials,
but it doesn't take a screenshot of the desktop, and is fairly convincing.
It would probably even fool me. It's X11, simply because that's easier than
writing a raw Wayland app at this point. It doesn't rely on any
insecurities of X11.

Build instructions are on top:
https://gist.github.com/magcius/835501bc2728be83587f

It was made in a hurry, so the main tell: the blinking cursor, I couldn't
deal with. Somebody with more than an hour on their hands might be able to
do something more with this concept.


>>  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 ;)
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



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