9 ms·

Dependencies are a major attack vector now. Tread carefully with all the supply chain attacks out there, it might not even be the authors doing these. We are e

Dependencies are a major attack vector now. Tread carefully with all the supply chain attacks out there, it might not even be the authors doing these. We are entering a dependency attack massive war. Dependencies are a balance but also a sign of weakness of a system in the modern day. There at least needs to be delayed, dependency bot like analysis before you integrate. Even then, they just leave your systems open to worse than DLL hell, telemetry tracking/data, and attack vectors that can take down or target many, many systems.

xg15 5y ago
How about using dependencies but pinning the version and only updating if you know what the update contains? I'm still continually baffled that we ended up in a world where automatically accepting updates from every dev and their dog is not just the norm but recommended practice.
- hombre_fatal 5y ago
  You also have to rely on all of your dependencies doing that for their dependencies and so on. It’s really a mindset/vigilance you need for the whole ecosystem.
  - xg15 5y ago
    Transitive dependencies are also your dependencies, even if you didn't consciously include them. So in an ideal world, you should vet all changes to dependencies of your codebase, including transitive dependencies. Whether or not this would be compatible with the way dependencies are used today is another question.
    - hnick 5y ago
      I'm not even sure it's not a fool's errand with the current software ecosystem. I think at some point it will have to be a language level feature. The ability to sandbox or provide permissions to packages/functions. Just like our OS had to, just like browsers had to, just like phones had to. Our code is the platform, the packages the apps. It's a similar use case. If I could download a module, and tell the compiler this module, and everything it uses (including packages that I also use, but through a different call tree) will never access the network or write to disk, it'd help grant some small peace of mind in terms of security at least.
      - giaour 5y ago
        Doesn't deno take this approach? The runtime does kinda force the question by only supporting imports via fully qualified URLs.
        hnick 5y ago
        It might, I'm not familiar but after a quick look it seems to operate on a vetted trust model i.e. you can use these because we checked and they are compatible. So you could miss out on a lot of the ecosystem. I was leaning more towards the web approach where we assume everyone is out to get us, but they can't unless we give them that one permission they need. If it's a statically typed language then it'd even allow dependency walking to see what permissions are used at a granular level and we can decide not to bring in anything that's too loose. This of course won't solve cases like logic bugs, but it'd help mitigate the impact. I'm just not sure if it's even feasible?
        giaour 5y ago
        I was thinking of their scoped permissions model described at https://medium.com/deno-tutorial/deno-security-65af9811d9c9 https://medium.com/deno-tutorial/deno-security-65af9811d9c9 Not sure if you can scope down permissions as part of an module import or if it only works when you initialize the interpreter
        kilburn 5y ago
        The checked and compatible stdlib is an extra provided by the project. Deno runs code in a sandbox where you need to give permissions to scripts/modules for them to access local files, the network, etc: https://deno.land/manual@v1.17.2/getting_started/permissions https://deno.land/manual@v1.17.2/getting_started/permissions
        zkldi 5y ago
        Yes, but it's not granular. You either let all modules have permission X, or none of them.
      - 5y ago
- jbverschoor 5y ago
  Yeah I also don’t understand. But then again.. the js ecosystem is one big pile of turds.. Tech cycles with people who reinvent the wheel and keep making the same mistakes All these problems have long been solved
  - ethbr0 5y ago
    They were solved in a way that slowed progress. So invariably, people discovered that if they threw out the complexities of the solutions, they could make faster progress. Then they eventually ran into the corner cases. That's the time loop that keeps happening.
    - xg15 5y ago
      Yeah, this seems less like actual progress and more that people wanted to drive in circles faster.
  - ironmagma 5y ago
    The problem of new versions of dependencies breaking old code happens all the time in a variety of ecosystems. It's not exactly "solved," it's a continual problem similar to picking what you will eat for dinner. There are pros and cons to each approach, in this case the con is that every now and then you have to manually pin a version. If we did it the other way, we would have to manually upgrade versions to get obvious and easy improvements. As with most things people happily call "turds," it's actually a tradeoff and not as simple as just being bad. As for reinventing the wheel, are wheels really settled science? As far as I know, new kinds of wheels are being created all the time. It's not just that new people are creating them, there are new things wheels need to do every day and new sets of requirements that the old existing wheel designs don't fulfill. Look at wheels from 50 years ago and they are nothing like the wheels of today. The wheels on cars are nothing like the wheels on aircraft, which in turn are nothing like the wheels on trains.
- fennecfoxen 5y ago
  "Pinning the version" is inadequate. Do a shasum on the package contents. (Thanks, Poetry.)
- UncleMeat 5y ago
  > only updating if you know what the update contains People suck at this. What this actually tends to do is mean "no updates, ever" unless you have a particularly rigorous culture of dependency management.
  - xg15 5y ago
    Or we get a culture where upstream writes in more detail what an upstream is supposed to contain and downstream verifies that the update indeed does what they write. If this leads to fewer updates overall, I have no problem with that.
    - tremon 5y ago
      If you change "contain" to "do", then this is the MAC security model as implemented by SELinux. a culture where upstream writes in more detail what their code is supposed to do and downstream enforces that the software indeed does (not do anything beyond) what they specified It didn't lead to fewer updates, it led to less usage of SELinux.
- staticassertion 5y ago
  > if you know what the update contains? I think anyone who thinks they're doing this is fooling themselves. You can review code for accidental vulnerabilities but if someone is trying to slip in a backdoor it shouldn't be hard to do so in a stealthy manner. The reality is that the entire dependency concept is just broken. There is an implicit trust that all dependencies are equally trusted. Your logging package is just as capable of performing file and network operations as your http package, even if you assume it won't. That's silly. It is up to programming languages and package managers to solve these problems. They're also not that hard to solve, in my opinion. "Run arbitrary code on a computer" is a model we've been securing for decades with web browsers, both in terms of web pages and extensions, and now too with mobile. Solving "this code can do X but that code shouldn't be able to" is similarly easy to solve with languages that support effects or capabilities. It just hasn't been done yet.
  - Gigachad 5y ago
    Permissions inside a programs own code seems incredibly difficult without radical change.
    - staticassertion 5y ago
      Pony's object capabilities are one example of an existing implementation. I don't think there's any "inventing" To do here, it's all just implementation work.
    - naasking 5y ago
      It's actually trivially easy once you remove ambient authority, which is the real source of these security problems. Consider how a program could modify your files if it cannot willy-nilly turn any old string into a file handle.
  - xg15 5y ago
    Adding permissions is a reasonable step, but I don't think it solves the problem. We know, it's very hard to get granularity right with permission systems and there is a strong temptation to just give everything all permissions. Dependencies with dangerous but necessary permissions can still abuse them: Your network library will still be able to add a bitcoin miner. What happened if an update requests a new permission? Also, how would that have prevented the current situation? Infinite loops are famously hard to detect and prevent automatically.
- justinpombrio 5y ago
  > I'm still continually baffled that we ended up in a world where automatically accepting updates from every dev and their dog is not just the norm but recommended practice. I think it follows from two things: 1. We use open source software for everything. This is also true of our dependencies, so we get hundreds or thousands of transitive dependencies. Many of which are presumably written by dogs, because (i) no one can tell if you're a dog on the internet, and (ii) OSS maintainers are so overworked they ask their dogs for help. 2. Languages and libraries are full of footguns, software is full of bugs and therefore vulnerabilities, and no one cares enough to go through the enormous effort to fix things. And this is true through the whole stack. So the only practical way to stay secure-ish is to reactively patch software as vulnerabilities are publicly discovered. And also defence in depth. (I would distinguish between the publicly known time that a vulnerability is discovered, and the first time it was discovered. You hope the two are the same but for many vulnerabilities, if a clever adversary found them first we'd never know.) With these two things together, you have a ton of questionable dependencies, and you need to update them all the time for security reasons.
  - xg15 5y ago
    Yeah I guess then we can just shrug and go on because there is nothing we can do to stop our app from randomly breaking tomorrow. > So the only practical way to stay secure-ish is to reactively patch software as vulnerabilities are publicly discovered. But this is different from just blindly accepting any update that upstream gives you. > And also defence in depth. This sounds increasingly like security theater. You can always more layers obstacles to make things harder for malware that is already on your system, but it's not clear to me how much this actually reduces your atrack surface.
    - bostik 5y ago
      Defense in depth implies a whole lot of things, and is certainly not security theater. Usually it boils down to three major themes: 1. Reduce blast radius: assuming component X is compromised, how far and wide can it be felt? 2: Principle of least privilege: once compromised, what can X do or access? Extend to the credentials X carries or has access to. 3: Detection: how early and how well can you detect the compromise in previous two steps? You can never prevent a compromise, but you can make it easier to notice when it has happened, and you can limit what the attackers can do afterwards.
- Sohcahtoa82 5y ago
  Because dependencies of dependencies exist, and if you use a large framework of some sort, you could end up with literally over 1,000 dependencies. Manually checking before updating does not scale.
zaroth 5y ago
Crazy what happens when you decide to freeload off a stranger’s code who you have no contract or agreement with whatsoever, beyond a license you must accept to use the software which disclaims any warranty whatsoever, even fitness for any purpose. I have zero sympathy for anyone complaining they were hurt by this. I think Marak is teaching an important and principled lesson here.
- balls187 5y ago
  > I think Marak is teaching an important and principled lesson here. What lesson is that?
  - darthrupert 5y ago
    Never rely on the Javascript community/ecosystem.
  - obviousanswer9 5y ago
    - greggman3 5y ago
      > these trillion dollar corporations just take and take and never give, Which trillion dollar corporations are these? A quick google says "Apple, Microsoft, Alphabet, Amazon, Telsa, Meta, NVidia, and Berkshire Hathaway" are the the only trillion dollar companies Except for the last one all of those companies give back vast amounts of open source support. All you using VSCode for free, that's Microsoft's payback. Oh, and Microsoft pays for NPM hosting and github, also Typescript, C#, F#, .NET. Hardly not giving anything back. Apple gives Swift, Clang, LLVM, Webkit to name a few. Alphabet, Go, Chrome (which also means Electron on which VSCode is running), Android, and plenty of others. Meta provides React, Redux. Not sure what open source Tesla gives back but they have given their patents (https://www.tesla.com/blog/all-our-patent-are-belong-you https://www.tesla.com/blog/all-our-patent-are-belong-you). Nvidia gives away tons of open source as well (https://developer.nvidia.com/open-source https://developer.nvidia.com/open-source)

xg15 5y ago

How about using dependencies but pinning the version and only updating if you know what the update contains? I'm still continually baffled that we ended up in a world where automatically accepting updates from every dev and their dog is not just the norm but recommended practice.

hombre_fatal 5y ago
You also have to rely on all of your dependencies doing that for their dependencies and so on. It’s really a mindset/vigilance you need for the whole ecosystem.
- xg15 5y ago
  Transitive dependencies are also your dependencies, even if you didn't consciously include them. So in an ideal world, you should vet all changes to dependencies of your codebase, including transitive dependencies. Whether or not this would be compatible with the way dependencies are used today is another question.
  - hnick 5y ago
    I'm not even sure it's not a fool's errand with the current software ecosystem. I think at some point it will have to be a language level feature. The ability to sandbox or provide permissions to packages/functions. Just like our OS had to, just like browsers had to, just like phones had to. Our code is the platform, the packages the apps. It's a similar use case. If I could download a module, and tell the compiler this module, and everything it uses (including packages that I also use, but through a different call tree) will never access the network or write to disk, it'd help grant some small peace of mind in terms of security at least.
    - giaour 5y ago
      Doesn't deno take this approach? The runtime does kinda force the question by only supporting imports via fully qualified URLs.
      - hnick 5y ago
        It might, I'm not familiar but after a quick look it seems to operate on a vetted trust model i.e. you can use these because we checked and they are compatible. So you could miss out on a lot of the ecosystem. I was leaning more towards the web approach where we assume everyone is out to get us, but they can't unless we give them that one permission they need. If it's a statically typed language then it'd even allow dependency walking to see what permissions are used at a granular level and we can decide not to bring in anything that's too loose. This of course won't solve cases like logic bugs, but it'd help mitigate the impact. I'm just not sure if it's even feasible?
        giaour 5y ago
        I was thinking of their scoped permissions model described at https://medium.com/deno-tutorial/deno-security-65af9811d9c9 https://medium.com/deno-tutorial/deno-security-65af9811d9c9 Not sure if you can scope down permissions as part of an module import or if it only works when you initialize the interpreter
        kilburn 5y ago
        The checked and compatible stdlib is an extra provided by the project. Deno runs code in a sandbox where you need to give permissions to scripts/modules for them to access local files, the network, etc: https://deno.land/manual@v1.17.2/getting_started/permissions https://deno.land/manual@v1.17.2/getting_started/permissions
        zkldi 5y ago
        Yes, but it's not granular. You either let all modules have permission X, or none of them.
    - 5y ago
jbverschoor 5y ago
Yeah I also don’t understand. But then again.. the js ecosystem is one big pile of turds.. Tech cycles with people who reinvent the wheel and keep making the same mistakes All these problems have long been solved
- ethbr0 5y ago
  They were solved in a way that slowed progress. So invariably, people discovered that if they threw out the complexities of the solutions, they could make faster progress. Then they eventually ran into the corner cases. That's the time loop that keeps happening.
  - xg15 5y ago
    Yeah, this seems less like actual progress and more that people wanted to drive in circles faster.
- ironmagma 5y ago
  The problem of new versions of dependencies breaking old code happens all the time in a variety of ecosystems. It's not exactly "solved," it's a continual problem similar to picking what you will eat for dinner. There are pros and cons to each approach, in this case the con is that every now and then you have to manually pin a version. If we did it the other way, we would have to manually upgrade versions to get obvious and easy improvements. As with most things people happily call "turds," it's actually a tradeoff and not as simple as just being bad. As for reinventing the wheel, are wheels really settled science? As far as I know, new kinds of wheels are being created all the time. It's not just that new people are creating them, there are new things wheels need to do every day and new sets of requirements that the old existing wheel designs don't fulfill. Look at wheels from 50 years ago and they are nothing like the wheels of today. The wheels on cars are nothing like the wheels on aircraft, which in turn are nothing like the wheels on trains.
fennecfoxen 5y ago
"Pinning the version" is inadequate. Do a shasum on the package contents. (Thanks, Poetry.)
UncleMeat 5y ago
> only updating if you know what the update contains People suck at this. What this actually tends to do is mean "no updates, ever" unless you have a particularly rigorous culture of dependency management.
- xg15 5y ago
  Or we get a culture where upstream writes in more detail what an upstream is supposed to contain and downstream verifies that the update indeed does what they write. If this leads to fewer updates overall, I have no problem with that.
  - tremon 5y ago
    If you change "contain" to "do", then this is the MAC security model as implemented by SELinux. a culture where upstream writes in more detail what their code is supposed to do and downstream enforces that the software indeed does (not do anything beyond) what they specified It didn't lead to fewer updates, it led to less usage of SELinux.
staticassertion 5y ago
> if you know what the update contains? I think anyone who thinks they're doing this is fooling themselves. You can review code for accidental vulnerabilities but if someone is trying to slip in a backdoor it shouldn't be hard to do so in a stealthy manner. The reality is that the entire dependency concept is just broken. There is an implicit trust that all dependencies are equally trusted. Your logging package is just as capable of performing file and network operations as your http package, even if you assume it won't. That's silly. It is up to programming languages and package managers to solve these problems. They're also not that hard to solve, in my opinion. "Run arbitrary code on a computer" is a model we've been securing for decades with web browsers, both in terms of web pages and extensions, and now too with mobile. Solving "this code can do X but that code shouldn't be able to" is similarly easy to solve with languages that support effects or capabilities. It just hasn't been done yet.
- Gigachad 5y ago
  Permissions inside a programs own code seems incredibly difficult without radical change.
  - staticassertion 5y ago
    Pony's object capabilities are one example of an existing implementation. I don't think there's any "inventing" To do here, it's all just implementation work.
  - naasking 5y ago
    It's actually trivially easy once you remove ambient authority, which is the real source of these security problems. Consider how a program could modify your files if it cannot willy-nilly turn any old string into a file handle.
- xg15 5y ago
  Adding permissions is a reasonable step, but I don't think it solves the problem. We know, it's very hard to get granularity right with permission systems and there is a strong temptation to just give everything all permissions. Dependencies with dangerous but necessary permissions can still abuse them: Your network library will still be able to add a bitcoin miner. What happened if an update requests a new permission? Also, how would that have prevented the current situation? Infinite loops are famously hard to detect and prevent automatically.
justinpombrio 5y ago
> I'm still continually baffled that we ended up in a world where automatically accepting updates from every dev and their dog is not just the norm but recommended practice. I think it follows from two things: 1. We use open source software for everything. This is also true of our dependencies, so we get hundreds or thousands of transitive dependencies. Many of which are presumably written by dogs, because (i) no one can tell if you're a dog on the internet, and (ii) OSS maintainers are so overworked they ask their dogs for help. 2. Languages and libraries are full of footguns, software is full of bugs and therefore vulnerabilities, and no one cares enough to go through the enormous effort to fix things. And this is true through the whole stack. So the only practical way to stay secure-ish is to reactively patch software as vulnerabilities are publicly discovered. And also defence in depth. (I would distinguish between the publicly known time that a vulnerability is discovered, and the first time it was discovered. You hope the two are the same but for many vulnerabilities, if a clever adversary found them first we'd never know.) With these two things together, you have a ton of questionable dependencies, and you need to update them all the time for security reasons.
- xg15 5y ago
  Yeah I guess then we can just shrug and go on because there is nothing we can do to stop our app from randomly breaking tomorrow. > So the only practical way to stay secure-ish is to reactively patch software as vulnerabilities are publicly discovered. But this is different from just blindly accepting any update that upstream gives you. > And also defence in depth. This sounds increasingly like security theater. You can always more layers obstacles to make things harder for malware that is already on your system, but it's not clear to me how much this actually reduces your atrack surface.
  - bostik 5y ago
    Defense in depth implies a whole lot of things, and is certainly not security theater. Usually it boils down to three major themes: 1. Reduce blast radius: assuming component X is compromised, how far and wide can it be felt? 2: Principle of least privilege: once compromised, what can X do or access? Extend to the credentials X carries or has access to. 3: Detection: how early and how well can you detect the compromise in previous two steps? You can never prevent a compromise, but you can make it easier to notice when it has happened, and you can limit what the attackers can do afterwards.
Sohcahtoa82 5y ago
Because dependencies of dependencies exist, and if you use a large framework of some sort, you could end up with literally over 1,000 dependencies. Manually checking before updating does not scale.

zaroth 5y ago

Crazy what happens when you decide to freeload off a stranger’s code who you have no contract or agreement with whatsoever, beyond a license you must accept to use the software which disclaims any warranty whatsoever, even fitness for any purpose. I have zero sympathy for anyone complaining they were hurt by this. I think Marak is teaching an important and principled lesson here.

balls187 5y ago
> I think Marak is teaching an important and principled lesson here. What lesson is that?
- darthrupert 5y ago
  Never rely on the Javascript community/ecosystem.
- obviousanswer9 5y ago
  - greggman3 5y ago
    > these trillion dollar corporations just take and take and never give, Which trillion dollar corporations are these? A quick google says "Apple, Microsoft, Alphabet, Amazon, Telsa, Meta, NVidia, and Berkshire Hathaway" are the the only trillion dollar companies Except for the last one all of those companies give back vast amounts of open source support. All you using VSCode for free, that's Microsoft's payback. Oh, and Microsoft pays for NPM hosting and github, also Typescript, C#, F#, .NET. Hardly not giving anything back. Apple gives Swift, Clang, LLVM, Webkit to name a few. Alphabet, Go, Chrome (which also means Electron on which VSCode is running), Android, and plenty of others. Meta provides React, Redux. Not sure what open source Tesla gives back but they have given their patents (https://www.tesla.com/blog/all-our-patent-are-belong-you https://www.tesla.com/blog/all-our-patent-are-belong-you). Nvidia gives away tons of open source as well (https://developer.nvidia.com/open-source https://developer.nvidia.com/open-source)