4 ms·

I’m increasingly fatalistic about computer security. It seems like your options are carefully auditing all dependencies (difficult and maybe impossible if the d

by thorum 5y ago

I’m increasingly fatalistic about computer security. It seems like your options are carefully auditing all dependencies (difficult and maybe impossible if the dependencies are highly technical or the malicious code is sufficiently subtle or obfuscated) every time you update, not updating at all (which leaves you vulnerable to all the bugs and other security issues in the version you choose to pin), or not using dependencies at all (by spending months or years totally rewriting the libraries and tools you need, and of course your own code will have bugs too). Fixing the points addressed in this article helps by making it harder to slip these backdoors in, but will never be foolproof unless every single library has a maintainer with the skills to detect subtle bugs and security issues, who audits every line of code. Even then the marketplace for unreported zero day vulnerabilities means that there are probably undiscovered vulnerabilities somewhere in your dependencies (or in the code for your IDE or OS or Spotify app or mouse driver...) that can be exploited by someone. I’m reminded of the Commonwealth series by Peter Hamilton, in which the invading aliens have no machines, and quickly discover that ours are full of bugs that can be exploited to turn against us. I don’t know what the solution is. Sandboxing your development in a codespace like Gitpod is a big improvement for sure, but even in Gitpod a lot of people import credentials and environment variables that can be stolen. (And what dependencies is Gitpod itself running?)

remus 5y ago
> I’m increasingly fatalistic about computer security. It seems like your options are carefully auditing all dependencies (difficult and maybe impossible if the dependencies are highly technical or the malicious code is sufficiently subtle or obfuscated) every time you update, not updating at all (which leaves you vulnerable to all the bugs and other security issues in the version you choose to pin), or not using dependencies at all (by spending months or years totally rewriting the libraries and tools you need, and of course your own code will have bugs too). There is also the option of having trusted third parties review code. This is by no means an easy option but it does seem more feasible than everyone auditing every line of code they ever depend on. You do end up with spicy questions like who do we trust to audit code? Why do we trust them? How are they actually auditing this code?
- worik 5y ago
  But that costs money. Money that if not spent, goes straight to the profit line
- rectang 5y ago
  The big problem is not bugs, not vulnerabilities, but malicious code inserted deliberately into packages published by attackers. One way to detect malicious code is line-by-line code review of published packages, but that's extremely laborious, even when done by third parties. What we really want to do is confirm that the package was the end product of an open source commit history, where commits were reviewed by a set of trusted authors (hey look third parties!) over time. That involves strong validation of publisher identities and cryptographic validation of the package contents to connect it to a commit history in a trusted public repository.
- _tom_ 5y ago
  Another option is reducing number of dependencies. Doesn't cure the problem but can cut the vulnerability surface by orders of magnitude. Transitive dependencies can, and frequently do result in The majority of the code in an application being unneeded. Using one function from a dependency can result in whole sets of libraries or even whole languages being included in the project.
worik 5y ago
But there it can be so much better, or so much worse. Worse is Node.js (not bothering with the unanswerable question: Why Node.js?) thousands and thousands of package downloads. Long chains of transitive dependencies. A long storied history of security/reliability catastrophes. I love Rust. But I have always thought having the compiler download dependencies is a very bad idea. It would be much better if the programmer had to deliberately install the dependencies. Then there would be an incentive to have less dependencies. This is currently a shit show, because it is easier to write than read, to talk than listen. New generations of programmers refuse to learn the lessons of their forebears and repeat all their mistakes, harder, bigger, faster
throwawaygh 5y ago
> carefully auditing all dependencies (difficult and maybe impossible if the dependencies are highly technical or the malicious code is sufficiently subtle or obfuscated) ...yeah, a business is responsible for the integrity of its supply chain. There's nothing fatalistic about this. Running a business with potential liabilities is different from having a high school programming hobby. If you're using community distributions of open source software in a security-critical context (e.g., any machine that touches PII) then you should absolutely white-list dependencies and either (1) have internal auditing mechanisms in place for those dependencies or else (2) have good reason to trust the QA procedures of the underlying community (and still do some basic auditing on every update anyways). Everything else should be carefully sand-boxed and basically assumed to be pwned/pwnable. If some rando came up to your contractor and offered them free concrete for use in your foundation, and the contractor said yes without any due dilligence, you would have every right to sue that contractor out of existence. The www isn't a wild west anymore. The era where any middle schooler can build a six figure business by serving as the middle man between open source packages and end-users should probably come to a close. And I say that as someone whose middle school software freelancing business cleared lots of revenue by the end of college. I wonder if this could be a revenue model of OSS. Cyber insurance providers should probably stat weighing in on these supply chain issues soon.
froh 5y ago
I think we have, as an industry, for a long time not seen the true value proposition of "Linux distributions". They do quite some boring and tedious security auditing, for example review setuid binaries to the point they drop from root into user privileges; and they backport security patches, so security updates are binary compatible drop in replacements. When a binary distribution is widely used, the beneift is shared bug fixing and hardening, the disadvantage is somewhat dated libraries. It's a model I understand. What I don't understand is this idea of bootstrapping infrastructure via curl https://..../setup.sh https://..../setup.sh && ./setup.sh, and the equivalent import of "modules", whatever you call them in your language of choice, straight from the web.
Groxx 5y ago
I'm gonna pimp my own complaint here: https://news.ycombinator.com/item?id=29125409 https://news.ycombinator.com/item?id=29125409 I think library permissions systems would mitigate or effectively eliminate a huge amount of these, and significantly raise the cost or reduce the targets of nearly all attacks. Libraries are, in practice, treated as black boxes. I think that's largely reasonable - that's almost the whole point of leveraging someone else's work. But our languages/etc do not allow doing that in any sane way. I think that's completely ridiculous.
- jiggawatts 5y ago
  The one thing I like about the Rust crates ecosystem is that crates have "tags" along the lines of "nostd" and the like. That's a good idea, but it wasn't taken anywhere near far enough as a policy. The technology is like 90% there, it just needs that 10% to be super useful. For example, did you know that a "Rust" crate can be 99.999% C/C++ code? A lot of them are. Some typo squatter basically wrapped a bunch of libraries like "libpng" and whatnot. Behind the scenes, all of these "Rust crates" are invoking cc and won't even build if you're on certain Rust toolchains! There's no indication of this on crates.io. Imagine if crates were scanned automatically by something like Microsoft's Roslyn and each crate and crate version had automatic tags along the lines of "pure Rust", "Safe Rust only", "Uses only std", "processor portable" (no-CPU-specific conditional compilation), "platform portable" (no Linux/Windows conditional compilation), etc... Obviously, the transitive dependencies would then bubble up. So if a crate that says "portable" has a dependency that changes from "portable" to "Linux-specific", then the crate should lose the "portable" tag. The crates.io team would prefer that every Rust user do this themselves. Manually. For every update. Tens of thousands of people doing this work over and over. Forever. I'd like to see this done properly, once, centrally, in a controlled and hard-to-spoof way. Security is not just about memory safety.
  - Groxx 5y ago
    Exactly. And raising awareness of use of these less-than-palatable practices tends to lead to a constant pressure to only use them when strictly necessary, generally leading things to a broadly safer end state. (edit: sorry, I removed the chunk about cargo-geiger: https://crates.io/crates/cargo-geiger https://crates.io/crates/cargo-geiger . tl;dr showing something like that everywhere by default would likely encourage fewer unsafe uses (ideally zero), which would usually be a good thing - there's a lot of flawed unsafe use out there. that's part of why it's unsafe.)
_tom_ 5y ago
I think that the rise of automated dependency resolution tools, like maven, has made this exponentially worse. It's routine for tools to to have hundreds or even thousands of dependencies, something that would never happen if you manually had to manage them. My .m2 directory has 4000+ jar files in it, for example. They make you more productive, but much more vulnerable.
panny 5y ago
>It seems like your options are carefully auditing all dependencies "given enough eyeballs, all bugs are shallow" Rust has an eyeball problem. Not saying this solves everything, but it certainly isn't helping. NPM has had several catastrophic security failures, but they all seem to be noticed rather quickly due only to the staggering number of people using JS.

by thorum 5y ago

remus 5y ago

> I’m increasingly fatalistic about computer security. It seems like your options are carefully auditing all dependencies (difficult and maybe impossible if the dependencies are highly technical or the malicious code is sufficiently subtle or obfuscated) every time you update, not updating at all (which leaves you vulnerable to all the bugs and other security issues in the version you choose to pin), or not using dependencies at all (by spending months or years totally rewriting the libraries and tools you need, and of course your own code will have bugs too). There is also the option of having trusted third parties review code. This is by no means an easy option but it does seem more feasible than everyone auditing every line of code they ever depend on. You do end up with spicy questions like who do we trust to audit code? Why do we trust them? How are they actually auditing this code?

worik 5y ago
But that costs money. Money that if not spent, goes straight to the profit line
rectang 5y ago
The big problem is not bugs, not vulnerabilities, but malicious code inserted deliberately into packages published by attackers. One way to detect malicious code is line-by-line code review of published packages, but that's extremely laborious, even when done by third parties. What we really want to do is confirm that the package was the end product of an open source commit history, where commits were reviewed by a set of trusted authors (hey look third parties!) over time. That involves strong validation of publisher identities and cryptographic validation of the package contents to connect it to a commit history in a trusted public repository.
_tom_ 5y ago
Another option is reducing number of dependencies. Doesn't cure the problem but can cut the vulnerability surface by orders of magnitude. Transitive dependencies can, and frequently do result in The majority of the code in an application being unneeded. Using one function from a dependency can result in whole sets of libraries or even whole languages being included in the project.

worik 5y ago

But there it can be so much better, or so much worse. Worse is Node.js (not bothering with the unanswerable question: Why Node.js?) thousands and thousands of package downloads. Long chains of transitive dependencies. A long storied history of security/reliability catastrophes. I love Rust. But I have always thought having the compiler download dependencies is a very bad idea. It would be much better if the programmer had to deliberately install the dependencies. Then there would be an incentive to have less dependencies. This is currently a shit show, because it is easier to write than read, to talk than listen. New generations of programmers refuse to learn the lessons of their forebears and repeat all their mistakes, harder, bigger, faster

throwawaygh 5y ago

> carefully auditing all dependencies (difficult and maybe impossible if the dependencies are highly technical or the malicious code is sufficiently subtle or obfuscated) ...yeah, a business is responsible for the integrity of its supply chain. There's nothing fatalistic about this. Running a business with potential liabilities is different from having a high school programming hobby. If you're using community distributions of open source software in a security-critical context (e.g., any machine that touches PII) then you should absolutely white-list dependencies and either (1) have internal auditing mechanisms in place for those dependencies or else (2) have good reason to trust the QA procedures of the underlying community (and still do some basic auditing on every update anyways). Everything else should be carefully sand-boxed and basically assumed to be pwned/pwnable. If some rando came up to your contractor and offered them free concrete for use in your foundation, and the contractor said yes without any due dilligence, you would have every right to sue that contractor out of existence. The www isn't a wild west anymore. The era where any middle schooler can build a six figure business by serving as the middle man between open source packages and end-users should probably come to a close. And I say that as someone whose middle school software freelancing business cleared lots of revenue by the end of college. I wonder if this could be a revenue model of OSS. Cyber insurance providers should probably stat weighing in on these supply chain issues soon.

froh 5y ago

I think we have, as an industry, for a long time not seen the true value proposition of "Linux distributions". They do quite some boring and tedious security auditing, for example review setuid binaries to the point they drop from root into user privileges; and they backport security patches, so security updates are binary compatible drop in replacements. When a binary distribution is widely used, the beneift is shared bug fixing and hardening, the disadvantage is somewhat dated libraries. It's a model I understand. What I don't understand is this idea of bootstrapping infrastructure via curl https://..../setup.sh https://..../setup.sh && ./setup.sh, and the equivalent import of "modules", whatever you call them in your language of choice, straight from the web.

Groxx 5y ago

I'm gonna pimp my own complaint here: https://news.ycombinator.com/item?id=29125409 https://news.ycombinator.com/item?id=29125409 I think library permissions systems would mitigate or effectively eliminate a huge amount of these, and significantly raise the cost or reduce the targets of nearly all attacks. Libraries are, in practice, treated as black boxes. I think that's largely reasonable - that's almost the whole point of leveraging someone else's work. But our languages/etc do not allow doing that in any sane way. I think that's completely ridiculous.

jiggawatts 5y ago
The one thing I like about the Rust crates ecosystem is that crates have "tags" along the lines of "nostd" and the like. That's a good idea, but it wasn't taken anywhere near far enough as a policy. The technology is like 90% there, it just needs that 10% to be super useful. For example, did you know that a "Rust" crate can be 99.999% C/C++ code? A lot of them are. Some typo squatter basically wrapped a bunch of libraries like "libpng" and whatnot. Behind the scenes, all of these "Rust crates" are invoking cc and won't even build if you're on certain Rust toolchains! There's no indication of this on crates.io. Imagine if crates were scanned automatically by something like Microsoft's Roslyn and each crate and crate version had automatic tags along the lines of "pure Rust", "Safe Rust only", "Uses only std", "processor portable" (no-CPU-specific conditional compilation), "platform portable" (no Linux/Windows conditional compilation), etc... Obviously, the transitive dependencies would then bubble up. So if a crate that says "portable" has a dependency that changes from "portable" to "Linux-specific", then the crate should lose the "portable" tag. The crates.io team would prefer that every Rust user do this themselves. Manually. For every update. Tens of thousands of people doing this work over and over. Forever. I'd like to see this done properly, once, centrally, in a controlled and hard-to-spoof way. Security is not just about memory safety.
- Groxx 5y ago
  Exactly. And raising awareness of use of these less-than-palatable practices tends to lead to a constant pressure to only use them when strictly necessary, generally leading things to a broadly safer end state. (edit: sorry, I removed the chunk about cargo-geiger: https://crates.io/crates/cargo-geiger https://crates.io/crates/cargo-geiger . tl;dr showing something like that everywhere by default would likely encourage fewer unsafe uses (ideally zero), which would usually be a good thing - there's a lot of flawed unsafe use out there. that's part of why it's unsafe.)

_tom_ 5y ago

I think that the rise of automated dependency resolution tools, like maven, has made this exponentially worse. It's routine for tools to to have hundreds or even thousands of dependencies, something that would never happen if you manually had to manage them. My .m2 directory has 4000+ jar files in it, for example. They make you more productive, but much more vulnerable.

panny 5y ago

>It seems like your options are carefully auditing all dependencies "given enough eyeballs, all bugs are shallow" Rust has an eyeball problem. Not saying this solves everything, but it certainly isn't helping. NPM has had several catastrophic security failures, but they all seem to be noticed rather quickly due only to the staggering number of people using JS.