3 ms·

I would be careful about claiming built artifacts play much role in the visibility of repository-delivered malware. Consider "reflections on trusting trust" for

I would be careful about claiming built artifacts play much role in the visibility of repository-delivered malware. Consider "reflections on trusting trust" for attacks on reproducible builds, and also that all the major scripting languages (PyPI, Ruby gems, and npm) have had malicious packages inserted over the last year or so.

TheDong 7y ago
> all the major scripting languages (PyPI, Ruby gems, and npm) have had malicious packages inserted None of those package repositories are maintained by a limited set of curators. Debian's repositories and other linux distributions repositories are curated. Uploading a malicious package to npm is as easy as typing 'npm publish'. > "reflections on trusting trust" It's a very useful piece of art and a thought experiment. In practice, it's not interesting for the average package. Very few packages are self-hosting and in such a position to leverage that sort of clever trickery. A good debian maintainer will also review code of their packages and make sure such trickery has no chance to be afood (e.g. by preventing a gem from downloading a custom ruby interpreter to bootstrap itself, but rather manually bootstrapping up themselves).
- Godel_unicode 7y ago
  The point of "... trusting trust" is not really the specific bug, but rather the observation that the whole supply chain matters. Built artifacts as exist on disk in the repo are a relatively small piece of that. > None of those package repositories are maintained by a limited set of curators. It's always interesting to me how few people seemingly know this. Python package maintainers realize how easy it is to add packages to PyPI, but many admins and even SOC operators inherently trust it because they think that it "must be reviewed by someone". Also, there have been plenty of security issues with Ubuntu and Debian: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue52#Community_Hosted_Servers_Compromised https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue52#Commu... https://www.linuxinsider.com/story/32240.html https://www.linuxinsider.com/story/32240.html Also there have been bugs in apt: https://www.fosslinux.com/6167/massive-security-bug-found-in-debian-ubuntu-and-derivatives-apt.htm https://www.fosslinux.com/6167/massive-security-bug-found-in... Also the official ISO from the Mint website: https://arstechnica.com/information-technology/2016/02/linux-mint-hit-by-malware-infection-on-its-website-and-forum-after-hack-attack/ https://arstechnica.com/information-technology/2016/02/linux... Also the AUR malware mentioned on thread: https://www.bleepingcomputer.com/news/security/malware-found-in-arch-linux-aur-package-repository/ https://www.bleepingcomputer.com/news/security/malware-found... Also the kernel.org compromise: https://www.zdnet.com/article/linux-kernel-source-code-repositories-get-better-security/ https://www.zdnet.com/article/linux-kernel-source-code-repos... Edit: let's throw in the redhat ceph intrusion while we're at it (note that this includes InkTank). https://www.zdnet.com/article/red-hats-ceph-and-inktank-code-repositories-were-cracked/ https://www.zdnet.com/article/red-hats-ceph-and-inktank-code...
  - tkfu 7y ago
    > The point of "... trusting trust" is not really the specific bug, but rather the observation that the whole supply chain matters. There's a really fascinating project by the authors of TUF called in-toto[1] that addresses exactly this problem. [1] https://in-toto.github.io/ https://in-toto.github.io/
  - majewsky 7y ago
    I don't like when "Reflections on trusting trust" is used as an excuse to throw the hands in the air and not doing anything. Sure, it's not perfect, but the reproducible-builds people are doing important work that makes it considerably harder to inject malware into distribution repos.
    - zzzcpan 7y ago
      I'm sorry, but the logical fallacy of "We must do something; This is something; Therefore, we must do this." is the worst attitude to have for security. Not only you will never end with anything actually important done, it will also justify all the evil that will be done in the name of security. And nobody says that not doing anything is ok, but please do it properly, do some basic threat modeling first. P.S. I'm not against reproducible builds, I think they are useful for many things, just not for security. They may even let us do decentralized trustless peer-to-peer build system someday.
    - Godel_unicode 7y ago
      The hard part about the security of built artifacts is not building them, it's auditing the source looking for bugs. Reproducible-builds doesn't audit the source, but many act like they think it does. Added to this is the host of other security issues with the chain between the developers keyboard and your system. This solves none of them, but many act like they think it does. Therefore, in my view it provides a smallish real benefit and a large moral hazard.
  - profalseidol 7y ago
    Science is hard. Superstition is fast and might save your job, at least for awhile.
- ohithereyou 7y ago
  >A good debian maintainer will also review code of their packages and make sure such trickery has no chance to be afood Except for that time that Debian developers "knowing better" completely neutered most cryptography on all updated Debian systems[1]: >Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. Keys generated with GnuPG or GNUTLS are not affected, though. Massive, rapid key rotation schemes had do be implemented to cover their screwup because all keys were trivially enumerable, to the point where all affected keys were blacklisted[2]. [1] https://www.debian.org/security/2008/dsa-1571 https://www.debian.org/security/2008/dsa-1571 [2] https://security.stackexchange.com/questions/3422/what-is-the-openssh-blacklist-package-is-it-related-to-the-debian-openssl-bug https://security.stackexchange.com/questions/3422/what-is-th...

