6 ms·

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 sou

by ohazi 7y ago

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 fully reproducible builds, hiding malware in some obscure but heavily depended on package could actually be relatively easy.

nextos 7y ago
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 https://github.com/flyingcircusio/vulnix
- swdunlop 7y ago
  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/development/tools/phantomjs/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...
  - baroffoos 7y ago
    Should you really be installing programs that are impossible to build? Also phantomjs is discontinued.
    - swdunlop 7y ago
      That's a great question, but it does not invalidate the point that there is nothing about Nix that states that binary packages cannot and do not happen.
      - nextos 7y ago
        Try for example FHS environments. That should make it possible to install software in a conventional way.
  - nextos 7y ago
    You can also build regular packages, no matter how complicated they are, by spanning an FHS environment. That's sort of a sandbox that simulates a regular Unix environment with whatever dependencies you need in the usual places (/bin, /usr, ...). Of course, you loose some Nix advantages. But it's a great way to get a regular Unix environment for one-off things or desperate cases.
- wwright 7y ago
  I believe they aren’t just progressing towards reproducible builds, but that the whole system is already predicated on them. In Nix, you have to make special exceptions for packages that aren’t rebuildable from source.
  - deleted 7y ago
    [deleted]
  - svd4anything 7y ago
    Rebuildable is different than reproducible. The Nix system is predicated on rebuilding. Ideally the binaries would be all also reproducible however it turns out making compilation completely deterministic is actually pretty hard. When we reach that point and me and you can both independently produce identical binaries and hash them from exactly the same source code that is beyond fantastic for security and auditing.
    - delroth 7y ago
      r13y.com tracks the progress for NixOS reproducibility (well, for the tiny subset of nixpkgs that forms the minimal ISO image at least).
calais 7y ago
This is a flaw with the repository model for software distribution: it confers the authority of the OS developers to packages not scrutinized to the same degree. Users' metal models of trustworthiness don't track very well the actual scrutiny software is subjected to. This might be a problem with any distribution system.
- ajross 7y ago
  FWIW, as far as "scrutiny" goes, I think the track record of Red Hat and Debian/Ubuntu on this stuff is about as good as... well, basically any other distribution system I'm aware of. The Android and iOS stores have hosted malware, as has Microsoft's. Steam has pushed bad stuff. NPM is a straight up train wreck... I mean, I agree in principle that it's a hard problem. But the actual solution we've landed on in the Linux world seems like... well, just not really the first thing we should be worried about.
  - calais 7y ago
    That's definitely the feeling I've gotten from the Debian repositories, which are very cautious about what to distribute. I was thinking about it in the abstract.
- dahfizz 7y ago
  What's the solution? I would argue that the Linux model is way more secure than the windows model of "Google your software and download it from whatever website pops up". It also allows for much more freedom and availability than the locked down macos app store. It's a tough balancing act.
- Godel_unicode 7y ago
  I think you're overestimating the rigor of other software delivery channels. Consider for instance that the biggest Windows SSH client (PuTTY) was delivered over http from a super sketchy looking website until very recently. Now it's the same super sketchy looking website, but with a green lock!
  - 7y ago
godelski 7y ago
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.
- zzzcpan 7y ago
  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.
est31 7y ago
> 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/ https://reproducible-builds.org/reports/2019-07/
- eikenberry 7y ago
  This plus reproducible builds will go a long ways toward preventing it.
  - zzzcpan 7y ago
    Reproducible builds can't prevent hidden malware. They don't do much at all for security.
    - est31 7y ago
      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.
      - zzzcpan 7y ago
        > In fact most attacks in the past were in source based languages like JavaScript but without reproducible builds the situation would be much worse. This is incorrect. It wouldn't make a single difference.
    - jakeogh 7y ago
      It forces logging of the malware, globally. That's worse than maybe getting caught.
      - 7y ago
blihp 7y ago
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.
- o-__-o 7y ago
  Ahh the attack vector. Here’s a free one: KDE addons for things like themes and wallpapers. The package format allows running of arbitrary code. Well obfuscated stuff gets through (to the tune of 10k+) all the time. Pretty sure I inherited a malware or two from there in the past

by ohazi 7y ago

nextos 7y ago

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 https://github.com/flyingcircusio/vulnix

swdunlop 7y ago
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/development/tools/phantomjs/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...
- baroffoos 7y ago
  Should you really be installing programs that are impossible to build? Also phantomjs is discontinued.
  - swdunlop 7y ago
    That's a great question, but it does not invalidate the point that there is nothing about Nix that states that binary packages cannot and do not happen.
    - nextos 7y ago
      Try for example FHS environments. That should make it possible to install software in a conventional way.
- nextos 7y ago
  You can also build regular packages, no matter how complicated they are, by spanning an FHS environment. That's sort of a sandbox that simulates a regular Unix environment with whatever dependencies you need in the usual places (/bin, /usr, ...). Of course, you loose some Nix advantages. But it's a great way to get a regular Unix environment for one-off things or desperate cases.
wwright 7y ago
I believe they aren’t just progressing towards reproducible builds, but that the whole system is already predicated on them. In Nix, you have to make special exceptions for packages that aren’t rebuildable from source.
- deleted 7y ago
  [deleted]
- svd4anything 7y ago
  Rebuildable is different than reproducible. The Nix system is predicated on rebuilding. Ideally the binaries would be all also reproducible however it turns out making compilation completely deterministic is actually pretty hard. When we reach that point and me and you can both independently produce identical binaries and hash them from exactly the same source code that is beyond fantastic for security and auditing.
  - delroth 7y ago
    r13y.com tracks the progress for NixOS reproducibility (well, for the tiny subset of nixpkgs that forms the minimal ISO image at least).

calais 7y ago

This is a flaw with the repository model for software distribution: it confers the authority of the OS developers to packages not scrutinized to the same degree. Users' metal models of trustworthiness don't track very well the actual scrutiny software is subjected to. This might be a problem with any distribution system.

ajross 7y ago
FWIW, as far as "scrutiny" goes, I think the track record of Red Hat and Debian/Ubuntu on this stuff is about as good as... well, basically any other distribution system I'm aware of. The Android and iOS stores have hosted malware, as has Microsoft's. Steam has pushed bad stuff. NPM is a straight up train wreck... I mean, I agree in principle that it's a hard problem. But the actual solution we've landed on in the Linux world seems like... well, just not really the first thing we should be worried about.
- calais 7y ago
  That's definitely the feeling I've gotten from the Debian repositories, which are very cautious about what to distribute. I was thinking about it in the abstract.
dahfizz 7y ago
What's the solution? I would argue that the Linux model is way more secure than the windows model of "Google your software and download it from whatever website pops up". It also allows for much more freedom and availability than the locked down macos app store. It's a tough balancing act.
Godel_unicode 7y ago
I think you're overestimating the rigor of other software delivery channels. Consider for instance that the biggest Windows SSH client (PuTTY) was delivered over http from a super sketchy looking website until very recently. Now it's the same super sketchy looking website, but with a green lock!
- 7y ago

godelski 7y ago

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.

zzzcpan 7y ago
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.

est31 7y ago

> 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/ https://reproducible-builds.org/reports/2019-07/

eikenberry 7y ago
This plus reproducible builds will go a long ways toward preventing it.
- zzzcpan 7y ago
  Reproducible builds can't prevent hidden malware. They don't do much at all for security.
  - est31 7y ago
    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.
    - zzzcpan 7y ago
      > In fact most attacks in the past were in source based languages like JavaScript but without reproducible builds the situation would be much worse. This is incorrect. It wouldn't make a single difference.
  - jakeogh 7y ago
    It forces logging of the malware, globally. That's worse than maybe getting caught.
    - 7y ago

blihp 7y ago

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.

o-__-o 7y ago
Ahh the attack vector. Here’s a free one: KDE addons for things like themes and wallpapers. The package format allows running of arbitrary code. Well obfuscated stuff gets through (to the tune of 10k+) all the time. Pretty sure I inherited a malware or two from there in the past