On Thu, Jan 9, 2014 at 7:05 PM, Martin Peres <martin.pe...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jasper
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
