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
@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.