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.
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?
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.
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.
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.
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.
And people often blindly copy & paste commands found on http://www...
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.
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.
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.
ahferroin7,
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.
True but sandbox still does not remove need to audit.
That might be a problem Hurd has…
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.