Slashdot Mirror

← Back to Stories (view on slashdot.org)

Turns Out That Snaps Are Not Secure In Ubuntu With X11 (softpedia.com)

Posted by BeauHD on from the insecurity-about-security dept.

prisoninmate quotes a report from Softpedia: According to Matthew Garrett, a renowned CoreOS security developer, and Linux kernel contributor, Canonical's new snap package format is not secure at all when it is used under X.Org Server (X Window System), which, for now, it is still the default display server of the Ubuntu 16.04 LTS (Xenial Xerus) operating system. The fact of the matter is that X11's old design is well-known for being insecure, and Matthew Garrett took the time to demonstrate this by writing a simple snap package that can steal data from any other X11 software, in this case anything you type on the Mozilla Firefox web browser. As more developers will provide snaps for their apps, Canonical needs to do something about the security of snaps in Ubuntu when using X11 or switch to the Mir display server. In the meantime, the security of snaps remains unaffected for the Ubuntu Server operating system, which is usually used without a display server. Canonical has officially released Ubuntu 16.04 LTS, which is now available to download for those interested.

17 of 133 comments (clear)

  1. Huh? Snaps? by Anonymous Coward · · Score: 3, Insightful

    Snaps for apps? What in the fuck

    1. Re:Huh? Snaps? by arth1 · · Score: 3, Funny

      Snaps is very useful when dealing with apps.

  2. Better summary by isj · · Score: 5, Informative

    "snaps" is a new package format for applications on Ubuntu. It is basically a package with dependencies, bundled together and meant for running in a container (docker or lxc I suppose?) which means that the OS is protected from it.

    However, since the application has access to X11 window server it has access to the facilities in it including monitoring keystrokes and mouse gestures sent to other X11 applications. So essentially a "snaps" can be a trojan keylogger.

    The article/blog does _not_ explore if X11's "untrusted client" feature would help.

    1. Re:Better summary by serviscope_minor · · Score: 5, Insightful

      The article/blog does _not_ explore if X11's "untrusted client" feature would help.

      I did, well, using SSH's one and yes it does help just fine.

      To repeat:

      xevilteddy does not work if you treat it as an untrusted client.

      The fault is with snaps for not marking them as untrusted, not with X11 for allowing trusted clients. In other news, if you run a compositor as trusted then that too can grab all keystrokes. In other other news if you treat the Wayland compositor as trusted it can grab keystrokes too.

      Trusted clients can do trusted shit. This is not especially exciting. It is good to know that ubuntu aren't treating snaps as untrusted though. That's bad, but it's the fault of snaps, not the fact that X treats them as trusted when told to.

      --
      SJW n. One who posts facts.
    2. Re:Better summary by markdavis · · Score: 4, Insightful

      +1 THANK YOU. Yet another unfounded attack on X11 to push an agenda. An agenda to push something that isn't necessarily better.

    3. Re:Better summary by serviscope_minor · · Score: 3, Informative

      No, it's a general thing with program security. You can mark programs as trusted or untrusted using a variety of mechanisms.

      For example, you can run programs as root (very truseted as they get access to everything), as a normal user (moderately trusted: they can't muck up the whole machine, but they can muck up the user), as a guest user (same, but there's nothing much to muck up) and the using various things like cgroups/jails to sandbox it further.

      X has a mechanism to say a client is untrusted in which case it's not allowed to mess with windows that it doesn't own. Trusted clients can mess with each other's windows.

      --
      SJW n. One who posts facts.
    4. Re:Better summary by columbus · · Score: 2

      Guys, I think you're getting the intent of the story wrong. It's not an X11 security problem. It's primarily a PR problem for Ubuntu & secondarily, it's a security problem for snaps.

      Ubuntu has been promoting snaps as a more secure way of packaging
      https://insights.ubuntu.com/20...

      And the research that Matthew Garret has done has demonstrated that the security provided by the snaps framework is not terribly good. So that's a PR problem for Ubuntu if one of the primary features they are advertising is demonstrated not to be fit for purpose. Personally I don't think that Ubuntu cares much about the security aspect of snaps. I think they care more about convenience and monetary gain. And I don't have a problem with either of those motivations.

      in.re. convenience: The apt package management system has many benefits, but it has problems with software development projects that run at different cadences. Remember when Ubuntu 8.04 LTS shipped with Firfox 3 beta? The apt system would lock you into the beta version for the life of the release. With snaps, you could upgrade just one application (like Firefox or Libre Office) without upgrading all of the libraries on your OS or upgrading your OS as a whole. I think that's pretty useful.

      in.re. monetary gain: Canonical has poured a lot of effort and money into Linux over the course of a decade. I wouldn't mind seeing them reap the rewards of their efforts in a monetary form. It looks like they want to run an AppStore to do this & an app-store just won't integrate well with apt. But it will with snaps. So good on them.

      I would just like them to be a bit more open about their motivations. I don't think the release of snaps has much to do with a desire for security, at least in a desktop environment.

      --
      friends don't let friends teleport drunk
  3. woah, just a minute by dominux · · Score: 4, Insightful

    If you have some software in a deb, and put that software in a snap, then you have increased your security slightly, but not much. If that software is then put on a Wayland or Mir desktop then you have increased the isolation of it a lot.
    If your software is in a .deb then you ran it's installation script as root. If it was bad then you are toast already.
    Snaps can be installed without being root, into the user home directory. This is an increased level of ability to run untrustworthy software. This whole exercise is so that open source systems can run untrustworthy proprietary paid for apps without the untrustworthy apps being a huge risk to the peer-reviewed code and other proprietary apps.
    Snaps are *not* a step backwards, but they don't get all the way to the end goal by themselves. They may have been over-sold slightly by Canonical because they are mainly for the phone which runs Mir, plus things like Firefox on the desktop which are trustworthy.

    1. Re:woah, just a minute by Uecker · · Score: 2

      I agree. Containers essentially have the same properties of statically compiled binaries. The reason they exist is that you can just put existing stuff in there easily without having to refactor. There are just another rotation of the wheel of software complexity (you nicely separate stuff, then you add a lots of interfaces because things need to interact, then you end up having a mess so you create another higher level of separation, etc.)

  4. Not quite that simple. by serviscope_minor · · Score: 5, Insightful

    Does XEvilTeddy still work over an SSH connection with ssh -X instead of ssh -Y? If not, then the problem is rather easily solvable, and the means to solve it have been there for years.

    Let me check...

    git clone configure make autoconf apt-get install blah blah oh wow a separate package for xtest wow you managed to save posivily kilobytes for the 0 people who would install x11-dev but not xtest-dev blah blah make oh ffs it needs to be installed this is annoying. Oh hey didn't check your code paths, build build blah

    DONE!

    OK...

    ssh 127.0.0.1 -o 'ForwardX11Trusted no'

    aaaand...

    Oh look it doesn't work.

    So no, X11 is, yet again not fundementally broken. It has a "default allow" policy, but mechanisms have existed for decades to add security to it. The main failing for ubuntu was not enabling the long-established security protections.

    --
    SJW n. One who posts facts.
  5. The OS will be protected from it anyway... by Viol8 · · Score: 2

    ...so long as its not running as root. That is kind of the whole point of OS's with user priviledge levels, file system permissions and protected virtual memory. Thats not what containers are for. I could explain but just go google FFS.

  6. I don't see the big deal by LichtSpektren · · Score: 4, Informative

    If you run Ubuntu Server, you're not using X.org. If you're running Ubuntu 16.04 on the desktop, you're probably not using any snap packages (except maybe Firefox). By the time desktop applications start to be packaged in snappy form, Ubuntu will be using Mir as the display server instead of X.org.

    1. Re:I don't see the big deal by C3lt · · Score: 3, Insightful

      By the time desktop applications start to be packaged in snappy form, Ubuntu will be using Mir as the display server instead of X.org.

      Why do you believe this to be true? 16.04 doesn't use Mir and is an LTS, people will be using it for years, and it is not even guaranteed yet that 16.10 will use Mir by default.

    2. Re:I don't see the big deal by C3lt · · Score: 2

      Since, as you said, 16.04 is LTS, that means that the .DEB packages which are in place now aren't going anywhere. The only packages that currently exist in Snappy Core are enterprise server things.

      I don't understand the relevance of your comment. 16.04 supports Snaps, uses X by default, and will be around long enough that snaps will be available for people to download and use within its lifetime, right? If that statement is true, then there is a security risk.

  7. Re:Misleading by Uecker · · Score: 4, Informative

    X11 is not fundamentally insecure. In fact, X11 had the security infrastructure to shield clients from each other for a long time. It is just not used and also has been neglected (people did not fix the bugs in applications which I filed - so some applications do not run as untrusted clients). The reason for this is that there was almost no point using it before, because different processes of the same user are not shielded against each other on Linux anyway, so there is nothing gained by doing it at the X level (maybe there is now with containers - although this is the wrong approach: containers are a security nightmare because the duplicate all library code). With respect to clients/processes of the same user, X is fundamentally much more secure than Linux has ever been - because at least in principle it had the infrastructure to protect clients from each other (although rudimentary and neglected).

  8. Re:slashdot's ubuntu coverage by F.Ultra · · Score: 3, Interesting

    Because System V init does not do process monitoring and service restart upon crash the MySQL people decided to write their own work around using shell scripts, this is why you can see a mysqld_safe process running as well as the regular mysqld on non systemd systems. mysqld_safe is a 1117 line bash script and /etc/init.d/mysql (the System V init script for MySQL) is a further 197 lines of bash:

    root@sql:~# wc /usr/bin/mysqld_safe
    1117 4059 31801 /usr/bin/mysqld_safe
    root@sql:~# wc /etc/init.d/mysql
    197 777 5742 /etc/init.d/mysql

    Since this monitoring is done by a bash script it's not always 100% safe, I have on several occasions encountered situations where a "service mysql stop" returned with OK but that the mysqld_safe process refused to die, noticed that mysql where stopped and restarted it behind the scenes resulting in upgrades going to complete shit among other things.

    Since all that shit is now instead handled properly by systemd due to i.e control groups the unit file for MySQL is extremely simply and straightforward:

    # MySQL systemd service file

    [Unit]
    Description=MySQL Community Server
    After=network.target

    [Install]
    WantedBy=multi-user.target

    [Service]
    User=mysql
    Group=mysql
    PermissionsStartOnly=true
    ExecStartPre=/usr/share/mysql/mysql-systemd-start pre
    ExecStart=/usr/sbin/mysqld
    ExecStartPost=/usr/share/mysql/mysql-systemd-start post
    TimeoutSec=600
    Restart=on-failure
    RuntimeDirectory=mysqld
    RuntimeDirectoryMode=755

    No more mysqld_safe siliness and also everything down to a 20 line unit file that is a hell of a lot easier to parse manually than the old init scripts.

    So I do hope that people will now see that the AC:s that keep posting these lies are in fact just lying trolls, not a single one of them have ever read the MySQL unit file and not a single one of them have ever run MySQL on a distribution using systemd.

  9. Re: slashdot's ubuntu coverage by i.kazmi · · Score: 2

    I definitely do not like Systemd but there is absolutely nothing wrong with MySql unit files in Ubuntu (typing this on Kubuntu 15.10 with Kubuntu 16.04 running in a vm under virtual box, both the guest and the host have the complete LAMP stack running)...that user was either trolling or had no idea what they were talking about and were rightly buried.