Sitting comfortably? Then it's probably time to patch, as critical flaw uncovered in npm's netmask package
- Reference: 1617042427
- News link: https://www.theregister.co.uk/2021/03/29/netmask_cve/
- Source link:
Researchers Victor Viale, Sick Codes, Kelly Kaoudis, John Jackson, and Nick Sahler have [1]disclosed a digital nasty, tracked as CVE-2021-28918, in the hugely widespread netmask npm package.
[2]
It's a handy bit of code used for parsing and comparing IP addresses, and the flaw lies in how it handles mixed-format IP addresses. Namely, what it does when there is a leading zero.
As an example, the IPv4 address 127.0.0.1 is localhost . However, pop 0127.0.0.1 into a browser and that 0127 gets treated as octal and changed to its decimal equivalent, which is 87. Thus 0127.0.0.1 is actually 87.0.0.1.
[3]
Unless one is using netmask, in which case the leading zero is simply stripped off and 0127 becomes 127, an address that, via netmask, looks like a private IP could be submitted, but is actually a public address (along with all the nefarious activity that might entail).
"Even worse, it goes the other way too!" exclaimed the researchers. Enter 0177.0.0.1 and, while a browser would treat it as an address in the 127 loopback range, netmask would again lose that leading zero and treat it as 177.0.0.1; a public rather than private address.
Trail of Bits security peeps emit tool to weaponize Python's insecure pickle files to hopefully now get everyone's attention [4]READ MORE
"For almost a decade," the researchers went on, "netmask has been incorrectly reading octal input data as a string; just stripping the 0 at the front and using the rest of the data as legitimate."
As for the vulnerability of those hundreds of thousands of projects, it depends on how netmask is being used.
The researchers estimated that the package is used in more than 278,000 projects and accounts for millions of downloads per week - although, to be fair, an awful lot of those will have been down to automated DevOps pipelines rather than actual humans clicking a button.
The node-netmask maintainer, Olivier Poitrey, was given kudos by the team for being "super responsive". The first patch arrived mere days after the 17 March notification date.
Affected users, and there are likely to be a lot, should upgrade to version 2.0.0 of the library.
The incident is a reminder that blithely relying on popular components is no guarantee that one will be immune from vulnerabilities.
Ax Sharma, security researcher at Sonatype, said such users "may not realise that they could be potentially vulnerable to anti-Server-Side Request Forgery (SSRF) bypasses or remote file inclusion (RFI) should they be purely relying on netmask for parsing IP addresses, without adding their own proper input sanitisation and normalisation checks.
"This highlights the need for proper input hygiene and never trusting input no matter the source. In this case, for example, the fixes... applied to netmask now take into account that IP addresses can also be provided in octal or hexadecimal formats, something users of netmask could also have implemented on their end as an extra precaution."
[5]
As the saying goes: Trust No One. ®
Get our [6]Tech Resources
[1] https://sick.codes/universal-netmask-npm-package-used-by-270000-projects-vulnerable-to-octal-input-data-server-side-request-forgery-remote-file-inclusion-local-file-inclusion-and-more-cve-2021-28918/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YGJN-oNk3P5ZbBNGknv8ogAAAA4&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YGJN-oNk3P5ZbBNGknv8ogAAAA4&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://www.theregister.com/2021/03/19/python_pickle_format_weaponized/
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YGJN-oNk3P5ZbBNGknv8ogAAAA4&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://whitepapers.theregister.com/
Re: Not NPM again!
It has nothing to do with NPM. it's a package with a problem. Do you really think that third party Go packages has less issues?
Why were people dragging in an external dependency (npm package) for some trivial crap like that?
What a shite culture so many of these javascript communities have. These language based package managers (NPM, PIP, crates.io, CPAN, etc) seem to breed incompetence.
Developers should be responsible and of course depend on a library but *only* if it will save days of work. If it is only because you are too lazy to type 10 lines then you basically need to improve your work ethic.
Yeah, because people aren't much more likely to make an error like that themselves... Now all those that DOES use netmask doesn't have that issue anymore(if they actually update their packages), but many of those that doesn't will not be protected.
The only real factor here is how quickly the package maintainers respond. And in this case it was quickly.
100% of the people had that issue. If they had implemented it themselves, perhaps 10% would have had that issue.
Also, do you expect large projects to just do an 'npm update' and push to production? Hah, no, this problem is now known and yet will still reside on ~30% of production servers for another year.
An important ~10 lines of code well saved ;)
You can bet your ass that most do simple string parsing, and has exactly the same issue.
To be honest, in large projects you'll probably want to use standard libraries as much as you can, because a lot of homegrown stuff will sooner or later reach the "nobody present knows how it works, nobody dares touch it" sort of maintenance category. Or legacy. Bottom line is, a lot of broken and insecure code will stick around once the developers left, whereas standard libraries usually have a lifetime beyond the contractor's or FTE's term.
Sure, crap happens either way, and it's not uncommon to benefit from the power of hindsight and point fingers then.
There's no 100% secure and bugfree software beyond "hello world". Personally I'd go with something that will (or is most likely to) receive future updates.
Parsing things is often less trivial than you would hope. If you wrote your ten-line parser off the top of your head, would it parse “192.168.510” correctly? Is it a good use of your time, and thousands of other developers’ time, to find, read, and implement the same specification correctly? What are the consequences if there are hundreds of differently half-baked implementations in the wild? I’m not suggesting that parsing IP addresses is hard but there is a reason libraries exist.
This isn't a comment on the package or npm, but using a leading 0 to indicate a number is octal seems like a really bad idea.
While that may be true, it is also very standard across a lot of (most?) programming languages.
Not NPM again!
Wasn't it NPM that also had a problem a year or two back? Some core package maker got told to take a package down that did some string manipulatrion, they took it down and it killed thousands of project builds all over the world. 6 hours later the main NPM repo owners had reinstate the iffy package simply 'cos it caused so much chaos not being present when builds were pulling it.
Never a huge fan of JS nor it's bastard offspring Node, think I'll stick with Go thanks!