Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Security Ubuntu Firefox Mozilla Open Source Operating Systems Privacy Software The Internet Linux Build News Technology

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

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.
This discussion has been archived. No new comments can be posted.

Turns Out That Snaps Are Not Secure In Ubuntu With X11

Comments Filter:
  • Huh? Snaps? (Score:3, Insightful)

    by Anonymous Coward on Friday April 22, 2016 @06:06AM (#51963069)

    Snaps for apps? What in the fuck

  • Better summary (Score:5, Informative)

    by isj ( 453011 ) on Friday April 22, 2016 @06:31AM (#51963135) Homepage

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

    • Re:Better summary (Score:5, Insightful)

      by serviscope_minor ( 664417 ) on Friday April 22, 2016 @06:52AM (#51963183) Journal

      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.

      • Re:Better summary (Score:5, Insightful)

        by markdavis ( 642305 ) on Friday April 22, 2016 @07:48AM (#51963343)

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

        • ...to push an agenda. An agenda to push something that isn't necessarily better.

          Well said.

        • 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... [ubuntu.com]

          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

      • by rastos1 ( 601318 )

        The fault is with snaps for not marking them as untrusted, ..

        This is unknown ground for me, so I have to ask: how can the client be marked as trusted/untrusted? (I assume that this is not something specific to snaps)

        • Re:Better summary (Score:4, Informative)

          by serviscope_minor ( 664417 ) on Friday April 22, 2016 @09:00AM (#51963607) Journal

          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.

          • by rastos1 ( 601318 )

            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.

            Can you be more specific? What is this mechanism? Is this about something like having access to X magic cookie stored in ~/.Xauthority? Environment variable? Can I mark /usr/bin/firefox as untrusted, but /usr/bin/xterm as trusted?

            • Can you be more specific?

              X SECURITY extension. The simplest way to access it is to forward X over SSH with the untrusted setting, but that simply sets up the server mechanism.

              • by rastos1 ( 601318 )
                It seems that is not going to work :-( See this post [cygwin.com]:

                Untrusted X11 forwarding was meant to be a way to allow logins to unknown or insecure systems. It generates a cookie with xauth and uses the Security extension to limit what the remote client is allowed to do. But this is widely considered to be not useful, because the Security extension uses an arbitrary and limited access control policy, which results in a lot of applications not working correctly and what is really a false sense of security. This i

                • Btw, since the extension is disabled/not present the ssh -X falls back to ssh -Y (untrusted forwarding) on most systems.

                  Huh interesting. I'm on stock ubuntu 14.04 and my tests showed it prevented xevilteddy from working. I'm not surprised though about GTK, it generally abuses the X protocol quite badly, and gets lots of things wrong. For example GTK programs frequently crash if I restart the system tray program. Skype never does and if you're doing worse than Skype, you fucked up badly!

      • Is this a fundamental problem with the packaging system, or because the package creator didn't set the appropriate options? Would it be solved by having snap have a default setting of untrusted?

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

    • False, snaps are not "meant for running in a container". Isolation (both from other snaps and to keep control over which devices and resources it can access) is achieved via other mechanisms, such as apparmor restrictions. Also, the entire snap is packaged as a squashfs, and all snaps are simply mounted read-only, so they can't modify each other's (or even their own) packaged files.

      Snaps also have access to a per-snap writable directory for user and runtime data, but again, they can't even see other snaps'

    • Snaps are Ubuntu's desperate attempt to be trendy and cool like those new kids with the phones and tablets.
      • I think they created them for M$ - and the new WinBuntu mess. (Likely an attempt to start milking software patents - government involvement? - they are a cartel. )

        The big point is using them will reduce the polish rate of software. When every package uses the different lib versions - software that depends on lib bugs don't get fixed. And the libs don't get updated - resulting in less secure systems etc.

        We don't really want bugs that depend on other bugs -- snap will reduce the long term quality of code.

  • by dominux ( 731134 ) on Friday April 22, 2016 @06:32AM (#51963141) Homepage

    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.

    • by Lumpy ( 12016 )

      I have been able to run standard apps in user land forever, this is NOT something new. you can easily compile and run an app in the restricted user directory as an X11 app and it cant go digging through the rest of the system.

      the hostile app can trash the user directly or try and fake them into giving it escalated privileges but absolutely anything that can display something on the screen or have read/write to the users directory can do that.

      • by dominux ( 731134 )

        naturally, but this is about the packaging. If you install a deb with sudo then you are running executable code that lives inside the deb with root privileges. With snap installation there is no postinst script or anything that runs as root as part of the install. You might run the snap installer as root, and that might process some commands in the snap, but it isn't running arbitrary code as root I think.

        • by Lumpy ( 12016 )

          With a statically compiled binary there is nothing to install. a single file that when launched does everything it needs and has everything it needs, eliminating the dependency hell that linux still suffers badly from.

          Honestly I still don't see any real reason for these.

          • by Uecker ( 1842596 )

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

        • by Uecker ( 1842596 )

          I always wanted a "secure deb" format which does not run maintainer scripts and only allows files to be installed in certain directories. Together with reproducible builds this could solve this problem. Containers are not great it terms of security because you risk having all the duplicated libraries. There are reasons people invented advanced packaging formats and those reasons do not simply go away now containers are the new hype...

      • Sorry but not in the slightest. If you don't have root access to the system you can only compile and run an app in the restricted user directory if you have the explicit blessing of a sys-admin who has done all the wonderful pre-work of ensuring you have all necessary libraries available for you. Beyond that you're SOL.

        • by Uecker ( 1842596 )

          You can always set up a local chroot environment with all necessary dependencies. Sounds difficult? For stuff which is properly packaged, there are fully automatic systems which do this for you... No root required.

          • Sounds difficult?

            ... we're talking about installing a frigging program. If you can't double click the damn thing and call it a day then yes, definitely too difficult.

            http://howfuckedismydatabase.c... [howfuckedi...tabase.com]

            • by Uecker ( 1842596 )

              I answered to your claim that you need a sysadmin to locally install software. This is not true. I am not sure if somebody made it double-clickable for idiots, but it would be easy to do without inventing a new package format.

  • by serviscope_minor ( 664417 ) on Friday April 22, 2016 @06:47AM (#51963165) Journal

    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.

  • Honestly this sounds like Snaps in general are horribly insecure on their own.

  • by LichtSpektren ( 4201985 ) on Friday April 22, 2016 @08:28AM (#51963485)
    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.
    • Re: (Score:3, Insightful)

      by C3lt ( 3644813 )

      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.

      • 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.
        • by C3lt ( 3644813 )

          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.

    • by Anonymous Coward

      And Wayland does the same thing.

      Not to mention the simple fact probably the #1 question for Ubuntu Server is "How do I install a GUI?"

      • And Wayland does the same thing.

        Not to mention the simple fact probably the #1 question for Ubuntu Server is "How do I install a GUI?"

        I don't think you know what you're talking about.

    • And Wayland has the same feature... No, bug... No, feature!! IT'S INSECURE AAAAAHHHHH!

    • If you run Ubuntu Server, you're not using X.org.

      Oh that's news to me, given you can add Xorg just like any other package. Why the assumption that every Ubuntu server doesn't have a GUI? There's even manual pages specifically for Ubuntu Server dedicated to telling you the *various* ways you can install Xorg on an Ubuntu server and comes with a nice list of packages that help administer servers via a GUI, and that Xorg and associated libraries get the same length of support in the LTS release as the other packages do.

  • X11 programs can see other programs' events. That's even true if I install the program from a .deb or a tarball, no? So WTF does this problem have to do with a package format?

    (Oh, and if calling me ignorant/lazy or saying LMGTFY helps you explain it, fine. I'll take your assholiness as long as you have answers.)

    • X11 programs can see other programs' events.

      By default, yes, but not if they're not authorised.

      That's even true if I install the program from a .deb or a tarball, no?

      Yes, certainly.

      So WTF does this problem have to do with a package format?

      Well, the packages are supposed to be for sandboxed stuff, as far as I can tell, so you can run them without risking compromising your machine. It's a pretty poor sandbox if it blithely gives X11 access to the programs at the most trusted level, as opposed to running them

  • Seriously, i don't know what motivates Canonical to reinvent the package manager.

"An open mind has but one disadvantage: it collects dirt." -- a saying at RPI

Working...