5 ms·

A lack of imagination by the author, unfortunately... A DoS on your build machine and dev machine can be indeed be critical issues. Imagine this scenario: Yo

A lack of imagination by the author, unfortunately... A DoS on your build machine and dev machine can be indeed be critical issues. Imagine this scenario: Your source code is somehow compromised and attackers slip in rogue code to your production site. It siphons off passwords or other PII. The attackers also take advantage of several of these RegEx DoS vulnerabilities to prevent you from quickly fixing the problem. When you discover the issue, you’ll first see that your build machine is unresponsive, so you can’t just spin a fixed build and re-deploy. You’ll sync your main branch to figure out what is going on, perhaps ready to make a build from your dev machine, but running yarn build hangs. It might take you 1 minute to solve or 5 hours - hard to guess. But every minute you’re delayed is another minute the attacker is siphoning off your production data. npm audit isn’t perfect, but I don’t agree with the author that devDependencies can’t have critical vulnerabilities. Build machines and dev machines are critical infrastructure. Recall the method of attack of SolarWinds [1]. Related: we all trust that the “many eyes” of open source contributors will keep our dependencies relatively clean, but this function is not infinite. There is some threshold of lines of code and rate of change that will outstrip the community’s natural ability to find and fix problems. I wish the npm community was more sensitive to the risks that are inherent in current practices. Efforts to limit dependencies and perhaps somehow tag which versions have completed a security audit (and by whom) would be great to see. [1] https://krebsonsecurity.com/2021/01/solarwinds-what-hit-us-could-hit-others/ https://krebsonsecurity.com/2021/01/solarwinds-what-hit-us-c...

askmike 5y ago
> Your source code is somehow compromised and attackers slip in rogue code to your production site. Really at this point it's too late to do anything else, instead of trying to dos your dev machine he can instead do simpler things like delete your ssh key from the machine. But let's play along: > The attackers also take advantage of several of these RegEx DoS vulnerabilities to prevent you from quickly fixing the problem. When you discover the issue, you’ll first see that your build machine is unresponsive There is nothing any attacker can do with the static files on the server that will trigger and RegEx DoS in your local development. Aside from the fact that you wouldn't download whatever is on the server back to your machine, even if you did it would never trigger such a DoS since (in the examples in the link) these are modules related to running a dev version of a frontend project based on the raw source files. Your scenario is only true when an attacker pwned both your production server and your laptop. A regex DoS is really the last thing you worry about at that stage.
- trunnell 5y ago
  I see your point that even worse things can happen when dev machines are compromised. The point I tried to make is that even a DoS of your machine can be a big problem. > There is nothing any attacker can do with the static files on the server that will trigger a RegEx DoS... IIUC, an attacker could change my package.json to include inputs to browserlist that trigger a RegEx DoS. To do that, the attacker only needs to make a fraudulent commit. Given how easy most teams make it to commit code, this isn’t too high of a bar.
  - nirvdrum 5y ago
    If you, as an attacker, are going to make a fraudulent commit and change package.json, you could just pull in a bogus dependency or add a new script/command that gets run on the build/dev machine. I agree the bar to submitting a fraudulent commit is unfortunately too low for many teams. But, this also extends to package publishing, too. We've seen packages published through compromised dev keys or the maintainer granted a new bad actor rights to publish. Here we could envision a situation where someone reports a legitimate, but low impact, security issue and also publishes a bogus package that everyone is now upgrading to. On the whole, these messages aren't encouraging people to upgrade to a new, verified release (i.e., a fixed version). They're encouraging people to upgrade to the latest release. Even if you suspend the bad actor thought experiment, the latest release of a package in all likelihood hasn't been audited beyond ensuring the previously reported security issue has been addressed. Upgrading indiscriminately is a risky activity as well. I don't think we should be encouraging people to do that (in any language ecosystem). It's not lack of imagination of attack vectors at play here. Treating extremely low risk factors as if they're high priority reduces trust in the system as a whole. Getting developers to care more about security is a laudable effort, but I think the `npm audit` approach (as reported in the post) is going to encourage bad practices.
    - trunnell 5y ago
      I agree with all of your points except for the very last one. Are we shooting the messenger (npm audit) here? Seems like the problem is lack of trust and lack of information about security of dependencies. Npm audit is just pointing that out. The size of the problem makes it very uncomfortable.
dj_mc_merlin 5y ago
1. You wouldn't wait for a full build in that scenario, but deploy a known-good last image or emergency shut down. 2. If you are doing a full build and fail because of the regex DOS, then that build would also contain the attacker injected siphoning code, which would make your entire exercise futile in the first place 3. Not obviously messing with the network or crashing build machines would be a better way of siphoning data for longer. 4. This is very contrived.
smsm42 5y ago
I think if the attacker got as far as deploy their code in your CI/CD pipeline and prod system, there's no "quickly" fixing it. There's a full shut down, restoring from trusted backup, full data and code audit and a lot of pain in the future validating and restoring the code and the data. Quick rebuild is not something that would be your priority there - how do you know this quick build won't be compromised anyway? If somebody got into your internal systems on the level they could modify the code, it's not a 1 minute problem and not a 5 hours problem, it's much bigger...
- trunnell 5y ago
  I think the typical scenario is that you understand how big of problem it is only in retrospect. In the moment, your first thought is that there is some type of quick fix that will restore functionality (if your site is down) or evict the intruder if something funny is detected. As a sibling commenter said, most teams would try to deploy a previous known-good build asset. But I stand by my point that a DoS of a development system can indeed be critical! I’m surprised to find that I appear to be in the minority here...
  - smsm42 5y ago
    I think you're confusing scenarios here. If you have known-good build, then there's no way it is compromised by regexp DOS attack - because that's the build that happened before the attack. So if you build that - setting aside the wisdom on doing that on a compromised system - the regexp DoS is not relevant. If you are building the modified code then one should definitely question why would you want to do something like that - build and deploy known compromised code. That seems to be the root of your confusion - it's not that development system DoS is not bad, it's that if you are at the point it's possible your security is already broken in much bigger way. It's like complaining that running "rm -rf /" under root would wipe all your files and that's a DoS - without taking into account that if somebody could run commands under root on your system it's not your system anymore. It's not that wiping all the files isn't bad - it's that the reason for why the situation is bad is much earlier that that.

