-
-
Notifications
You must be signed in to change notification settings - Fork 184
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
Consider a new v2 release addressing the npm audit issues #212
Comments
node-gyp is using node-tar@2, not node-tar@3 though. So what is needed would be a new v2 release. |
Apologies I misread
…On Tue., 23 Apr. 2019, 11:35 pm Christophe Coevoet, < ***@***.***> wrote:
node-gyp is using ***@***.***, not ***@***.*** though. So what is needed
would be a new v2 release.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#212 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAENSWBZC2A4OES4E5NDAC3PR4GBBANCNFSM4HHX2TTQ>
.
|
There are a lot of libs chain-depending on + [email protected]
added 426 packages from 800 contributors and audited 12096 packages in 5.679s
found 4 high severity vulnerabilities
run `npm audit fix` to fix them, or `npm audit` for details That's essentially a false positive, because anyone in position to exploit node-tar in that dependency chain is most likely also in position to just ship malicious code.
So, unless a fixed node-tar version is released in 2.x branch, downstream (including npm, npm-lifecycle etc) would have to do a major version bum for Another possible way forward would be to migrate node-gyp@3 off node-tar usage completely, but that is not the ideal solution. |
I would gladly accept a PR against the v2 branch to address this. But I'm not really interested in doing work to support node versions long past their LTS expirations. The library has been completely rewritten since then, so it's not a simple backport. If anyone wants to take this on, I'll be happy to answer any questions and publish it once it lands, but I haven't even looked at that version of the codebase for 2 years now. |
@isaacs Thanks for the fast reply! (Also, for the willingness to accept a patch and cut a release).
I believe that that's not the point, the point is that
|
See e.g. npm/npm-lifecycle#28 |
I've been digging into the v2 code this morning, and I'm not sure v2 is actually vulnerable to this attack. In v2, when an extract encounters a link, it runs this code (lines 46-49 in if (entry.type === "Link") {
entry.linkpath = entry.props.linkpath =
path.join(opts.path, path.join("/", entry.props.linkpath))
} And a comment above this code explains the reasoning behind this:
However, I believe this results in a buggy implementation of tar extraction. Here's an example: I have a sample tar,
So the tar simply consists of two files: Using the v2 node-tar branch locally, I ran the following script: var tar = require('./tar');
var fs = require('fs');
var extract = tar.Extract('extracted');
fs.createReadStream('archive.tar').pipe(extract); And got the following error:
I believe the root cause of this issue is that the So, from what I can tell, tar extraction with hard links in v2 is buggy, but it isn't actually vulnerable to this attack. Side note: if you comment out the if statement included above, the attack does work. EDIT: I did some digging through the v2.x.x tags, and all of them have the above if statement in |
/cc @vdeturckheim, perhaps, re: 2.x being affected or not Upd: It looks like 2.x still overwrites files inside the dest dir. That's not what patched 4.x does. Thoughts? |
After more experimenting I can also confirm that 2.x.x can still overwrite files inside the destination directory. However, I don't think it's possible to overwrite files outside of the destination directory because of the inner path.join("/", entry.props.linkpath) The result of the above
And this path can't have any path.join('target', '/some/path/here') And this will always result in a path inside the target directory because the second argument can't have any |
Opened #213 with a potential solution to this vulnerability. |
Can we get this looked at sooner than later please? |
Ok, there's a v2.2.2 which no longer has this vulnerability, and includes a test to verify. Fixed on this commit in fstream: npm/fstream@6a77d2f which is published on [email protected] Let's get this tested in node-gyp, update the advisory, and put this to bed. |
npm advisory will be updated tomorrow morning, and then (I swear to god if someone comes out of the woodwork demanding this be backported to tar@v1, I'm gonna have to be rushed to the hospital, this code is so old and so gnarly. The tests don't even run properly on any version of node newer than v4.) |
Thank you |
Revert the tar resolution because the vulnerability is patched in node-tar. isaacs/node-tar#212
Fixes sass/node-sass#2625 |
The advisory has been updated as of this morning. |
Will this also be updated automatically? https://nvd.nist.gov/vuln/detail/CVE-2018-20834 |
Hi @isaacs , I just tried this, and it still doesn't fix my problems doing npm audit fix. I had tar version 4.4.8, but i also tried downgrading it to 4.4.2; Please can you help? |
Got it resolved! sorry guys... i had a node-gyp dependency for npm-lifecycle, once I resolved, the manual review on fstream dependencies could be fixed quickly! It works now! :) 👍 |
I have a alias for that which comes in handy :P
alias npm_nuke='rm -rf node_modules package-lock.json && npm i'
…On Thu, May 16, 2019, 4:54 AM Braian Silva ***@***.***> wrote:
The new version of tar has been released.
isaacs/node-tar#212 (comment)
<#212 (comment)>
Delete the folder node_modules and package-lock.json, then execute the
commands:
1. npm install
2. npm audit
3. npm audit fix
4. npm audit
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#212>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEW4K3IKMVQQME3LGM42RH3PVSLRZANCNFSM4HHX2TTQ>
.
|
I contacted NIST directly about 2.2.2 not having the vulnerability, and got the following response:
So stay tuned, because soon 2.2.2 will be recognized as an acceptable, non-vulnerable version, and appropriate versions of dependent packages like node-gyp will no longer be flagged as vulnerable. |
ihttps://github.com/isaacs/node-tar/issues/212#issuecomment-492463507
There's a new version, but it seems to be uninstallable. If you:
You'll get errors about tar and fstream being out of date.
So it should be getting 2.2.2. The complete dependency tree for tar is:
So, with great irony, npm appears to indirectly be part of the problem why I'm getting an old version of tar. -_- The only way to get 2.2.2 seems to be to manually edit my package-lock.json file. |
It is installable, except npm is using |
I can't do the issue justice. See nodejs/node-gyp#1718
tl:dr; npm audit is unhappy with node-tar@^2 because of https://hackerone.com/reports/344595. Since node-tar@^2 is used in node-gyp the npm audit alert is rippling throughout the Node community. Bumping to node-tar@^4 breaks Node 0.10 & 0.12 support which starting up the typical semver debates, and may force a lot of projects to subsequently bump their majors, and so on an do fourth.
Edit: node-tar@^2 not @^3
The text was updated successfully, but these errors were encountered: