This package appears to have a TOCTOU bug

[hacksk]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863985#10

[pravi]

@isaacs can you clarify? This will help us in updating npm package in debian. cacache depends on this module.

[simevo]

see #3 (comment)

[isaacs]

The *at methods suggested in the Debian bug report are not exposed in Node.js, so that's not a solution.

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 lstat is a best effort attempt to avoid following symbolic links, but yes, a well-timed file system update can cause it to perform in unexpected ways.

[simevo]

Mmmh turns out that fs.lchown is deprecated (why??), besides it is not available at all on linux !

When I tried on debian sid with nodejs v8.9.3 I got:

not ok fs.lchown is not a function

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 !

[jepler]

I agree, with the primitives provided in node fs it doesn't seem to be able to safely do operations like these on systems where an adversarial user can create symlinks within the hierarchy being operated on. Besides which, I failed to find any npm packages which provide the *at family of functions, so there may not even be an alternative you can depend on to help you resolve the problem. I am sorry I don't have any positive suggestions to offer.

[simevo]

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.

[simevo]

libuv 1.2.1 now has lchown
it should be usable from nodejs master and land in 10.x soon
so the patch I proposed could become viable

[spencern]

The snyk.io vulnerability testing tool has started to report this issue for any package that depends on chownr

https://snyk.io/vuln/npm:chownr:20180731

[EightArmCode]

@simevo any news on the status of your patch?

[VPenkov]

I'm also interested in this, the package is so popular that NPM itself depends on it.
Any suggestions how to remove it from vulnerability lists such as Snyk's would be appreciated.

[morkro]

What is the status on this?

[simevo]

see my open PR #15 which requires nodejs > 10.6
CI tests don't pass since original tests are failing too

[joelataylor]

Looking forward to a patch on the vulnerability

[artakvg]

Hope the patch will appear soon

[TimeBomb]

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.

[benwiggins]

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 fs.lchown wherever possible (Node 10.6+ for sure, but maybe also ignore the deprecation on earlier versions when running under MacOS?) but fallback to fs.chown. But I think for all intents and purposes chownr would probably still be considered a vulnerable package by Snyk etc. in that case.

[simevo]

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 ?

[isaacs]

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 readdir that will succeed on actual directories, and fail on symlinks to directories, there is still a problem that I don't see a way to address. So the TOCTOU is smaller, but not gone.

The basic flow would be:

1. Read a directory, get a list of items
2. One of those items is a directory
3. After the initial readdir (or readdir+lstat), but before the directory traversal, an attacker moves the directory aside and replaces it with a symbolic link to some other directory.
4. The script will proceed to change ownership of all items in the symlink target directory.

Unless Node.js gains the ability to call fs.readdir with an option to fail if the directory is a symbolic link, I don't see a way around this. As far as I know, that capacity does not exist in readdir(3), so this is probably not possible.

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.

[webdevbyjoss]

Hello from 2019!! I've got the TOCTOU security alert from Snyk with the following packages chain:
react-fullstory-component@2.1.0 › fsevents@1.2.4 › node-pre-gyp@0.10.3 › tar@4.4.8 › chownr@1.1.1

As the "chownr" isn't used directly here. What is the typical action plan in this case except temporary muting the alert with snyk ignore or get rid of the whole vulnerable dependency chain?

[pravi]

@webdevbyjoss use nodejs >= 10.10 and chownr >= 1.1.0 as per #14 (comment)

[dr3]

@pravi I am still getting the TOCTOU Snyk alert with nodejs >= 10.10 and chownr >= 1.1.0

✗ Medium severity vulnerability found in chownr
  Description: Time of Check Time of Use (TOCTOU)
  Info: https://snyk.io/vuln/npm:chownr:20180731
  Introduced through: speculate@1.7.4, compression-webpack-plugin@2.0.0, razzle@2.4.0, brotli-webpack-plugin@1.0.0
  From: speculate@1.7.4 > tar-fs@1.16.3 > chownr@1.1.1
  From: compression-webpack-plugin@2.0.0 > cacache@11.3.1 > chownr@1.1.1
  From: razzle@2.4.0 > uglifyjs-webpack-plugin@1.2.4 > cacache@10.0.4 > chownr@1.1.1
  and 8 more...

The vulnerability still appears to be in v1.1.1

[pravi]

@dr3 you should report it to Snyk.

[isaacs]

As I mentioned on 2018-09-15, there is no readdir(3) call that will succeed on a "real" directory, but fail on a symbolic link to a directory. What that means is that there is no atomic way to verify that, at the exact time of readding a directory, it's a real directory and not a symlink to somewhere else.

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 chown -r, rm -rf, chmod -r, etc.

The additional TOCTOU issue (using chown instead of lchown) is fixed on v1.1.0, and the second TOCTOU issue (relying on additional lstat calls) has been fixed in v1.1.0 when using Node.js 10.10 or higher. But the final one, "readdir follows symlinks" is unavoidable.

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 fs.lchown yourself.

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.