<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 09/01/14 21:54, Martin Peres wrote: </div> <blockquote cite="mid:52CF0C8F.1090606@free.fr" type="cite">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? </blockquote> 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 <a href="https://github.com/MaartenBaert/wayland-keylogger">wayland-keylogger</a> 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. <blockquote cite="mid:52CF0C8F.1090606@free.fr" type="cite">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). </blockquote> 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. <blockquote cite="mid:52CF0C8F.1090606@free.fr" type="cite"> 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. </blockquote> It's nice to see that we can at least agree on that :P. Maarten Baert </body> </html>