3 ms·

> Nothing short of a full code review will save you from a malicious supply chain attack. Nonsense. Or, at least, an oversimplication. https://medium.com/agor

> Nothing short of a full code review will save you from a malicious supply chain attack. Nonsense. Or, at least, an oversimplication. https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even... Nothing short of full code review will ensure that malicious code from a dependency doesn’t get into your program at all, but the capabilities of that malicious code once it does get into your program can certainly be limited.

munk-a 5y ago
I don't disagree that Javascript in general runs with a lot more permissions than should probably be given but permissions is a very hard thing to manage. So you decide to install a node package that helps retry and automatically back off requests you want to send to your server since you're working in a mobile environment that has sketchy internet reliability... it is very hard to craft a set of permissions to allow that package to retry requests to certain addresses you'd like to retry without also letting it throw random system metrics it's collecting to an ad-server. Additionally, these permissions will be more comprehensible to review but they still need to be reviewed and reviewed by a party you trust. That's a tall order for the open source community when it comes to a volume of packages like npm or composer. You can logically look at lpad as a package and say "We're padding strings, we don't need to do anything with network traffic or disk reads" but building an automated system to make that evaluation and saving that evaluation in a tamperproof manner is going to be hard... and what happens if lpad starts trying to do a better job - operating correctly in left-to-right character sets and in languages where alignment is dictated by hyphens instead of blank space. Code isn't simple and while the above statement may seem hyperbolic I think it's just because most of us accept the risk, it's highly unlikely that malicious supply chain attacks will suddenly sink our businesses so we accept a reasonable level of security in exchange for what feels like a modest risk but actually fully 100% preventing that risk? You'll need to check every usage scenario on every set of hardware and go through that code with a fine toothed comb.
- ryukafalz 5y ago
  > it is very hard to craft a set of permissions to allow that package to retry requests to certain addresses you'd like to retry without also letting it throw random system metrics it's collecting to an ad-server If you're expecting to have to craft ACLs program-wide for that package, then sure, that's going to be hard. That's more coarse-grained than what I'm talking about here though. Imagine, if you will, a programming environment where modules you load don't have any authority to access the network, filesystem, etc unless you pass them in. They're just not in scope. In such a language, the default way to grant HTTP access might look like this in pseudo-Python: http = require("http") myMaliciousLibrary = require("myMaliciousLibrary", http=http) Now, this library has the problem you mentioned; it can make arbitrary outgoing HTTP requests, meaning it can send any metrics it collects to an ad server. It can't access the filesystem because the filesystem isn't in scope either, so what it can collect is limited, but still more access than it needs. So here's one way you might fix that (obviously highly simplified/incomplete in its implementation): class ProxyHTTP(origin="https://example.com", http): def __init__(origin="https://example.com"): self.allowed_origin = origin def get(origin, path="/"): return http.get(self.allowed_origin, path) http = require("http") myMaliciousLibrary = require("myMaliciousLibrary", http=ProxyHTTP(origin="https://good-site.example.com", http)) Now, this version of myMaliciousLibrary gets an object that looks like the http library it would normally use; it just happens to ignore the origin parameter that the library passes to it and uses the one it was initialized with instead. Now, that library can make requests to good-site.example.com, but if it tries to make a request to adserver.evil.com, it'll go to good-site.example.com instead. (You might also imagine a version of ProxyHTTP that just throws an error if the request's origin isn't the same one it was initialized with, or isn't in a list it was initialized with.) Most of today's programming languages aren't strict enough to enable this of course; JavaScript isn't there yet for example, and most other languages aren't even close to being able to do this. But that's mostly because they don't provide strict enough encapsulation, not because they're lacking some complex security enforcement mechanism. > I think it's just because most of us accept the risk, it's highly unlikely that malicious supply chain attacks will suddenly sink our businesses so we accept a reasonable level of security in exchange for what feels like a modest risk I just think people are accepting way more risk than they realize, given the number of dependencies in modern applications and the amount of access each of those dependencies have. It feels crazy that any one of those dependencies in any application could exfiltrate massive amounts of sensitive data from any machine it happens to run on.

munk-a 5y ago

I don't disagree that Javascript in general runs with a lot more permissions than should probably be given but permissions is a very hard thing to manage. So you decide to install a node package that helps retry and automatically back off requests you want to send to your server since you're working in a mobile environment that has sketchy internet reliability... it is very hard to craft a set of permissions to allow that package to retry requests to certain addresses you'd like to retry without also letting it throw random system metrics it's collecting to an ad-server. Additionally, these permissions will be more comprehensible to review but they still need to be reviewed and reviewed by a party you trust. That's a tall order for the open source community when it comes to a volume of packages like npm or composer. You can logically look at lpad as a package and say "We're padding strings, we don't need to do anything with network traffic or disk reads" but building an automated system to make that evaluation and saving that evaluation in a tamperproof manner is going to be hard... and what happens if lpad starts trying to do a better job - operating correctly in left-to-right character sets and in languages where alignment is dictated by hyphens instead of blank space. Code isn't simple and while the above statement may seem hyperbolic I think it's just because most of us accept the risk, it's highly unlikely that malicious supply chain attacks will suddenly sink our businesses so we accept a reasonable level of security in exchange for what feels like a modest risk but actually fully 100% preventing that risk? You'll need to check every usage scenario on every set of hardware and go through that code with a fine toothed comb.

ryukafalz 5y ago
> it is very hard to craft a set of permissions to allow that package to retry requests to certain addresses you'd like to retry without also letting it throw random system metrics it's collecting to an ad-server If you're expecting to have to craft ACLs program-wide for that package, then sure, that's going to be hard. That's more coarse-grained than what I'm talking about here though. Imagine, if you will, a programming environment where modules you load don't have any authority to access the network, filesystem, etc unless you pass them in. They're just not in scope. In such a language, the default way to grant HTTP access might look like this in pseudo-Python: http = require("http") myMaliciousLibrary = require("myMaliciousLibrary", http=http) Now, this library has the problem you mentioned; it can make arbitrary outgoing HTTP requests, meaning it can send any metrics it collects to an ad server. It can't access the filesystem because the filesystem isn't in scope either, so what it can collect is limited, but still more access than it needs. So here's one way you might fix that (obviously highly simplified/incomplete in its implementation): class ProxyHTTP(origin="https://example.com", http): def __init__(origin="https://example.com"): self.allowed_origin = origin def get(origin, path="/"): return http.get(self.allowed_origin, path) http = require("http") myMaliciousLibrary = require("myMaliciousLibrary", http=ProxyHTTP(origin="https://good-site.example.com", http)) Now, this version of myMaliciousLibrary gets an object that looks like the http library it would normally use; it just happens to ignore the origin parameter that the library passes to it and uses the one it was initialized with instead. Now, that library can make requests to good-site.example.com, but if it tries to make a request to adserver.evil.com, it'll go to good-site.example.com instead. (You might also imagine a version of ProxyHTTP that just throws an error if the request's origin isn't the same one it was initialized with, or isn't in a list it was initialized with.) Most of today's programming languages aren't strict enough to enable this of course; JavaScript isn't there yet for example, and most other languages aren't even close to being able to do this. But that's mostly because they don't provide strict enough encapsulation, not because they're lacking some complex security enforcement mechanism. > I think it's just because most of us accept the risk, it's highly unlikely that malicious supply chain attacks will suddenly sink our businesses so we accept a reasonable level of security in exchange for what feels like a modest risk I just think people are accepting way more risk than they realize, given the number of dependencies in modern applications and the amount of access each of those dependencies have. It feels crazy that any one of those dependencies in any application could exfiltrate massive amounts of sensitive data from any machine it happens to run on.