91–100 of 117 posts
Earlier quoted context omitted.
Reproducible builds can't prevent hidden malware. They don't do much at all for security.
It forces logging of the malware, globally. That's worse than maybe getting caught.
If somebody had stolen the signing keys and could do a https://www.cloudflare.com/learning/security/glossary/bgp-hi... there will be no trace.
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…
Relevant xkcd: https://xkcd.com/1200/
"Unpatched KDE vulnerability disclosed on Twitter"
https://www.zdnet.com/article/unpatched-kde-vulnerability-di...
Earlier quoted context omitted.
When you attack a server, you don't use a virus, you use a phish or something else to gain access to it to do your dirty bidding. What people call "viruses" usually refer only to attacks that work by getting people to execute random crap on their computer with their privileges. Servers are set up and administered in a way such that it is far harder to get somebody to run the payload containing the virus in the first…
It occurs to me that malicious code that scans WordPress etc. sites for vulnerabilities, installs itself, and sends spam and propagates itself does match the general shape of a virus (even to the point where pattern-matching antivirus would genuinely be effective against it). We just for whatever reason tend not to refer to it as a "WordPress virus," but rather e.g. a "reverse shell" or a "botnet."
Earlier quoted context omitted.
It forces logging of the malware, globally. That's worse than maybe getting caught.
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-hi... there will be no trace.
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.
Earlier quoted context omitted.
> 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 experimen…
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 pa…
Earlier quoted context omitted.
> Most malware code I've seen is terribly written and barely works. Yeaah cause someone is just going to be so kind enough to share their perfect example of what malware code should look like to the rest of the world.. (actually there's an F ton available on Github, quasar, pupyrat, etc) Don't be so naive man. As a hobbyist malware programmer myself, I know that you don't know what you're really talking about other t…
> As a hobbyist malware programmer myself, I know that you don't know what you're really talking about Let's see some of your code.
Earlier quoted context omitted.
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 pa…
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.
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.
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/
All the npm cases I can think of have been in javascript code, not 'binaries'. So that wouldn't have prevented any of them.
Ultimately the problem doesn't have a good solution right now. Reproducible builds are a part of the solution, as is making it harder for malicious debian packagers to upload infected binaries. You need to protect the entire supply chain.
Earlier quoted context omitted.
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.
> 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 experimen…
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
[2] https://security.stackexchange.com/questions/3422/what-is-th...