4 ms·

Some people will use this to argue against dependencies or npm, but I would argue that this vulnerability is actually a great example of why those are good thin

by lucumo 6y ago

Some people will use this to argue against dependencies or npm, but I would argue that this vulnerability is actually a great example of why those are good things. The bug is caused by an esoteric IP address notation. Nearly everyone who would need this functionality would get the implementation wrong. In the exact same way the author of netmask did. However, netmask is now fixed and this bug will now no longer appear in any new implementation. Even better: npm will start to give warnings about this vulnerable package and will provide a fix through npm audit. Everything that is maintained in a reasonable way, will now no longer have this vulnerability. This is not a failure of dependencies or npm: this is an example why those are good things.

selykg 6y ago
Pros and cons. Everything has them. I think the really big issue with all these package management solutions is how deep the dependency requirements go. One package depends on another package that depends on 18 other packages, that depend on 30 other packages, and it's packages all the way down. No one is going to review all of those packages regularly. It's just not going to happen. Sure, it's less a problem for the big popular packages, but those big popular packages still depend on a lot of smaller packages and those smaller packages are extremely vulnerable due to sheer lack of eyes on it. Everyone always says "I won't use software that isn't open source because the code is in the open and vulnerabilities can be found" but the fact of the matter is someone has to be reviewing that code to find them. I'd love to better understand how many people are out there reviewing code as part of their process. I'll be it's a lot less than anyone would like.
- mason55 6y ago
  The alternative is to develop the entire stack in house. Unlikely that you’ll do any better and meanwhile your competitors will pass you by. It’s really just the consequence of asymmetrical outcomes. Most of the time it all just works and so if you don’t keep up you’re out of business. When something goes wrong the whole world is exposed. I guess with npm you do have the additional wrinkle that much of it is outside the std lib which increases risk a bit.
  - umvi 6y ago
    > The alternative is to develop the entire stack in house Maybe now because everyone is entrenched, but the alternative could have been to offer a robust "standard library" in the first place that lets you cover 90% of developer's use cases without needing external packages. See: Java, C/C++, Go, Python... Only JavaScript seems to be a special snowflake where doing even the most basic tasks requires downloading 50 packages.
    - Karunamon 6y ago
      I'm not super familiar with the JS ecosystem, but isn't Node unique in that it tends to have packages for things that arguably have no business being their own dependencies? leftpad comes to mind.
    - pdpi 6y ago
      For all the reasons you might criticise JavaScript, that’s one of the least reasonable. Python is specifically known as a “batteries included” language, and Go has stdlib support for the core use cases the language is designed for. I wouldn’t say that C++ or Java have particularly rich standard libraries outside of IO and common data structures, and C is downright anaemic.
      - dtech 6y ago
        JVM/Java has an extensive stdlib, including a decent DNS/IP resolution library that this package contains a vulnerability in. It also has one of the best date/time libraries I've ever seen, while that it external in nearly all languages for example.
      - jjav 6y ago
        > I wouldn’t say that C++ or Java have particularly rich standard libraries The Java standard library is about as rich as it gets. I rarely ever have had to use external dependencies when working on Java projects.
    - nemothekid 6y ago
      In your examples, only Java and Go have robust standard libraries and both are essentially corporate programming languages. The claim that C has a safe and/or robust standard library is very bizarre. Python only got there after years of community development (Python is 30 years old, Node is 11), and even today I wouldn't consider it particularly high quality.
deleted 6y ago
[deleted]
enriquto 6y ago
Not sure if you are being sarcastic, but anyway I laughed out loud at your message. Thanks!
swiley 6y ago
Even libc with everything it lacks has IP address parsers, this is a great example of how node.js is flawed.
- cies 6y ago
  You're saying some functionality not being part of Node's std lib is "a great example" of the whole of Node being flawed. You must have a lot more "great examples" up your sleeve!
- tyingq 6y ago
  Well, technically it parsed right. /sbin/ping will similarly parse odd notation. To me the issue was with ancillary functions like isPrivateIp() using the unparsed ip text.
