-
-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
This package appears to have a TOCTOU bug #14
Comments
@isaacs can you clarify? This will help us in updating npm package in debian. cacache depends on this module. |
see #3 (comment) |
The Patch welcome to address this. However, I suspect that any recursive file modification in Node that intends to not follow symbolic links will suffer from this sort of loophole. The |
Mmmh turns out that When I tried on debian sid with nodejs v8.9.3 I got:
so it seems my proposed fix is not viable ATM. Apart from that, it would be cool to have @jepler at least review it by inspection ! |
I agree, with the primitives provided in node |
Fine then I propose that we escalate this to the nodejs issue tracker. As it stands now the nodejs platform makes it impossible for module devs to protect users against time of check to time of use bugs. |
libuv 1.2.1 now has lchown |
The snyk.io vulnerability testing tool has started to report this issue for any package that depends on |
Chownr has a recently reported issue to snyk, though the issue itself has been known for over a year. isaacs/chownr#14 This issue has been introduced via sharp via tar and tar-fs npm packages We'll continue to follow this issue on the chownr repo. And I've added a comment to the issue thread. isaacs/chownr#14 (comment)
@simevo any news on the status of your patch? |
I'm also interested in this, the package is so popular that NPM itself depends on it. |
fixes the symlinks problem isaacs#3 while not causing the TOCTOU vulnerability isaacs#14 The [patch in libuv 1.21.0](https://github.com/libuv/libuv/releases/tag/v1.21.0) that undeprecates `fs.lchown` [has been incorporated in nodejs Version 10.6.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V10.md#2018-07-04-version-1060-current-targos). So I specified the minimum nodejs version in `package.json` with the `engine` key: https://docs.npmjs.com/files/package.json#engines
What is the status on this? |
see my open PR #15 which requires nodejs > 10.6 |
Looking forward to a patch on the vulnerability |
Hope the patch will appear soon |
We develop software used by enterprises. This issue is a potential showstopper for us from using this module or modules that leverage this component, e.g. pm2. I appreciate @simevo's efforts and would love to see the project maintainers give some priority to getting a patch for this. |
The silence around a year-plus old security issue is pretty disappointing and @simevo's work is greatly appreciated — major kudos for getting lchown into libuv. But dropping compatibility with Node versions prior to 10.6 is not exactly a small undertaking or even feasible in some cases. Admittedly it's not far away, but 10.x is not even in Active LTS yet and neither 8.x or even 6.x have reached End-of-life. Even if the patch was merged today, such a breaking compatibility change would necessitate a major semver bump. That isn’t going to magically propagate its way up the dependency chain. And each package maintainer then has to be willing to upgrade and break their compatibility. That’s six major, backwards-incompatible releases to get a patched chownr into pm2. Maybe a better option in the short term would be to decide at runtime to use |
Thanks for the kudos, I'd like to send a fair share of those to the fellow debian people @jepler, @hacksk and @pravi who discovered this and reported it here. This is a good example of fruitful collaboration between the nodejs and debian opensource ecosystems, notwithstanding the differing approaches to module/package dependencies. Now back to the point, nodejs 6.x has End-of-Life 2019-04, and 8.x has EoL 2019-12; does it make sense to backport the libuv 1.2.1 fixes on top of 1.16.1 for 6.x and on top of 1.19.2 for 8.x ? |
I just published 1.1.0, which uses lchown when available, and also reduces the stat calls on node v10.10.0, where stat data can be included in the readdir call. However, as there is no The basic flow would be:
Unless Node.js gains the ability to call My advice is to not run chownr on untrusted systems. For the vast majority of cases, this isn't a problem, since it requires an attacker having access to the filesystem where the user script is running chown, and in that case, this TOCTOU is the least of your worries. |
Hello from 2019!! I've got the TOCTOU security alert from Snyk with the following packages chain: As the "chownr" isn't used directly here. What is the typical action plan in this case except temporary muting the alert with |
@webdevbyjoss use nodejs >= 10.10 and chownr >= 1.1.0 as per #14 (comment) |
@pravi I am still getting the TOCTOU Snyk alert with nodejs >= 10.10 and chownr >= 1.1.0
The vulnerability still appears to be in |
@dr3 you should report it to Snyk. |
As I mentioned on 2018-09-15, there is no That being the case there will always be a TOCTOU issue for any recursive filesystem operation that traverses directories making changes at each level. No exceptions. The same TOCTOU issue exists for The additional TOCTOU issue (using Since this particular remaining TOCTOU issue is inherent in any recursive filesystem mutation, and this is a module designed specifically to do a specific recursive filesystem mutation, I'd say you're as safe as you can be. It's not a problem with this module, but inherent in the operation. If you wrote it yourself, you'd have the same problem. If it's an issue in your situation, then don't use chownr, and instead call I'd suggest that anyone sent to this issue via snyk please report this to them, or ask them to contact me if they'd like more information. I'm not a customer of theirs, so I don't want to bother their support folks with this issue myself. |
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863985#10
The text was updated successfully, but these errors were encountered: