Recent searches
Search options
There is something that have been bothering me for past few months, and resulted in me archiving node-ip repo on github: https://github.com/advisories/GHSA-78xj-cgh5-2h22
Someone filed a dubious CVE about my npm package, and then I started getting messages from all people getting warnings from `npm audit`.
I just posted a comment on the advisory issue https://github.com/github/advisory-database/pull/3504#issuecomment-2189530624 asking to remove it, but looking at dicer's advisory https://github.com/advisories/GHSA-wm7h-9275-46v2 I see that there might be a larger pattern in place?
/1
It looks like there are entities that in theory should fill the void in OSS community and provide resources for managing security reports for overloaded maintainers. (I'm looking at you SNYK)
However, the verification process of vulnerability reports doesn't involve maintainer at all, and it sounds like the commercial interest of advisory repositories is aligned with creating more vulnerabilities and proving themselves “useful" to companies that utilize them.
/2
For that dicer bug in particular, I don't think it is reproducible as described in the advisory's PoC: https://gist.github.com/indutny-signal/9602403f5b0a946d139398e9bad8222c
Furthermore the PoC doesn't seem to involve dicer at all: https://security.snyk.io/vuln/SNYK-JS-DICER-2311764
What's funny is that I found no way to dispute the advisory on SNYK. The closest thing that I found was to write a message to support, but I'm not entirely sure whether this results in a vulnerability takedown...
/fin
Update:
GitHub got back to me and decided to lower the vulnerability rating in response to my feedback. Furthermore, they advised me to enable Private Vulnerability Reporting feature so that I could get a chance at tackling the reports before they hit all package users next time. Great response!
SNYK still didn't get back to me, though, and I have no idea if another feedback channel exists.
@indutny you should see how synk's "security researchers" act in email...
@indutny so does that mean you'd be unarchiving the node-ip repo or? I'm guessing it still needs the private vulnerability reporting enabled?
@thisismissem yeah, I plan to unarchive it when I get to computer this evening
@indutny amazing, thanks!
@indutny if you want, I could help dispute and hopefully revoke the CVE
it's bogus that maintainers need to do this labor
@eslerm this would be awesome. Thank you so much!
@indutny great, I'll send an email
I'm on vacation this week, but can get the ball rolling over the weekend
@indutny I agree the rating was completely overblown, but I don't understand why you don't consider this a vulnerability?
As mentioned in the bulletin: determining public vs private IPs can be fairly important when preventing server side forgery (SSRF) attacks.
Obfuscating the IP using various methods (see https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery) is a popular technique to evade filtering and accomplish SSRF. An excellent talk (based around URL parsing but similar idea) is https://www.youtube.com/watch?v=voTHFdL9S2k
@mikesiegel maybe I don't understand it fully, but where would you get the unnormalized or badly formatted IP address from? If the attacker can influence it, can you trust the attacker to not use 127.0.0.1 in the first place?
My original point was that if you get this address from kernel (as you should) or DNS, it will always be normalized and node-ip should be able to handle it without issues.
@indutny The scenario I'm imaging is: you're using cloud-based synthetic monitoring software. New Relic, Pingdom, Dynatrace. They ask you put in an IP address and port, their monitoring servers will reach out to test your monitored server every 15 minutes and return the result of an HTTP GET. What they really don't want to do is reach back into their own network, retrieve an HTTP GET on something not exposed publicly and share it with an end-user. So to make sure this doesn't happen, they do some sort of isPublic() check and tell you pound sand if it's private. Here are some additional examples from H1: https://github.com/reddelexc/hackerone-reports/blob/master/tops_by_bug_type/TOPSSRF.md
@mikesiegel hm… yeah, this does sound like a situation where security guarantees of node-ip would be important.
That being said, the use case seems to be off the common path so the mitigation might be just to say that the library is not intended to be used for security purposes.
@indutny a more common example would be upload from URL (picture, document), but actually exploiting those tends to be pretty convoluted. I've also seen it on sites where you can configure your own webhook. It's hard problem to solve though, because between DNS and weird IP address stuff (like 2130706433 = 127.0.0.1) it's a challenge.