www. O S N E W S .com
News Features Interviews
BlogContact Editorials
.
Malware found in the Ubuntu Snap store
By Thom Holwerda on 2018-05-13 15:29:32

Oh, snap! Just because some packages are available to install directly from the Ubuntu Software Center doesn't make them safe. This is proved by a recent discovery of malware in some snap packages from the Ubuntu Snaps Store.

At least two of the snap packages, 2048buntu and Hextris, uploaded to the Ubuntu Snaps Store by user Nicolas Tomb, contained malware. All packages by Nicolas have since been removed from the Ubuntu Snaps Store, "pending further investigations".

I honestly did not expect anyone to care enough to upload malware to the Ubuntu Software Center. Good thing it got caught.

 Email a friend - Printer friendly - Related stories
.
Read Comments: 1-10 -- 11-14
.
Who caught this?
By leech on 2018-05-13 17:00:15
And this is why I stick with the distributions repositories. Also why I stick with Debian. Okay fine, that isn't the reason I stick with Debian over Ubuntu, just one of them. The software center is kind of crap. Just let me 'apt' all the things.

On a side note, I think flatpak mostly just has the hub, which links to the source code, it's just a simple build set up like PKGBUILD on Arch, if I recall. So less likely to get malware in it.

I think Snap on the other hand is meant more for commercial/proprietary/clos ed source packages, right?
Permalink - Score: 0
.
This is why we can't have nice things
By Morgan on 2018-05-13 19:59:28
I never used Snaps in Ubuntu, I've always been inclined to use apt in a terminal on Debian based distros, but this sucks for the credibility of the Snaps system and its team.

And for those who say this couldn't happen in their distro of choice: I once came across a bad Slackbuild in a third party Slackware repo. It was mostly harmless (it echoed an output that simulated the results of rm -rf / as a joke) but it proved why one should audit any Slackbuild script before blindly running it. If it could happen to Slackware, it could happen to any distro that supports third party packages, which is all of them that I know of.
Permalink - Score: 3
.
Really Malware is no supprise.
By oiaohm on 2018-05-14 01:47:22
Docker images have had malware for quite some time.

Snap being background services and desktop made it way more likely to be targeted.

I use flatpak with flathub repository. Flathub does build what they ship to your from source. They are not depending on random parties to upload safe binaries.

One of the reasons why Linux desktop is not targeted by malware much its that it hard work to get installed.
Permalink - Score: 0
.
Snap permissions
By flypig on 2018-05-14 08:54:21
It's important that in these cases the malware was a cryptocurrency miner, which can't be easily restricted using the current snap permissions model (at least, I don't see how). This is a relatively gentle wake-up call for the snap ecosystem. It could have been ransomware.

In theory snaps should be safer than software installed through something like apt that just grants root access to everything. Unfortunately the permissions don't seem to get flagged up to the user by the Software Centre when you install, and as this shows, tight permissions are still no substitute for manual review.
Permalink - Score: 4
.
RE: Who caught this?
By Vistaus on 2018-05-14 10:07:56
You need to be careful with the distro packages as well. I remember a couple of years ago that malware was found inside an IRC server package and it made its way into Fedora. So *theoretically* such compromised software could end up in Debian/Ubuntu archives as well.
Permalink - Score: 3
.
RE[2]: Who caught this?
By oiaohm on 2018-05-14 11:41:56
> So *theoretically* such compromised software could end up in Debian/Ubuntu archives as well.

https://tests.reproducible-builds...

Inside debian a lot harder. You would have to have the malware as public source code in most cases. Modified package is going to trip the reproducible build process.

You will also notice that Fedora picked up the reproducible processes after the issue. So you have less packages built by 1 party instead package is built by multi parties than each produced package is compared to see if they are identical. This is also a counter to a single build machine being breached.
Permalink - Score: 6
.
Comment by ahferroin7
By ahferroin7 on 2018-05-14 12:25:24
I find it particularly interesting that there are so many people people who seem to be taken completely by surprise by this. It's not like there's any kind of rigorous verification that the packages do what they say and no more, so this was going to happen eventually.
Permalink - Score: 4
.
Manpower issue
By laffer1 on 2018-05-14 13:15:21
In order to evaluate every package regularly, it takes significant work. Most projects do not have the resources to do that. At best, precompiled packages are a time savings for those that are willing to take the risk.

In order to do this, you need people volunteering with specific skills and a strong background in security. Scanning the software with existing tools may catch a few things.
Permalink - Score: 3
.
RE: Comment by ahferroin7
By Alfman on 2018-05-14 14:28:56
ahferroin7,

> I find it particularly interesting that there are so many people people who seem to be taken completely by surprise by this. It's not like there's any kind of rigorous verification that the packages do what they say and no more, so this was going to happen eventually.

Yeah, it doesn't matter if you are apple, google, microsoft, a linux distro, etc, these things do slip in. None of them have enough experts to comprehensively audit every piece of 3rd party code submitted to them. Furthermore a malicious hacker can foil automated defenses by only activating their malware after an app has been approved.

This is why sandboxing is important, it allows us to keep restraints on applications that are running without automatically giving them free reign over everything.
Permalink - Score: 3
.
RE[2]: Who caught this?
By FlyingJester on 2018-05-15 00:10:53
Or the time that the Chromium packages on Debian downloaded blackbox binaries that had the ability to listen in on your microphone?
Permalink - Score: 3

Read Comments 1-10 -- 11-14

No new comments are allowed for stories older than 10 days.
This story is now archived.

.
News Features Interviews
BlogContact Editorials
.
WAP site - RSS feed
© OSNews LLC 1997-2007. All Rights Reserved.
The readers' comments are owned and a responsibility of whoever posted them.
Prefer the desktop version of OSNews?