Linked by Thom Holwerda on Sun 13th May 2018 15:29 UTC
Ubuntu, Kubuntu, Xubuntu

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.

Order by: Score:
Who caught this?
by leech on Sun 13th May 2018 17:00 UTC
leech
Member since:
2006-01-10

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/closed source packages, right?

Reply Score: 0

RE: Who caught this?
by Vistaus on Mon 14th May 2018 10:07 UTC in reply to "Who caught this?"
Vistaus Member since:
2018-03-21

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.

Reply Score: 3

RE[2]: Who caught this?
by oiaohm on Mon 14th May 2018 11:41 UTC in reply to "RE: Who caught this?"
oiaohm Member since:
2009-05-30

So *theoretically* such compromised software could end up in Debian/Ubuntu archives as well.


https://tests.reproducible-builds.org/debian/reproducible.html

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.

Reply Score: 6

RE[2]: Who caught this?
by FlyingJester on Tue 15th May 2018 00:10 UTC in reply to "RE: Who caught this?"
FlyingJester Member since:
2016-05-11

Or the time that the Chromium packages on Debian downloaded blackbox binaries that had the ability to listen in on your microphone?

Reply Score: 3

RE[3]: Who caught this?
by oiaohm on Tue 15th May 2018 02:29 UTC in reply to "RE[2]: Who caught this?"
oiaohm Member since:
2009-05-30

Or the time that the Chromium packages on Debian downloaded blackbox binaries that had the ability to listen in on your microphone?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909

Please note it was Debian people who noticed that this was happening. The issue was a upstream modification to the Chromium source so every distribution shipping current version Chromium was having this happen.

Same features have appear in windows programs and windows users have never noticed it.

Reply Score: 3

This is why we can't have nice things
by Morgan on Sun 13th May 2018 19:59 UTC
Morgan
Member since:
2005-06-29

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.

Reply Score: 3

zima Member since:
2005-07-06

And people often blindly copy & paste commands found on www...

Reply Score: 2

Really Malware is no supprise.
by oiaohm on Mon 14th May 2018 01:47 UTC
oiaohm
Member since:
2009-05-30

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.

Reply Score: 0

Snap permissions
by flypig on Mon 14th May 2018 08:54 UTC
flypig
Member since:
2005-07-13

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.

Reply Score: 4

Comment by ahferroin7
by ahferroin7 on Mon 14th May 2018 12:25 UTC
ahferroin7
Member since:
2015-10-30

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.

Reply Score: 4

RE: Comment by ahferroin7
by Alfman on Mon 14th May 2018 14:28 UTC in reply to "Comment by ahferroin7"
Alfman Member since:
2011-01-28

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.

Reply Score: 3

RE[2]: Comment by ahferroin7
by oiaohm on Tue 15th May 2018 02:22 UTC in reply to "RE: Comment by ahferroin7"
oiaohm Member since:
2009-05-30

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.


Linux distributions as whole have enough personal to audit everything. But it would require killing off all the duplication of effort building the same programs over again. Its about the only group with enough resources to-do it. But its the hurding cats problem.

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.


True but sandbox still does not remove need to audit.

Reply Score: 2

RE[3]: Comment by ahferroin7
by zima on Fri 18th May 2018 00:31 UTC in reply to "RE[2]: Comment by ahferroin7"
zima Member since:
2005-07-06

But its the hurding cats problem.

That might be a problem Hurd has... ;)

Reply Score: 2

Manpower issue
by laffer1 on Mon 14th May 2018 13:15 UTC
laffer1
Member since:
2007-11-09

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.

Reply Score: 3