Circumventing Ubuntu Snap confinement

[mjg59]

Ubuntu 16.04 was released today, with one of the highlights being the new Snap package format. Snaps are intended to make it easier to distribute applications for Ubuntu - they include their dependencies rather than relying on the archive, they can be updated on a schedule that's separate from the distribution itself and they're confined by a strong security policy that makes it impossible for an app to steal your data.

At least, that's what Canonical assert. It's true in a sense - if you're using Snap packages on Mir (ie, Ubuntu mobile) then there's a genuine improvement in security. But if you're using X11 (ie, Ubuntu desktop) it's horribly, awfully misleading. Any Snap package you install is completely capable of copying all your private data to wherever it wants with very little difficulty.

The problem here is the X11 windowing system. X has no real concept of different levels of application trust. Any application can register to receive keystrokes from any other application. Any application can inject fake key events into the input stream. An application that is otherwise confined by strong security policies can simply type into another window. An application that has no access to any of your private data can wait until your session is idle, open an unconfined terminal and then use curl to send your data to a remote site. As long as Ubuntu desktop still uses X11, the Snap format provides you with very little meaningful security. Mir and Wayland both fix this, which is why Wayland is a prerequisite for the sandboxed xdg-app design.

I've produced a quick proof of concept of this. Grab XEvilTeddy from git, install Snapcraft (it's in 16.04), snapcraft snap, sudo snap install xevilteddy*.snap, /snap/bin/xevilteddy.xteddy . An adorable teddy bear! How cute. Now open Firefox and start typing, then check back in your terminal window. Oh no! All my secrets. Open another terminal window and give it focus. Oh no! An injected command that could instead have been a curl session that uploaded your private SSH keys to somewhere that's not going to respect your privacy.

The Snap format provides a lot of underlying technology that is a great step towards being able to protect systems against untrustworthy third-party applications, and once Ubuntu shifts to using Mir by default it'll be much better than the status quo. But right now the protections it provides are easily circumvented, and it's disingenuous to claim that it currently gives desktop users any real security.

Comments

[(Anonymous)]

Are their not checks on this sort of thing when uploading to app store ?

[(Anonymous)]

Too hard. Canonical have always been chronically under-resourced for what they're trying to do... they certainly don't have the ability to do a careful line-by-line security analysis of every single app that's uploaded to the store. That's the point of having sandboxing in the first place... even if someone does sneak in something that snoops on key presses, the sandbox prevents it from functioning.

[(Anonymous)]

It was more wondering what the automated review catches. From developer page

"Your snap has now been uploaded to the store, and is now undergoing an automated review. You'll be emailed when the review has completed, at which time you can visit the MyApps site and publish your snap!"

I suppose bypassed with

" Note that if you uploaded a new version for an already-published snap, your update will be automatically published."

[(Anonymous)]

you are aware that review and publish are two separate things, right ?
while all uploads are always automatically reviewed, the first publishing is a manual step to make sure you don't put something live by accident.

[(Anonymous)]

Yeah, so you just have to publish a harmless app first, then push a malicious update that will be automatically approved.

[(Anonymous)]

No, you push an update that will be reviewed, and if approved, will automatically be published.

[mjg59]

It'd be pretty easy to avoid the obvious cases - block anything that calls XSelectInput() or XTestFakeKeyEvent(), but people aren't obliged to call the library functions to do this. You could write some pretty obfuscated code that would end up having the same result, and that would filter through any kind of checks that could reasonably be implemented. It's a hard problem - the only way to really handle it is to design the technology such that these attacks aren't possible in the first place.

[(Anonymous)]

The code does not have to be very complicated -- download something over the network and execute it.

[(Anonymous)]

That just means that an attacker doesn't do the nefarious thing immediately, but rather when some condition applies. Any attacker will want to do that anyway, to avoid being flooded with useless crap.

wasted reading

[(Anonymous)]

x has always been this way. this isnt news, its clicky bait- and rather predictable. the concept of a repo having trust in the maintainer in debian systems is well known. for all these years an evil teddy could have been placed in a debian repo and if not caught immediately, then fleshed out by users.

running click on x is no different. its merely a new format waiting for mir which will fix this old x problem. its also a wonderful concept i intend to implement with tcl scripts.

and im not even evil or teddy..

Re: wasted reading

[(Anonymous)]

yes, this sort of thing is possible today in most every X11-based linux distro (modulo the protections provided by a few things like subgraph or qubes). It also applies when you use ssh with XForwarding to run remote applications (the server can read and inject input into all of your local X windows. It also applies when a program gets exploited: attackers don't need a privilege escalation exploit to get root if you already have a root shell open in another window (or if they can persist long enough for you to open one eventually).

What is new news is that canonical claims (linked under the word "claim" in this post) "snap applications are isolated from the rest of the system. Users can install a snap without having to worry whether it will have an impact on their other apps or their system". This is misleading. So thank you, Matthew, for bringing attention to this!