simion314 6y ago
Packaging is fine for security as we see with maintained Linux distribution, the problem people have with NPM community is that you get a spider web of packages because instead of a big high quality standard library you have to use some random guys npm package or copy and paste some code from Stack Overflow. The solution would be that Google,Mozilla,Microsoft and Apple would do something productive for once and create such an (optional) standard library and good tools that would know to only build the used stuff in the final thing.
dmos62 6y ago
I agree with your point. I never saw a problem with dependencies until I worked on a system where security and reliability were very high priorities. Apparently, on a system like that you only use the official language libraries, a very very minimal set of auxiliary libraries (e.g. Google's Guava), and everything else you code up yourself, because you can't include anything your team can't audit. You could audit a third-party library, but extracting or writing just the parts you need and then auditing that is always less work. That way you're sort of in a world without a wider eco-system.
mschuster91 6y ago
> The bug is caused by an esoteric IP address notation Fun fact: there are even more IP address notations... try ping'ing 0x7F000001 or 2130706433, for example - on OS X commandline and Google Chrome at least, these resolve to localhost.

by lucumo 6y ago

selykg 6y ago

Pros and cons. Everything has them. I think the really big issue with all these package management solutions is how deep the dependency requirements go. One package depends on another package that depends on 18 other packages, that depend on 30 other packages, and it's packages all the way down. No one is going to review all of those packages regularly. It's just not going to happen. Sure, it's less a problem for the big popular packages, but those big popular packages still depend on a lot of smaller packages and those smaller packages are extremely vulnerable due to sheer lack of eyes on it. Everyone always says "I won't use software that isn't open source because the code is in the open and vulnerabilities can be found" but the fact of the matter is someone has to be reviewing that code to find them. I'd love to better understand how many people are out there reviewing code as part of their process. I'll be it's a lot less than anyone would like.

mason55 6y ago
The alternative is to develop the entire stack in house. Unlikely that you’ll do any better and meanwhile your competitors will pass you by. It’s really just the consequence of asymmetrical outcomes. Most of the time it all just works and so if you don’t keep up you’re out of business. When something goes wrong the whole world is exposed. I guess with npm you do have the additional wrinkle that much of it is outside the std lib which increases risk a bit.
- umvi 6y ago
  > The alternative is to develop the entire stack in house Maybe now because everyone is entrenched, but the alternative could have been to offer a robust "standard library" in the first place that lets you cover 90% of developer's use cases without needing external packages. See: Java, C/C++, Go, Python... Only JavaScript seems to be a special snowflake where doing even the most basic tasks requires downloading 50 packages.
  - Karunamon 6y ago
    I'm not super familiar with the JS ecosystem, but isn't Node unique in that it tends to have packages for things that arguably have no business being their own dependencies? leftpad comes to mind.
  - pdpi 6y ago
    For all the reasons you might criticise JavaScript, that’s one of the least reasonable. Python is specifically known as a “batteries included” language, and Go has stdlib support for the core use cases the language is designed for. I wouldn’t say that C++ or Java have particularly rich standard libraries outside of IO and common data structures, and C is downright anaemic.
    - dtech 6y ago
      JVM/Java has an extensive stdlib, including a decent DNS/IP resolution library that this package contains a vulnerability in. It also has one of the best date/time libraries I've ever seen, while that it external in nearly all languages for example.
    - jjav 6y ago
      > I wouldn’t say that C++ or Java have particularly rich standard libraries The Java standard library is about as rich as it gets. I rarely ever have had to use external dependencies when working on Java projects.
  - nemothekid 6y ago
    In your examples, only Java and Go have robust standard libraries and both are essentially corporate programming languages. The claim that C has a safe and/or robust standard library is very bizarre. Python only got there after years of community development (Python is 30 years old, Node is 11), and even today I wouldn't consider it particularly high quality.

deleted 6y ago

[deleted]

enriquto 6y ago

Not sure if you are being sarcastic, but anyway I laughed out loud at your message. Thanks!

swiley 6y ago

Even libc with everything it lacks has IP address parsers, this is a great example of how node.js is flawed.

cies 6y ago
You're saying some functionality not being part of Node's std lib is "a great example" of the whole of Node being flawed. You must have a lot more "great examples" up your sleeve!
tyingq 6y ago
Well, technically it parsed right. /sbin/ping will similarly parse odd notation. To me the issue was with ancillary functions like isPrivateIp() using the unparsed ip text.

simion314 6y ago

Packaging is fine for security as we see with maintained Linux distribution, the problem people have with NPM community is that you get a spider web of packages because instead of a big high quality standard library you have to use some random guys npm package or copy and paste some code from Stack Overflow. The solution would be that Google,Mozilla,Microsoft and Apple would do something productive for once and create such an (optional) standard library and good tools that would know to only build the used stuff in the final thing.

dmos62 6y ago

I agree with your point. I never saw a problem with dependencies until I worked on a system where security and reliability were very high priorities. Apparently, on a system like that you only use the official language libraries, a very very minimal set of auxiliary libraries (e.g. Google's Guava), and everything else you code up yourself, because you can't include anything your team can't audit. You could audit a third-party library, but extracting or writing just the parts you need and then auditing that is always less work. That way you're sort of in a world without a wider eco-system.

mschuster91 6y ago

> The bug is caused by an esoteric IP address notation Fun fact: there are even more IP address notations... try ping'ing 0x7F000001 or 2130706433, for example - on OS X commandline and Google Chrome at least, these resolve to localhost.