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

131–140 of 223 posts

Re: Malware Found in the Ubuntu Snap Store

#131

Post by alsadi »

popey wrote: post #118
alsadi wrote: post #116

Earlier quoted context omitted.

Snap is a proprietary format that is canonical-centric, don't tell me that the community make choice to make client opensource but official store both hardcoded (initially) and closed source. On the other hand,flatpak is a freedesktop project, done using open standards like OCI and ostree.

No. Snap is not a proprietary format at all. It's a squashfs file with a small amount of metadata. You can make a snap by plopping a file in a folder, add a simple snap.yaml which describes the application and then "make" a snap with the common mksquashfs tool. There is room in the world for flatpak and snap to co-exist. We created snaps as an evolution on from clicks on the Ubuntu phone, and it covers use cases that…

Remember ubuntu one storage solution? An opensource client does not make the whole thing free software and open standard.

Re: Malware Found in the Ubuntu Snap Store

#132

Post by newnewpdro »

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…

When I began exploring rebuilding an Arch install from source using ABS it all seemed to blindly trust everything coming from the arch repos as not being compromised. There was zero signing of anything. I had hoped the package maintainers responsible for the housekeeping of all the associated metadata would have been signing it all with their respective keys.

If someone were to compromise an upstream Arch server I suspect it wouldn't be especially difficult to inject malware or trojans somewhere even those building from source would receive.

Re: Malware Found in the Ubuntu Snap Store

#133

Post by 64kbisalluneed »

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

But this particular issue doesn't have anything to do with X!

One word: lxc

Re: Malware Found in the Ubuntu Snap Store

#134

Post by jancsika »

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 software is distributed through channels which make it explicit that the current stable version is the only version I support.

Re: Malware Found in the Ubuntu Snap Store

#135

Post by eat_veggies »

newnewpdro wrote: post #132
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…

When I began exploring rebuilding an Arch install from source using ABS it all seemed to blindly trust everything coming from the arch repos as not being compromised. There was zero signing of anything. I had hoped the package maintainers responsible for the housekeeping of all the associated metadata would have been signing it all with their respective keys. If someone were to compromise an upstream Arch server I su…

I'm pretty sure all packages in the official repositories are signed:

> Official packages: A developer made the package and signed it. The developer's key was signed by the Arch Linux master keys. You used your key to sign the master keys, and you trust them to vouch for developers.

source: https://wiki.archlinux.org/index.php/Pacman/Package_signing

Re: Malware Found in the Ubuntu Snap Store

#136

Post by geofft »

Shikadi wrote: post #126
HankB99 wrote: post #125

Earlier quoted context omitted.

> ... and the AUR, which everyone knows are not officially endorsed or reviewed ... Uh, not everyone. I ran Manjaro for a bit and found that many of the things I ran were available via AUR. The usual thing I'd find in a search was usually something like: sudo pacman -Sy sudo pacman -S yaourt base-devel yaourt -Sy yaourt -S gpodder (That's the entire reply, BTW.) At some point I started to wonder what the provenance o…

In ubuntu, it's even less obvious. Main, restricted, and universe are all checked together by apt, and treated the same

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. restricted and universe vs. multiverse is just about licensing, not access control or vetting.)

Re: Malware Found in the Ubuntu Snap Store

#137

Post by newnewpdro »

eat_veggies wrote: post #135
newnewpdro wrote: post #132

Earlier quoted context omitted.

When I began exploring rebuilding an Arch install from source using ABS it all seemed to blindly trust everything coming from the arch repos as not being compromised. There was zero signing of anything. I had hoped the package maintainers responsible for the housekeeping of all the associated metadata would have been signing it all with their respective keys. If someone were to compromise an upstream Arch server I su…

I'm pretty sure all packages in the official repositories are signed: > Official packages: A developer made the package and signed it. The developer's key was signed by the Arch Linux master keys. You used your key to sign the master keys, and you trust them to vouch for developers. source: https://wiki.archlinux.org/index.php/Pacman/Package_signing

I'm not talking about the binary packages.

Re: Malware Found in the Ubuntu Snap Store

#138

Post by jlgaddis »

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.

> All work in Debian is performed by developers that can be identified. For those using Debian to be able to trust Debian, we feel it is important that our users can identify those that are working on the project and that development is as transparent as is possible. [0]

I don't personally use Debian very much these days -- my desktops all run Fedora, my servers (with a few exceptions) run CentOS and RHEL -- but I used Debian exclusively for many, many years and out of all Linux distributions Debian (IMO, of course) comes the closest to doing things "the right way". In and of itself, that is pretty amazing, I think, considering that there isn't really all that much that has changed in its 25 year history! In other words, they somehow managed to get things right the first time around.

There are a few things that could perhaps be done a little better or different but -- considering that Debian is an all-volunteer project -- I think they manage to do an awesome job with the limited resources available to them.

[0]: https://wiki.debian.org/DebianKeyring

Re: Malware Found in the Ubuntu Snap Store

#139

Post by drdrey »

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…

In this case though it's not really a security issue as you describe and more of an abusive use of resources. I don't mean to be facetious but that's also what Electron apps do to some extent

Re: Malware Found in the Ubuntu Snap Store

#140

Post by cookiecaper »

mcny wrote: post #123
tinus_hn wrote: post #97

Earlier quoted context omitted.

Apple doesn’t get the source code of apps. They check what apis you use so they can prevent you from using non public apis and they run some cursory checks. But there is a lot of crap on the App Store.

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.
Post reply on HN