Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malware Found in the Ubuntu Snap Store

linuxuprising.com

Post reply on HN
Print view View original

151–160 of 223 posts

Re: Malware Found in the Ubuntu Snap Store

#151

Post by rando444 »

geofft wrote: post #9

There is no review process or central restrictions on who can upload to the Ubuntu Snap Store, so in a sense, this isn't surprising. https://docs.snapcraft.io/build-snaps/publish Does the name "Ubuntu Snap Store" carry a connotation that code is reviewed for malware by Ubuntu, the way that the Apple, Google, Amazon, etc. mobile app stores are? Or does its presence in the software center app imply a connotation that i…

While code reviews are helpful, can they really prevent malware?

(since an app can always download and execute extra code after it's installed.)

Re: Malware Found in the Ubuntu Snap Store

#152

Post by geofft »

Shikadi wrote: post #148
geofft wrote: post #136

Earlier quoted context omitted.

But main/restricted and universe are both vetted—the only people who can upload to universe are Debian developers (indirectly, via Ubuntu importing from Debian) and Ubuntu developers, and the process of becoming either of these is nontrivial. Ubuntu's equivalent of the AUR, if I understand the AUR right, is PPAs, which are definitely not enabled by default and are fairly obvious about their third-party-ness. (Main vs…

It took me a good amount of googling to verify that, but you're mostly correct, there are only 132 developers with upload rights to the universe repository. Though I would argue that the distinction isn't just licensing, since Canonical themselves only support main and restricted.

I mean that the distinction between main and restricted and between universe and multiverse is licensing. It's a 2x2 matrix:

              supported   only community
    free       main        universe
    non-FOSS   restricted  multiverse

Re: Malware Found in the Ubuntu Snap Store

#153

Post by geofft »

im3w1l wrote: post #109
geofft wrote: post #51

Earlier quoted context omitted.

That perception is correct. It's limited because in practice Debian developers (being almost entirely volunteers!) don't have the resources to read and audit each line in an upstream release, so certainly intentionally obfuscated backdoors from a previously trustworthy upstream would almost certainly get through. But the type of attack in this article, with a new binary and an unwanted line of shell script to run it,…

Thanks a lot for clarifying these things. Do they do any identity verification so people can be held accountable after the fact if something shady were to be discovered?

Yes, that's part of why Debian uses PGP keys for package uploads and insists that your key is signed by other Debian developers and not simply anyone in the web of trust. (I am aware of one Debian developer who contributes / is known to the community by a pseudonym, but I'm told that a few other senior people in Debian know this person's legal name for this exact reason.)

Re: Malware Found in the Ubuntu Snap Store

#154

Post by cookiecaper »

zootboy wrote: post #35
eat_veggies wrote: post #24

Earlier quoted context omitted.

I like Arch's package management model, where sources are split into the official repositories, which are manually approved, and the AUR, which everyone knows are not officially endorsed or reviewed, and to check the sources and PKGBUILDS for anything sketchy before installing. The processes for installing from the two are also different enough that the user can't mistake one for the other: official packages are a pa…

Also, compare the wording on the snap store: > Safe to run - Not only are snaps kept separate, their data is kept separate too. Snaps communicate with each other only in ways that you approve. Versus the AUR: > DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk.

The difference being that Snaps always run in a semi-encapsulated environment (a container), whereas the AUR just executes in whatever security context you're issuing commands from. PKGBUILDs are arbitrary shell scripts and they can do anything that the user executing them can do.

I'm not trying to defend the perception that Snaps are immune from malware, but there is a real difference in the default safety of a package off the Snap Store and the AUR.

Re: Malware Found in the Ubuntu Snap Store

#155

Post by pierrec »

matthewbauer wrote: post #91
dtx1 wrote: post #75

Earlier quoted context omitted.

Well as a lazy arch user i installed pacaur and just use official and AUR sources without much checking. It's just convenient that there's an AUR for everything

Be warned that malware like this is in the AUR all the time. It's so common it's not even newsworthy. They are usually pretty good at handling it though.

I've never heard of this happening and I can't find a single occurrence of it. I mean, I agree with "don't blindly trust everything in the AUR", but this seems wrong.

Re: Malware Found in the Ubuntu Snap Store

#156

Post by cookiecaper »

Shikadi wrote: post #148
geofft wrote: post #136

Earlier quoted context omitted.

But main/restricted and universe are both vetted—the only people who can upload to universe are Debian developers (indirectly, via Ubuntu importing from Debian) and Ubuntu developers, and the process of becoming either of these is nontrivial. Ubuntu's equivalent of the AUR, if I understand the AUR right, is PPAs, which are definitely not enabled by default and are fairly obvious about their third-party-ness. (Main vs…

It took me a good amount of googling to verify that, but you're mostly correct, there are only 132 developers with upload rights to the universe repository. Though I would argue that the distinction isn't just licensing, since Canonical themselves only support main and restricted.

Universe is Canonical's dumping ground. There are millions of vulnerable Redis instances in production today because Ubuntu doesn't feel inclined to issue an update for a major CVE affecting the redis-server package shipped for 14.04.

There's multiple layers of problems here, because as we see with Ubuntu, just because the code was built and uploaded by a trustworthy person doesn't mean it's automatically safe or secure (especially for more nefarious infections that bury themselves deep in the source tree). Remember the pwnage that brought down kernel.org for a few months? That was only a few years ago, but the infiltration had been quite serious, and if I recall correctly, there was some concern that infected code had made it into officially distributed tarballs.

In practice, I don't know that the distinction between distributing packages that are trivially exploitable and distributing packages that have exploits pre-baked in is really that big of a difference. Automated scanners often pick up and automatically exploit exposed instances within a few days.

What it boils down to is that admins need to take responsibility for their own workload and what they choose to execute, no matter the guarantees of the distributor or the claims that $Sandbox_Y is magically impenetrable (which was silly enough before, but completely farcical in a post-Spectre world).

Re: Malware Found in the Ubuntu Snap Store

#157

Post by j605 »

jancsika wrote: post #134

Is there some workable way to just add rando user-requested distros (or, more importantly, Debian) to a PPA? Is there some alternate/sane way to distribute packages for Gnu/Linux without smothering my development process in molasses? I don't even mind creating a VM for every single distro a user requests, and doing a huge automated binary compilation fest for every release. The only thing I care about is that the sof…

It is not the job of the developer to package software, that is for maintainers. The best you could do is specify dependencies and tell them how to compile. If it is proprietary, then you might have to support a few popular formats(debs and rpms) and make sure they also work on other distributions without much effort. For example Arch User Repository has google-chrome that repackages it into the native package format but since all dependencies are known, the binary packaged for Debian also works in Arch Linux.

Re: Malware Found in the Ubuntu Snap Store

#158

Post by zer00eyz »

cookiecaper wrote: post #140
mcny wrote: post #123

Earlier quoted context omitted.

I really wish we had app stores actually require vendors to submit source code and build instructions so that the app store would build it themselves and publish it. Something like F-Droid even if the source code is not publicly available.

It's difficult to get useful code review out of colleagues working for the same company. The idea that Apple et al should have a competent reviewer audit each submission is simply not a practical thing for any type of repo that accepts software developed by third parties.

Sometimes a small comment in HN makes one think in a whole new way.

I agree with you that useful code review is a tough nut to crack. Professional editors exist for writing, and science has the peer review process (also flawed).

Reading code, is a whole different ball of wax from writing it (and from optimizing it in some cases) - I can think of few people who are great at both. I have to wonder if we will ever get to the point where "review" sits in an outside role/function that isn't already overloaded (team lead, architect, management).

Does the fact that we don't have dedicated code reviewers speak to its immaturity or (in)effectiveness.

Re: Malware Found in the Ubuntu Snap Store

#159

Post by chris_wot »

I only get my packages from the central repos. I would be very wary of downloading snaps unless I knew exactly who was distributing them.

Repositories are why Linux repos are free of malware. With more snap-based packages being made available then we are going to see a lot more of this sort of thing.

Re: Malware Found in the Ubuntu Snap Store

#160

Post by cookiecaper »

dtx1 wrote: post #75
eat_veggies wrote: post #24

Earlier quoted context omitted.

I like Arch's package management model, where sources are split into the official repositories, which are manually approved, and the AUR, which everyone knows are not officially endorsed or reviewed, and to check the sources and PKGBUILDS for anything sketchy before installing. The processes for installing from the two are also different enough that the user can't mistake one for the other: official packages are a pa…

Well as a lazy arch user i installed pacaur and just use official and AUR sources without much checking. It's just convenient that there's an AUR for everything

The AUR is really handy, but you do need to be careful. Arch does not pretend to hold the user's hand, and you're not likely to get much sympathy from the community if you get bitten by recklessly installing stuff from the AUR.

Also, as far as I know, pacaur is no longer maintained. I switched to trizen, which prints the PKGBUILD on screen before allowing the user to opt in to executing it. Not going to pretend that I always review the PKGBUILD thoroughly, but I do generally skim them, applying more scrutiny as packages become more obscure.

Post reply on HN