predictable tmpfile names may lead to potential security issue #3635
Comments
|
Doesn't sound unreasonable but I'm not sure if this is something that will be changed / changed anytime soon. |
|
First, yes, if you are running code on a machine that also has malicious users that can look in the process table, you're already pretty well fucked in many ways. But, sure, defense in depth. The ideal solution here, for many reasons beyond this issue, is to not use tmp files at all. There's no good reason for them, they're just a relic from workarounds that are no longer necessary. But, the change is a massive rewrite, that I haven't been able to get to yet. A temporary immediate workaround is to set npm's A less immediate workaround is f4d3169. |
|
Please use CVE-2013-4116 for this issue. |
|
@fgeek not sure if that's meant for us or if it's part of something automated, but we don't generally post updates/issues to other bug trackers :) |
|
@kapouer @fgeek Does this fix satisfy the issue? @codevi writes:
It seems like that will always be an issue, as long as npm uses tmp files at all. Short of using random names for every single file underneath the However, once the folder is created, it seems like less of an issue. After all, the problem is that an attacker can create the symlink after the npm process is started, but before it tries to create its tmp file, and thus trick npm into writing to the wrong place. The folder itself is user-owned and only user-writable, and the level underneath it is completely randomized, so I'm not convinced this is still an issue (or really, even ever was). I'd like to see an actual exploit before adding any more complexity to this. The plan is to eventually do away with tmp file usage completely, so doing more work on it seems foolish. |
|
@fgeek ah neat, we don't really use that stuff, but feel free to update it with the rhel people or whatever you need to do if you're involved with them :) |
|
@st-luke Already done. For example in Debian bug tracking system https://security-tracker.debian.org/tracker/CVE-2013-4116 all security vulnerabilities should have CVE (and even some security hardening issues). I can request those for you if you lack the time or something like that. |
|
Nah, don't worry about it. We don't need them :) On Monday, July 15, 2013, Henri Salo wrote:
|
|
@luk- It's not only that you need them for security advisories/release notes, but it is very important for users of your software. CVE makes it easier to coordinate security vulnerabilities. Now that this vulnerability has CVE identifier we can use it e.g. in Debian to discuss and address same vulnerability and for example share the patch with Ubuntu or other distros. I hope I explained it correctly :) I'm also happy to help if there is need for CVE identifiers. |
|
You could also verify content after extraction and if it fails then reject it. |
Forwarding this potential security issue about npm :
On 08/07/2013 14:23, Daniel Kahn Gillmor wrote:
what we're talking about is a classic symlink attack. I haven't tried
to verify it with npm myself, but using predictable tmpfile names in
world-writable directories is the usual gateway to a vulnerability here.
The text was updated successfully, but these errors were encountered: