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

71–80 of 223 posts

Re: Malware Found in the Ubuntu Snap Store

#71

Post by wopian »

crispyporkbites wrote: post #62
paulpauper wrote: post #60

A Monero miner is one of the more innocuous forms of malware ,compared to a C&C trojan or a keylogger. Some websites will mine monero in the background. Because it's just a js script, it's not much different than a banner ad except it's less intrusive, yet somehow 'currency miner' has more negative connotations than 'ad server'. That is the downside of decentralized mining and asic resistance is you end up with a lot…

> Because it's just a js script, it's not much different than a banner ad except it's less intrusive Tell that to your electricity provider

Or to your laptop/mobile battery lives...

Re: Malware Found in the Ubuntu Snap Store

#72

Post by sleavey »

As someone who hasn't yet used Ubuntu 18.04, is the snap store something I'll be using in 5 years time instead of APT, is it just another attempt by Canonical to jump on the app store bandwagon, or is it something completely different?

Excuse my ignorance but I'm intensely suspicious of "stores" on open source operating systems.

Re: Malware Found in the Ubuntu Snap Store

#73

Post by mihaifm »

Can anyone clarify if this is a possibility for apt packages as well? As far as I understand, there are 4 types of apt repositories (for Ubuntu): Main, Universe, Restricted, Multiverse.

I guess Main is safe since it's handled by Canonical, but the rest?

Moreover, a lot of installers simply add a custom repository to sources.list.

What are some good practices for a novice user, regarding apt?

Re: Malware Found in the Ubuntu Snap Store

#74

Post by codedokode »

solomatov wrote: post #36
the_common_man wrote: post #6

This is exactly why you should not run random docker images and snaps. Docker images are also run as root in many cases. It is better to build app images from scratch and understand what exactly goes into the image.

Why not run random docker images? As far as I understand, docker container are pretty solid. Not super solid but solid enough.

Docker was never made for security, only for isolation and it can have vulnerabilities.

Re: Malware Found in the Ubuntu Snap Store

#75

Post by dtx1 »

eat_veggies wrote: post #24
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…

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

Re: Malware Found in the Ubuntu Snap Store

#76

Post by FRex »

faho wrote: post #29
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…

>a simple game like that taking >100MB would make me suspicious Nah. Games often feature a bunch of textures and video and sound files. Bad compression or too high resolution on those is quite common, which is why games _are_ often that large. Also proprietary software usually ships a bunch of libraries - games often ship with a premade engine, which are also often quite large. As a datapoint, I have a copy of "Strat…

The website version of the game was 150 KB.

You'd be hard pressed to find an engine or runtime (except electron as some people are saying it actually is..) to get a game like that (literally moving boxes and text) up to that size.

Even if he used static images and ttf fonts the size is way off. Pngs are a couple to couple dozen kilos a piece. Fonts are a few megs at most each. The single biggest font 'file' I know of/used for real (except for experiments people might do with the file formats) is Noto Sans CJK ttc file and it's not a single font but a collection (and it covers all of CJK[0] which is an insane range).

Entire Minecraft is under 300 megs and that includes the launcher, the language packs, and the entire JRE that is 140 megs in itself (!).

On gamejolt there is a (very nice) small low poly game called The Very Organized Thief, it was made in Unity3D and is just 13 megs in a zip (EDIT: and 35 unpacked).

I couldn't find a low poly game in Unreal Engine 4 nor one that is under 100-200 megs (EDIT: when packed) so maybe Unreal Engine 4 has that high static cost but I'm not sure right now.

In any case: 2048 taking over 100 megs is actually crazy, especially since it's a game so simple you can rewrite it in almost any engine overnight. He/she could have done at least that much.

[0] - https://www.google.com/get/noto/help/cjk/

Re: Malware Found in the Ubuntu Snap Store

#77

Post by AsyncAwait »

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

For packages with many votes this is somewhat fine, but you should still skim the PKGBUILD as the maintainers of even popular packages may change in time.

Re: Malware Found in the Ubuntu Snap Store

#78

Post by kuschku »

subway wrote: post #56
solomatov wrote: post #36

Earlier quoted context omitted.

Why not run random docker images? As far as I understand, docker container are pretty solid. Not super solid but solid enough.

Those random docker images are rarely used in isolation. They typically handle your data and often your customers data. Beyond that, numerous escape exploits in linux containerization (and docker specifically) have popped up over the years, and many more are going to pop up over the coming years. This is not a mature space. Running random binary code distributed from an non-curated source, even in a "container" is go…

And that’s why you should usually build your own images, and only trust docker images from the same people whose binaries you’d also trust with all your data.

(e.g. a docker image from RedHat may be okay, one from zhenghe8 likely not)

Re: Malware Found in the Ubuntu Snap Store

#80

Post by mikedelfino »

solomatov wrote: post #8

The problem with snaps is that they didn't take security really seriously on desktop: https://www.zdnet.com/article/linux-expert-matthew-garrett-u... >"X has no real concept of different levels of application trust. Any application can register to receive keystrokes from any other application. Any application can inject fake key events into the input stream. An application that is otherwise confined by strong securit…

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.

Post reply on HN