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!

XSM

[(Anonymous)]

It's worth noting that X has supported pluggable security modules for some time now. IIRC, though, the only useful implementation is for SELinux, and is BYO policy.

[(Anonymous)]

This is the kind of problems that all linux x11 distro have in this years and that we all have lived with?

[(Anonymous)]

X11 has a way to avoid this in the form of untrusted clients. This feature has been neglected but if slightly adapted and used correctly, could complete avoid this issue. The reason it has been neglected is that all applications which run under the same uid can read each other's data anyway - so this kind of security never existed under Linux / UNIX (or other OSs) anyway, for reasons entirely unrelated to X. So activating it in X wouldn't really have helped.

[(Anonymous)]

thanks a lot for your clear reply

[(Anonymous)]

Only one Ubuntu OS is using X11 right now and that will change with the next release.

[(Anonymous)]

(a) that "only" OS happens to be the most widely used one by far
(b) saying "X is secure" when you mean "The next release of X which will be out in six months (or two years, if you only consider LTS) will be secure" is not misleading?

[(Anonymous)]

@ (a) You mean the server? That does not have X11...

[(Anonymous)]

Built the snap succesfully with your instructions but can't get it to run. Running /snap/bin/xevilteddy.xteddy says:
xteddy: Cannot connect to X server :0

Any clues? Running fresh updated install of 16.04 on virtualbox.

[(Anonymous)]

Trying to run xteddy outside the snap opens it up but within a few seconds it dumps core:

xteddy: malloc.c:2395: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.
Aborted (core dumped)

The Horror!

[(Anonymous)]

Oh no! An application running in a snap can do the *exact same thing* any other application running on the system can do! The world is ending! The world is ending!

Y'know, unless snapd runs the equivalent of `xauth generate $DISPLAY . untrusted` before it runs the application itself.

Re: The Horror!

[(Anonymous)]

Yes, but the point is that Canonical was touting Snaps as being more secur

"The security mechanisms in snap packages allow us to open up the platform for much faster iteration across all of our flavours as 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."

Re: The Horror!

[(Anonymous)]

putting a sticky tape on the keyhole to my car is more secure than no sticky tape.

Canonical never claimed the benchmark of or the highest level of security.

It doesn't matter if i win by 1 point or 100 points winning is still winning.
like wise even 1% more secure is still technically more secure.

Re: The Horror!

[(Anonymous)]

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

Does that marketing speak sound like Canonical is limiting their claim in any way?

Sure doesn't to me.

Re: The Horror!

[(Anonymous)]

There is a huge difference. I use only two types of software: Packages that are in the Debian "main" archive or software I wrote myself. Forget about the latter.

The former can have backdoors, of course, but at least there is some kind of control. Because the packages are built from source code, backdoors can be identified, hopefully. The security level will be even better when reproducible builds are in place.

Snap and xdg-app seem to a way to distribute untrusted, maybe even proprietary, programs to otherwise free systems. No idea, why one would want that, but some of their security improvements are very good, e.g. sandboxing, no maintainer scripts...

Re: The Horror!

[(Anonymous)]

What's wrong adding independent proprietary app to free software?
There's nothing wrong with it. Its called democracy.

Re: The Horror!

[(Anonymous)]

Hello Democracy, this is Patrick.

Re: The Horror!

[(Anonymous)]

Hello democracy, this is Bob, I'm with Patrick.

bad system call

[(Anonymous)]

When I run this command:

/snap/bin/xevilteddy.xteddy

I didn't see any teddy bear, instead it displayed an error message.

bad system call

I didn't see any keystroke information in the terminal after typing in firefox.

Re: bad system call

[(Anonymous)]

This is what I did in 32 bit Ubuntu 16.04. But I got bad system call error.

sudo apt-get install git

git clone https://github.com/mjg59/xevilteddy

cd xevilteddy/

sudo apt-get install snacraft

sudo apt-get install libxtst-dev

snapcraft snap

sudo snap install xevilteddy_0.1*.snap

/snap/bin/xevilteddy.xteddy

[(Anonymous)]

I hadn't heard about snap until now. It seems to overlap with the goals of xdg-app. What are the differences? What do they have in common?

There once was a B2 X, if memory serves...

[(Anonymous)]

I used to run Trusted Solaris 7, to separate possibly-unfriendly customers, and it would happily put up windows with the category and security level shown, and refuse to copy between them if the recipient's credentials didn't dominate the sender's.

The category stuff would work well with SELinux, and I'd use it today if I could. The levels (Secret, Top Secret, etc) less so.

--dave collier-brown
davecb@spamcop.net

[(Anonymous)]

Seems like a solution would be to not let apps talk to X directly, but have them go through some type of mediator, that prevents them from doing malicious things. But maybe it's not possible to tell what's malicious and what's not...

Extra security risk?

[(Anonymous)]

I am a little confused, so snaps do not introduce any new security flaws into the Ubuntu system, they just dont offer any more protection than the standard .deb? So it is safe to download Ubuntu 16.04?

AppArmor / SELinux

[(Anonymous)]

Can we save the day combining Snap with AppArmor/SELinux?