askmike 5y ago

> Your source code is somehow compromised and attackers slip in rogue code to your production site. Really at this point it's too late to do anything else, instead of trying to dos your dev machine he can instead do simpler things like delete your ssh key from the machine. But let's play along: > The attackers also take advantage of several of these RegEx DoS vulnerabilities to prevent you from quickly fixing the problem. When you discover the issue, you’ll first see that your build machine is unresponsive There is nothing any attacker can do with the static files on the server that will trigger and RegEx DoS in your local development. Aside from the fact that you wouldn't download whatever is on the server back to your machine, even if you did it would never trigger such a DoS since (in the examples in the link) these are modules related to running a dev version of a frontend project based on the raw source files. Your scenario is only true when an attacker pwned both your production server and your laptop. A regex DoS is really the last thing you worry about at that stage.

trunnell 5y ago
I see your point that even worse things can happen when dev machines are compromised. The point I tried to make is that even a DoS of your machine can be a big problem. > There is nothing any attacker can do with the static files on the server that will trigger a RegEx DoS... IIUC, an attacker could change my package.json to include inputs to browserlist that trigger a RegEx DoS. To do that, the attacker only needs to make a fraudulent commit. Given how easy most teams make it to commit code, this isn’t too high of a bar.
- nirvdrum 5y ago
  If you, as an attacker, are going to make a fraudulent commit and change package.json, you could just pull in a bogus dependency or add a new script/command that gets run on the build/dev machine. I agree the bar to submitting a fraudulent commit is unfortunately too low for many teams. But, this also extends to package publishing, too. We've seen packages published through compromised dev keys or the maintainer granted a new bad actor rights to publish. Here we could envision a situation where someone reports a legitimate, but low impact, security issue and also publishes a bogus package that everyone is now upgrading to. On the whole, these messages aren't encouraging people to upgrade to a new, verified release (i.e., a fixed version). They're encouraging people to upgrade to the latest release. Even if you suspend the bad actor thought experiment, the latest release of a package in all likelihood hasn't been audited beyond ensuring the previously reported security issue has been addressed. Upgrading indiscriminately is a risky activity as well. I don't think we should be encouraging people to do that (in any language ecosystem). It's not lack of imagination of attack vectors at play here. Treating extremely low risk factors as if they're high priority reduces trust in the system as a whole. Getting developers to care more about security is a laudable effort, but I think the `npm audit` approach (as reported in the post) is going to encourage bad practices.
  - trunnell 5y ago
    I agree with all of your points except for the very last one. Are we shooting the messenger (npm audit) here? Seems like the problem is lack of trust and lack of information about security of dependencies. Npm audit is just pointing that out. The size of the problem makes it very uncomfortable.

dj_mc_merlin 5y ago

1. You wouldn't wait for a full build in that scenario, but deploy a known-good last image or emergency shut down. 2. If you are doing a full build and fail because of the regex DOS, then that build would also contain the attacker injected siphoning code, which would make your entire exercise futile in the first place 3. Not obviously messing with the network or crashing build machines would be a better way of siphoning data for longer. 4. This is very contrived.

smsm42 5y ago

I think if the attacker got as far as deploy their code in your CI/CD pipeline and prod system, there's no "quickly" fixing it. There's a full shut down, restoring from trusted backup, full data and code audit and a lot of pain in the future validating and restoring the code and the data. Quick rebuild is not something that would be your priority there - how do you know this quick build won't be compromised anyway? If somebody got into your internal systems on the level they could modify the code, it's not a 1 minute problem and not a 5 hours problem, it's much bigger...

trunnell 5y ago
I think the typical scenario is that you understand how big of problem it is only in retrospect. In the moment, your first thought is that there is some type of quick fix that will restore functionality (if your site is down) or evict the intruder if something funny is detected. As a sibling commenter said, most teams would try to deploy a previous known-good build asset. But I stand by my point that a DoS of a development system can indeed be critical! I’m surprised to find that I appear to be in the minority here...
- smsm42 5y ago
  I think you're confusing scenarios here. If you have known-good build, then there's no way it is compromised by regexp DOS attack - because that's the build that happened before the attack. So if you build that - setting aside the wisdom on doing that on a compromised system - the regexp DoS is not relevant. If you are building the modified code then one should definitely question why would you want to do something like that - build and deploy known compromised code. That seems to be the root of your confusion - it's not that development system DoS is not bad, it's that if you are at the point it's possible your security is already broken in much bigger way. It's like complaining that running "rm -rf /" under root would wipe all your files and that's a DoS - without taking into account that if somebody could run commands under root on your system it's not your system anymore. It's not that wiping all the files isn't bad - it's that the reason for why the situation is bad is much earlier that that.