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

Why GNU/Linux Viruses Are Fairly Uncommon

gnu.org

Post reply on HN
Print view View original

31–40 of 117 posts

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#31

Post by godelski »

ohazi wrote: post #3

On a more serious note, I'm surprised there hasn't been much discussion about potential malware in official Linux package repositories vs. developer-centric source repositories like npm, rubygems, crates.io, etc. One would hope that the bar is higher with strict maintainership rules, but there are a zillion packages, and you can't vet them all. Also, practically everyone installs binary packages, so until we have ful…

Hasn't this happened a few times? IIRC the AUR had some malware last year, but it was caught pretty quickly. I think why it doesn't happen often is more visibility thing. If it's a useful virus then it's going to be in a popular package, for maximum contamination (or at least some threshold). But people using things like the AUR are generally much more tech savvy then you're average computer user and will correctly flag a package as malicious much faster. Plus there is a higher percentage of users looking at commits. So if they get caught fast then there's more protection for the less savvy (or "lazy"). This is just a guess though.

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#32

Post by zaat »

fao_ wrote: post #28
zaat wrote: post #20

Earlier quoted context omitted.

>Obviously this isn't something that could not be fixed in Windows, and maybe it already has been. There is nothing even remotely obvious about that statement. If it was anything near possible it wouldn't an ongoing problem, unsolved for the last 12 years, since the introduction of UAC in Windows Vista. Now I wouldn't say that Microsoft didn't progress. Far from it. Almost no one I knew kept Vista UAC enabled, as it…

The main flaws with UAC is that you don't know what application is asking for it (This actually ties into a deeper problem which is, you don't know where application binaries reside, and applications are less predictable on Linux). Instead you have to correlate with what you've done recently, which might not align with the process that requested permission.

Not sure what you mean, this is not generally true - the dialog states the name of the process or the application requesting elevation, as you can see in a quick google pics search.

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#33

Post by est31 »

ohazi wrote: post #3

On a more serious note, I'm surprised there hasn't been much discussion about potential malware in official Linux package repositories vs. developer-centric source repositories like npm, rubygems, crates.io, etc. One would hope that the bar is higher with strict maintainership rules, but there are a zillion packages, and you can't vet them all. Also, practically everyone installs binary packages, so until we have ful…

> the [Debian] Release Team recently announced that Debian will no longer allow binaries built and uploaded by maintainers on their own machines to be part of the upcoming release.

https://reproducible-builds.org/reports/2019-07/

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#34

Post by zzzcpan »

godelski wrote: post #31
ohazi wrote: post #3

On a more serious note, I'm surprised there hasn't been much discussion about potential malware in official Linux package repositories vs. developer-centric source repositories like npm, rubygems, crates.io, etc. One would hope that the bar is higher with strict maintainership rules, but there are a zillion packages, and you can't vet them all. Also, practically everyone installs binary packages, so until we have ful…

Hasn't this happened a few times? IIRC the AUR had some malware last year, but it was caught pretty quickly. I think why it doesn't happen often is more visibility thing. If it's a useful virus then it's going to be in a popular package, for maximum contamination (or at least some threshold). But people using things like the AUR are generally much more tech savvy then you're average computer user and will correctly f…

I think people inspect AUR packages before compiling, at least I do, so something obvious will be caught. But something like backdoor hiding in plain sight as an RCE vulnerability or even just more obvious code sneakely integrated into the source and waiting for a specific time far into the future to activate is very unlikely to be caught.

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#35

Post by eikenberry »

est31 wrote: post #33
ohazi wrote: post #3

On a more serious note, I'm surprised there hasn't been much discussion about potential malware in official Linux package repositories vs. developer-centric source repositories like npm, rubygems, crates.io, etc. One would hope that the bar is higher with strict maintainership rules, but there are a zillion packages, and you can't vet them all. Also, practically everyone installs binary packages, so until we have ful…

> the [Debian] Release Team recently announced that Debian will no longer allow binaries built and uploaded by maintainers on their own machines to be part of the upcoming release. https://reproducible-builds.org/reports/2019-07/

This plus reproducible builds will go a long ways toward preventing it.

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#36

Post by zzzcpan »

eikenberry wrote: post #35
est31 wrote: post #33

Earlier quoted context omitted.

> the [Debian] Release Team recently announced that Debian will no longer allow binaries built and uploaded by maintainers on their own machines to be part of the upcoming release. https://reproducible-builds.org/reports/2019-07/

This plus reproducible builds will go a long ways toward preventing it.

Reproducible builds can't prevent hidden malware. They don't do much at all for security.

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#37

Post by est31 »

zzzcpan wrote: post #36
eikenberry wrote: post #35

Earlier quoted context omitted.

This plus reproducible builds will go a long ways toward preventing it.

Reproducible builds can't prevent hidden malware. They don't do much at all for security.

They can't prevent it but they can help it become visible. Without reproducible builds, nobody has an easy way to verify that a specific binary corresponds to a specific deemed safe bit of source code. There can still be source code based attacks by upstream maintainers of course. In fact most attacks in the past were in source based languages like JavaScript but without reproducible builds the situation would be much worse.

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#38

Post by swdunlop »

nextos wrote: post #5
ohazi wrote: post #3

On a more serious note, I'm surprised there hasn't been much discussion about potential malware in official Linux package repositories vs. developer-centric source repositories like npm, rubygems, crates.io, etc. One would hope that the bar is higher with strict maintainership rules, but there are a zillion packages, and you can't vet them all. Also, practically everyone installs binary packages, so until we have ful…

Nix/Guix are quite cool to tackle this. They are progressing quite quickly towards reproducible builds, so you can avoid compromised servers sending malicious binaries. Also, since package definitions are quite declarative, I guess it's easier to perform static verification to spot malicious code getting introduced there. There's e.g. Vulnix that scans for CVEs [1]. [1] https://github.com/flyingcircusio/vulnix

NixOS (and NixPkgs) is great, but there are still plenty of binary only packages from difficult to build projects like PhantomJS in the ecosystem. It takes a serious commitment to build complex projects in Nix and maintain them.

(edit) An example of binary packages in Nixpkgs: https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#39

Post by tombert »

jwkane wrote: post #11
tombert wrote: post #8

Earlier quoted context omitted.

That's about 95% of it. There are other things that give Linux a bit more of an edge in this space as well. For example, every time I use Windows, it feels like every app is asking to run as administrator. Admittedly, I haven't used Windows for about a year, but in Linux, it's pretty rare that I ever do admin/sudo outside of the command line, and I only ever use it when I know what I'm doing. Obviously this isn't som…

lets not forget the "curl blahblah.com | sudo bash" bit-o-insanity.

Yeah...I don't think I've ever actually done that, but I could see some blog post saying to.

I think an annoying truth that us Linux-users don't like to admit is that another large part of what makes linux "more secure" is that only technical people bother using it. My parents are both smart people, but aren't programmers or anything, and as a result didn't like Linux when I tried to get them to use it; if they did use Ubuntu it's entirely possible that they'd figure out how to get a virus pretty quickly.

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#40

Post by blihp »

ohazi wrote: post #3

On a more serious note, I'm surprised there hasn't been much discussion about potential malware in official Linux package repositories vs. developer-centric source repositories like npm, rubygems, crates.io, etc. One would hope that the bar is higher with strict maintainership rules, but there are a zillion packages, and you can't vet them all. Also, practically everyone installs binary packages, so until we have ful…

Depends on the attack vector. If the concern is inadvertent malware (i.e. an unaware developer incorporating a malicious library etc.) then I'd suspect the package repos would be a bit safer because they tend to act as a low pass filter (active source repos can change very frequently, downstream package repos much less so) and also act as one or more additional sets of eyes on the source code. Some developers can get so focused on getting things done that they can lose sight other aspects of their application.

I've heard far more stories about malware making it into developer repos (usually inadvertently) than making it to package repos. I suspect it's partially the relative areas of focus of developers vs package maintainers and partially just having another set of eyes at least glancing at what's going on.

Post reply on HN