4 ms·

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

by eikenberry 7y ago

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.
  - ChrisCinelli 7y ago
    If you assume that the build systems and the distribution are secure. If somebody had stolen the signing keys and could do a https://www.cloudflare.com/learning/security/glossary/bgp-hijacking/ https://www.cloudflare.com/learning/security/glossary/bgp-hi... there will be no trace.
    - jakeogh 7y ago
      Bugs in the build system are just bugs, quite possibly security bugs but still set in stone. Reproducible builds have no point if you distribution is broken and cant actually cant verify they are reproduced. You could have just asked "What if the reproduced build isn't?". It's not a reason to not be able to reproduce the image. We know how to publish the input and output hashes. It's one of the use cases for a global ledger. Using CF's trust root would be pointless.
Godel_unicode 7y ago
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...

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.
- ChrisCinelli 7y ago
  If you assume that the build systems and the distribution are secure. If somebody had stolen the signing keys and could do a https://www.cloudflare.com/learning/security/glossary/bgp-hijacking/ https://www.cloudflare.com/learning/security/glossary/bgp-hi... there will be no trace.
  - jakeogh 7y ago
    Bugs in the build system are just bugs, quite possibly security bugs but still set in stone. Reproducible builds have no point if you distribution is broken and cant actually cant verify they are reproduced. You could have just asked "What if the reproduced build isn't?". It's not a reason to not be able to reproduce the image. We know how to publish the input and output hashes. It's one of the use cases for a global ledger. Using CF's trust root would be pointless.

Godel_unicode 7y ago

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...