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

211–220 of 223 posts

Re: Malware Found in the Ubuntu Snap Store

#211

Post by coatmatter »

Kototama wrote: post #79

One more confirmation that Ubuntu cannot be recommended anymore.

I think it would be useful if such declarations followed up with an alternative suggestion.

I have no alternative suggestion, because Ubuntu is still what I would recommend to new users even if it's not what I personally use anymore, because they have the track record for getting new Linux users on board and helping them out (via the prominent search results for common problems people come across, etc). On the whole, I also think their design has been consistently decent (including Unity).

Re: Malware Found in the Ubuntu Snap Store

#212

Post by dest »

michaelmrose wrote: post #186
userbinator wrote: post #22

used a proprietary license Does the license actually mention it mines? I am reminded of a lot of "freemium"/"ad-supported"/etc. software that makes its author money via ads or whatever else --- and you agree to that if you read the license --- and it is a bit shady to name the miner 'systemd', but it seems rather overboard to call this "malware"... when I see that term I think of software that self-propagates and exf…

Mining in the background is worse than ads because it will be silently ruining the battery life of your laptop or silently running up your electric bill on your desktop. Note that at 12c per kilowatt hour 200W of extra draw on a machine that's always running is 2.4c per hour. Over the expected 5 year lifespan of a machine this could cost you $880 in the EU this would be more like $1980 because electricity is on avera…

Think about how much ads steal from you, by tricking your brain into buying stuff you don't need.

Re: Malware Found in the Ubuntu Snap Store

#213

Post by mikedelfino »

vbernat wrote: post #191
mikedelfino wrote: post #80

Earlier quoted context omitted.

Doesn't Xauthority solve this? I thought we could use xauth to generate an unprivileged cookie and launch the program using it. Then it could not meddle with other X clients or even the clipboard. Of course you should also prevent the program from reading the original privileged Xauthority data. Running it as a different user does the trick.

Xauthority isn't fine-grained. Once you get a cookie, you haven't any restriction to what you can do with the X server.

We could generate an "untrusted" cookie. This prevents clients using it from meddling with "trusted" clients.

It's not really fine grained and also doesn't prevent untrusted clients from meddling with one another, but seems like a starting point for someone inclined to add more security to X.

Re: Malware Found in the Ubuntu Snap Store

#214

Post by throwaway08320 »

geofft wrote: post #51
ISL wrote: post #13

Earlier quoted context omitted.

I do tend to believe that the presence of a package in the Debian repositories is a limited representation of quality/review, as there is a package-maintainer and apparent community decision as to whether or not to keep it in the distro. Is that perception correct?

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,…

While full auditing is impossible for any distribution, Debian has a multiple people eyeballing code.

Apart the package maintainers and contributors, the Security Team can also review critical packages and step in if something looks suspicious.

But, most importantly, the release cycle and the long freeze before releases is all about STABILITY and SECURITY.

Anybody can upload backdoored code on npm/PyPI etc, infect someone and then remove the malicious release without being detected.

Releasing something malicious or with serious bugs before a freeze cycle and going undetected for months is not impossible but much more difficult.

Re: Malware Found in the Ubuntu Snap Store

#215

Post by throwaway08320 »

avar wrote: post #25
ISL wrote: post #13

Earlier quoted context omitted.

I do tend to believe that the presence of a package in the Debian repositories is a limited representation of quality/review, as there is a package-maintainer and apparent community decision as to whether or not to keep it in the distro. Is that perception correct?

Your perception is entirely incorrect. Debian maintainers don't have the time (or often the knowledge) to review upstream changes. Do you think the Debian Linux, GCC and Xorg maintainers exhaustively review and understand every patch? They don't. Instead, the reason you don't see malware pushed to those repositories is because the incentives in the free software world don't align to make them happen in the first plac…

> Debian maintainers don't have the time (or often the knowledge) to review upstream changes > Do you think the Debian Linux, GCC and Xorg maintainers exhaustively review and understand every patch? They don't.