TheDong 7y ago

> all the major scripting languages (PyPI, Ruby gems, and npm) have had malicious packages inserted None of those package repositories are maintained by a limited set of curators. Debian's repositories and other linux distributions repositories are curated. Uploading a malicious package to npm is as easy as typing 'npm publish'. > "reflections on trusting trust" It's a very useful piece of art and a thought experiment. In practice, it's not interesting for the average package. Very few packages are self-hosting and in such a position to leverage that sort of clever trickery. A good debian maintainer will also review code of their packages and make sure such trickery has no chance to be afood (e.g. by preventing a gem from downloading a custom ruby interpreter to bootstrap itself, but rather manually bootstrapping up themselves).

Godel_unicode 7y ago
The point of "... trusting trust" is not really the specific bug, but rather the observation that the whole supply chain matters. Built artifacts as exist on disk in the repo are a relatively small piece of that. > None of those package repositories are maintained by a limited set of curators. It's always interesting to me how few people seemingly know this. Python package maintainers realize how easy it is to add packages to PyPI, but many admins and even SOC operators inherently trust it because they think that it "must be reviewed by someone". Also, there have been plenty of security issues with Ubuntu and Debian: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue52#Community_Hosted_Servers_Compromised https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue52#Commu... https://www.linuxinsider.com/story/32240.html https://www.linuxinsider.com/story/32240.html Also there have been bugs in apt: https://www.fosslinux.com/6167/massive-security-bug-found-in-debian-ubuntu-and-derivatives-apt.htm https://www.fosslinux.com/6167/massive-security-bug-found-in... Also the official ISO from the Mint website: https://arstechnica.com/information-technology/2016/02/linux-mint-hit-by-malware-infection-on-its-website-and-forum-after-hack-attack/ https://arstechnica.com/information-technology/2016/02/linux... Also the AUR malware mentioned on thread: https://www.bleepingcomputer.com/news/security/malware-found-in-arch-linux-aur-package-repository/ https://www.bleepingcomputer.com/news/security/malware-found... Also the kernel.org compromise: https://www.zdnet.com/article/linux-kernel-source-code-repositories-get-better-security/ https://www.zdnet.com/article/linux-kernel-source-code-repos... Edit: let's throw in the redhat ceph intrusion while we're at it (note that this includes InkTank). https://www.zdnet.com/article/red-hats-ceph-and-inktank-code-repositories-were-cracked/ https://www.zdnet.com/article/red-hats-ceph-and-inktank-code...
- tkfu 7y ago
  > The point of "... trusting trust" is not really the specific bug, but rather the observation that the whole supply chain matters. There's a really fascinating project by the authors of TUF called in-toto[1] that addresses exactly this problem. [1] https://in-toto.github.io/ https://in-toto.github.io/
- majewsky 7y ago
  I don't like when "Reflections on trusting trust" is used as an excuse to throw the hands in the air and not doing anything. Sure, it's not perfect, but the reproducible-builds people are doing important work that makes it considerably harder to inject malware into distribution repos.
  - zzzcpan 7y ago
    I'm sorry, but the logical fallacy of "We must do something; This is something; Therefore, we must do this." is the worst attitude to have for security. Not only you will never end with anything actually important done, it will also justify all the evil that will be done in the name of security. And nobody says that not doing anything is ok, but please do it properly, do some basic threat modeling first. P.S. I'm not against reproducible builds, I think they are useful for many things, just not for security. They may even let us do decentralized trustless peer-to-peer build system someday.
  - Godel_unicode 7y ago
    The hard part about the security of built artifacts is not building them, it's auditing the source looking for bugs. Reproducible-builds doesn't audit the source, but many act like they think it does. Added to this is the host of other security issues with the chain between the developers keyboard and your system. This solves none of them, but many act like they think it does. Therefore, in my view it provides a smallish real benefit and a large moral hazard.
- profalseidol 7y ago
  Science is hard. Superstition is fast and might save your job, at least for awhile.
ohithereyou 7y ago
>A good debian maintainer will also review code of their packages and make sure such trickery has no chance to be afood Except for that time that Debian developers "knowing better" completely neutered most cryptography on all updated Debian systems[1]: >Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. Keys generated with GnuPG or GNUTLS are not affected, though. Massive, rapid key rotation schemes had do be implemented to cover their screwup because all keys were trivially enumerable, to the point where all affected keys were blacklisted[2]. [1] https://www.debian.org/security/2008/dsa-1571 https://www.debian.org/security/2008/dsa-1571 [2] https://security.stackexchange.com/questions/3422/what-is-the-openssh-blacklist-package-is-it-related-to-the-debian-openssl-bug https://security.stackexchange.com/questions/3422/what-is-th...