This is plain false. While it's impossible to guarantee a 100% code reviews, the number of bugs and vulnerabilities found, reported upstream, and patched by distributions (especially Debian) shows that code is being reviewed.

Re: Malware Found in the Ubuntu Snap Store

#216

Post by scarface74 »

coatmatter wrote: post #209
scarface74 wrote: post #55

Earlier quoted context omitted.

And for the life of me I can't understand why people use the Facebook app. The mobile web page loads faster, it's automatically sandboxed by being just a browser page and it can do almost anything that the app can do. Besides on iOS at least, if you click on a link from the Facebook web page, you can take advantage of whatever content blocker you have installed.

> And for the life of me I can't understand why people use the Facebook app. When I last used it, it just felt less clunky than opening it in a mobile browser tab (Android). I bet most people who do use the app would agree. A mobile browser's address bar is also kind of ugly, so apps often just feel more 'immersive' and therefore 'better'. The ultimate reason however is probably because Facebook is somewhat good at m…

Google Maps while navigating requires features that require an app.

Re: Malware Found in the Ubuntu Snap Store

#217

Post by scarface74 »

michaelmrose wrote: post #184
fjsolwmv wrote: post #92

Earlier quoted context omitted.

If you log into Facebook on web, then visit any other site, they send your browsing info to Facebook via Like button. The Facebook app is more sandboxed, since it can't snoop on your web browsing.

The facebook app for quite a while was actually sending facebook data about your phone calls and sms so guess again.

Only on Android....they couldn't do that on iOS.

Re: Malware Found in the Ubuntu Snap Store

#218

Post by cookiecaper »

pritambaral wrote: post #185
cookiecaper wrote: post #154

Earlier quoted context omitted.

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 pack…

> Snaps always run in a semi-encapsulated environment (a container) Even with the `--classic` switch?

I wasn't aware of the "classic" switch, looks like they added it early last year. They appear to call this "classic confinement mode", and it sounds like it functions essentially like a normal package manager, though they insist on saying it's a "relaxed security model" instead of "no additional security model at all", which appears to be the truth of the matter.

Their site claims that only pre-vetted Snaps can be distributed with "classic confinement", so that's something at least. If that's true, it would allow the comparison between Snaps and the AUR to hold -- Snaps would either be pre-vetted and akin to official package repositories, or unvetted but executed within containers (which is still not really an ironclad security guarantee, but better than nothing).

It is deeply sad to see something that supposedly exists to facilitate and promote a sandboxed distribution model give up and cop out so blatantly though. They should've just named the flag "--make-snaps-worthless-you-should-be-using-apt-instead".

Is there a technical reason to prefer "classic" snaps over packages from the official repos? It seems like the default install path may be different and the libraries/installed files possibly better segmented on the filesystem, but ultimately that's little consolation.

Re: Malware Found in the Ubuntu Snap Store

#219

Post by newnewpdro »

badsectoracula wrote: post #201
newnewpdro wrote: post #121

Earlier quoted context omitted.

Have you ever gone through the rigamarole of getting a project into a major distro like debian? A bunch of the guidelines governing that process are simply unenforcable in a model where the developer builds and publishes the release. I am not of the opinion that those rules are irrelevant to the stability and security of our systems. There's a significant push to establish a more app-store model for linux distributio…

I do not really see the difference between the app-store model and the distribution repository model, at the end of the day both are models that teach the users to only download stuff from a specific place. This introduces gatekeeping middlemen that personally i'd rather do without. But if there is going to be a central """trusted""" place, i'd prefer it to be distribution agnostic. (although even that isn't ideal si…

It makes a substantial difference when we're talking about open software the distributor builds from source. The major distributors set a relatively high standard for the build process.

The same cannot be said for developers in my experience, who often don't even see a problem with the build process accessing the network - and frequently will publish releases built from the same host environment they use for their general daily computing.

From the perspective of a distributor, the packages should be perfectly buildable (and for official releases, preferably so) with a toolchain of known provenance in a clean environment without network connectivity.

The priorities are quite different for the developer of software and the distributor of systems incorporating that software. It's similar to the tension between system administrators and developers.

Post reply on HN