IPv4 Parsing Flaw In NPM Netmask Could Affect 270,000 Apps (securityledger.com) 74
chicksdaddy shares a report from The Security Ledger: Independent security researchers analyzing the widely used open source component netmask have discovered security vulnerabilities that could leave more than a quarter million open source applications vulnerable to attack, according to a report released Monday, The Security Ledger reports. According to a report by the site Sick Codes, the flaws open applications that rely on netmask to a wide range of malicious attacks including Server Side Request Forgeries (SSRF) and Remote- and Local File Includes (RFI, LFI) that could enable attackers to ferry malicious code into a protected network, or siphon sensitive data out of one. Even worse, the flaws appear to stretch far beyond a single open source module, affecting a wide range of open source development languages, researchers say.
Netmask is a widely used package that allows developers to evaluate whether a IP address attempting to access an application was inside or outside of a given IPv4 range. Based on an IP address submitted to netmask, the module will return true or false about whether or not the submitted IP address is in the defined "block." According to the researcher using the handle "Sick Codes," the researchers discovered that netmask had a big blind spot. Specifically: it evaluates certain IP addresses incorrectly: improperly validating so-called "octal strings" rendering IPv4 addresses that contain certain octal strings as integers. For example, the IP4 address 0177.0.0.1 should be evaluated by netmask as the private IP address 127.0.0.1, as the octal string "0177" translates to the integer "127." However, netmask evaluates it as a public IPv4 address: 177.0.0.1, simply stripping off the leading zero and reading the remaining parts of the octal string as an integer.
The implications for modules that are using the vulnerable version of netmask are serious. According to Sick Codes, remote attackers can use SSRF attacks to upload malicious files from the public Internet without setting off alarms, because applications relying on netmask would treat a properly configured external IP address as an internal address. Similarly, attackers could also disguise remote IP addresses local addresses, enabling remote file inclusion (RFI) attacks that could permit web shells or malicious programs to be placed on target networks. But researchers say much more is to come. The problems identified in netmask are not unique to that module. Researchers have noted previously that textual representation of IPv4 addresses were never standardized, leading to disparities in how different but equivalent versions of IPv4 addresses (for example: octal strings) are rendered and interpreted by different applications and platforms.
Netmask is a widely used package that allows developers to evaluate whether a IP address attempting to access an application was inside or outside of a given IPv4 range. Based on an IP address submitted to netmask, the module will return true or false about whether or not the submitted IP address is in the defined "block." According to the researcher using the handle "Sick Codes," the researchers discovered that netmask had a big blind spot. Specifically: it evaluates certain IP addresses incorrectly: improperly validating so-called "octal strings" rendering IPv4 addresses that contain certain octal strings as integers. For example, the IP4 address 0177.0.0.1 should be evaluated by netmask as the private IP address 127.0.0.1, as the octal string "0177" translates to the integer "127." However, netmask evaluates it as a public IPv4 address: 177.0.0.1, simply stripping off the leading zero and reading the remaining parts of the octal string as an integer.
The implications for modules that are using the vulnerable version of netmask are serious. According to Sick Codes, remote attackers can use SSRF attacks to upload malicious files from the public Internet without setting off alarms, because applications relying on netmask would treat a properly configured external IP address as an internal address. Similarly, attackers could also disguise remote IP addresses local addresses, enabling remote file inclusion (RFI) attacks that could permit web shells or malicious programs to be placed on target networks. But researchers say much more is to come. The problems identified in netmask are not unique to that module. Researchers have noted previously that textual representation of IPv4 addresses were never standardized, leading to disparities in how different but equivalent versions of IPv4 addresses (for example: octal strings) are rendered and interpreted by different applications and platforms.
Welcome to object oriented programming (Score:1, Funny)
Remember, you're not *permitted* to look at lower layers of a straction. You just assume that the authors of the lower level are competent and consistent, but actually testing it is also not permitted. And saying at the retrospective "which of you bozos cannot count to 07" is absolutely not permitted.
Re: Welcome to object oriented programming (Score:2)
The idea is rather, that there is a "contract" about the interface's behavior. And you should not look because if it diverts from that, it is a bug. So if you divert too, yoir code is faulty too, and will fall flat on its face when the underlying bug is fixed.
It does not mean you can't or shouldn'z verify the code you're using.
Just... be honest...: You wouldn't report it and wait for a fix, like you should. You would write a workaround and then the security problem would simply appear in your workaround ins
Re: (Score:3)
Compounded by the JS community being inexperienced, naive, and results-oriented rather than truly skilled. Plus, they love a toy language that was not designed for big work.
Re: (Score:2)
No everyone loves the language they work in.
Who uses octal IPv4 addresses? (Score:5, Insightful)
Who thought octal IP addresses were ever a thing? Because every single RFC, standard, and software documentation out there written in the last three decades has specified IPv4 addresses in dot-decimal notation, except for cases when documenting IP packet header address fields as 32-bit unsigned integers. Not to mention CIDR standard RFC1519 and superseding RFC4632 never mention the word octal much less provide examples for it.
So what software out there is actually using netmask program to validate octal IPv4 CIDR formatting ranges?
Re: (Score:3)
Re: (Score:3)
I agree with you a given software interface should specify the representation to be used for numeric inputs. However I don't see any reason to assume that nobody would ever want to represent a number on a computer system in any number of common base representations for various reasons.
The flaw here really is interfaces trying to be two smart. If you are taking and ipv4 address as input you really should just specify - I am expecting a 32bit unsigned, or a dotted decimal utf-8 string, or octal or whatever -
Who uses octal for anything? (Score:2)
Or rather, what's the point of using octal whatsoever? It made sense in the day of 36-bit words, but it's been decades since we standardized exclusively on 8-bit bytes.
I can't recall any legitimate use other than Unix permissions, and even there that's reordered, with set*id bits ejected to a separate octal digit from class of users they affect. On the other hand, reinterpreting numbers with leading zeroes is a fairly common error.
I'd say, let's make a new syntax: 0o33 for what's 033 currently, and have w
Re:Who uses octal IPv4 addresses? (Score:4, Interesting)
Lot's of software accepts IPv4 addresses in octal notation, for example all major browsers. There are other odd notations besides octal as well. You can just give a 32 bit number as an IPv4 address, or two octets and one number for the last two octets. You can combine these too. Browsers accept 0300.168.257 as a valid IPv4 address equal to 192.168.1.1. It's a mess. At least with IPv6 the official notation is sufficiently complicated that nobody even tries to match addresses without first normalizing them.
Re: (Score:2)
Lot's of software accepts IPv4 addresses in octal notation, for example all major browsers.
I'm unable to replicate this (debian stable, chromium and firefox esr)?
Re: (Score:2, Informative)
Chromium and Firefox on Linux Mint immediately turn http://0300.168.257 into http://192.168.1.1.
Re: (Score:2)
Chromium and Firefox on Linux Mint immediately turn http://0300.168.257 into http://192.168.1.1.
Thanks! I'm now able to replicate that and any other octal adress (what I did wrong was missing the leading 0).
Re: (Score:2)
Chromium and Firefox on Linux Mint immediately turn http://0300.168.257 into http://192.168.1.1.
Wow, that's an absolute mess (for the standard, I mean). How the fuck does it remotely make the slightest bit of sense to be mixing 3 different numeric formats together in the same address?
Re: (Score:2)
Probably https://xkcd.com/927/ [xkcd.com]
Re: (Score:3)
> So what software out there is actually using netmask program to validate octal IPv4 CIDR formatting ranges?
More clever than octal IP address formatting is turning a theoretical authorization bypass scenario into a press release.
Re: (Score:2)
False - I have had alternate IP address representations as part of my application testing punch list for years, and I have discovered multiple SSRF exploits, allowing me to access at least partially DMZ and internal resources.
Re: (Score:2)
They will be interpreted as octal if you have leading 0's. I learned that when I generated ip addresses with a program and put the leading 0'.s there to make it line up nice and neat.
But, even given that, how many people writing a program are going to actually know that they can print it out as octal and then pass it to the program to validate? I am guessing almost no one just because it requires you to deviate from decimal ip address and know octal will work.
So while the netmask program has a bug if som
Re: Who uses octal IPv4 addresses? (Score:2)
But how does an external attacker force his IP to be represented as octal?
This seems to rely non some very weird configuration created by an eight fingered sysadmin.
Re: (Score:1)
Security researchers seem to hype how many could be affected without actually disclosing that the feature while it should work is likely used by no one, and hence is simple a bug with little or no security risk.
The person doing the app with the check would have to have coded it in octal and given that is extra work to use an obscure pointless feature that most of the developers probably don't even know exist, or know out to print out octal (I don't know that I have seen a place where an octal representation
By typing I that way (Score:2)
> But how does an external attacker force his IP to be represented as octal?
By typing it with leading zeroes.
On my web page, I put an iframe or whatever pointing to http://0300.0250.0001.0001/adm... [0250.0001.0001]
Your web firewall checks for links and forms going to 192.168.1.* or 10*. So it doesn't catch that.
Your web browser, on the other hand, knows that 0300.0250.0001.0001 is the same number as 192.168.1.1, so it posts the form to your local router. Which I would then control.
This is a subclass of a larger class
Re: By typing I that way (Score:2)
Makes sense. I never even considered people had to be using text passing in server script to implement firewall like functions.
Working with text is such an error prone mess.
Re: (Score:3)
Re: (Score:3)
The international standard specifying this behavior would be IEEE Std 1003.1-2017 ("POSIX"), in the API definition for the inet_addr [opengroup.org] which is the standard interface provided for parsing IPv4 address strings. The format for an IPv4 address is specified to consist of anywhere from one to four components, each of which may be in decimal, octal, or hexadecimal notation following ISO C syntax for integer literals. The leading components are one octet each and the last one is variable length to make up a total of
Re: (Score:2)
You are wrong in your claim. Man pages, for example https://linux.die.net/man/3/in... [die.net] and https://man.netbsd.org/inet_at... [netbsd.org], do describe the accepted formats -- including octal -- for text. They have done this for decades.
Stringly typed versus strongly typed values (Score:3)
This is a great example of how loosely typed languages bite people in the ass. They try hard to have flexible handling of inputs, which means programs tend to do things like interpret strings many times, in places with potentially different validation rules, rather than converting them once and validating the resulting parsed value. In a languages where variables are more strongly typed, a "netmask" function or package would expect a parsed IP address as its input, rather than a string, and this vulnerability would never exist.
Re: (Score:2)
I don't know what you are on about considering that all textual IP addresses start off as strings until parsed.
In this rare case somebody was passing an octal dot notation formatted IP address or CIDR as a parameter but the program was parsing the IP address or CIDR as decimal dot notation as it wasn't checking for or supported leading zeros in order to use octal dot notation.
Re: (Score:3)
The vulnerability is caused by using two different parsers for validating and using the address. This happens because the language doesn't have an IPv4 address type, so passing the address around as a string is natural. First the string is passed to the validation library, which doesn't interpret a string with a leading zero as an octal number and accepts the decimal interpretation. Then the same string is passed to whatever uses the address, but that uses a different parser which knows about octal notation
Re: (Score:2)
Even when I deal with C code, it is common for various libraries to take IP address as string. Sure, getaddrinfo/inet_atop provides normalized binary representations, but that's generally not used by libraries.
Of course, having those libraries in the c library means that a library developer is less likely to roll their own string parser to get to a number for arithmetic like netmask comparison, but it's not because IP addresses are particularly strongly typed in C, it's because the language standard impleme
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You seem to be confusing programming languages and "heterogenous network environments". Implicit in this is that we're talking about checking input data, and "netmask" in particular is used for purposes like authorization checks. Input checking -- validation and authorization -- needs to be consistent, and that's harder to do with stringly typed languages.
How you build a network environment is an entirely separate question -- language or platform heterogeneity, text versus binary formats, structure of for
Re: (Score:2)
You seem to be confusing programming languages and "heterogenous network environments"
Your perception is wrong.
Implicit in this is that we're talking about checking input data
And how do you suggest this input data should be specified?
Input checking -- validation and authorization -- needs to be consistent, and that's harder to do with stringly typed languages.
And how is the input going to differ for the languages you prefer? It's not going to be a sequence of character on input?
Re: (Score:2)
I wrote about programming languages; you wrote about "heterogenous network environments". You either confused or intentionally conflated them, and I offered the interpretation that assumed good faith. If you say that interpretation was wrong, fine.
The form of input will vary based on interface. Usually, it will be one or more sequences of octets, where each sequence might be bounded (as in a UDP packet) or have indefinite length (as in a TCP stream).
The language issue I pointed at is that stringly typed
Re: (Score:2)
I wrote about programming languages; you wrote about "heterogenous network environments". You either confused or intentionally conflated them
They're not the same but they're strongly related. In heterogeneous network environments, you can't assume that endpoints have compatible representations of strongly typed values that can be communicated as-is. Hence the prevalence of textual protocols, including formats of addresses. On those people can usually agree.
The language issue I pointed at is that stringly typed languages encourage interpreting that input just before each use, rather than converting the input to a "native" (or at least canonical form) early in processing, which introduces the risk of different code treating one input string differently. That risk was realized in this example because the netmask package used a different interpretation rule than other code. In contrast, a strongly typed language (see, for example, Go's equivalent of netmask [golang.org]) would use a pre-parsed network mask and IP pair, so there's much less scope for differing interpretations.
That's not an issue of language but rather an issue of standard library. The obvious difference is that JavaScript doesn't have a standardized data structure for this purpose but Go does (bein
Re: (Score:2)
Obviously, people do not always agree about text representations about something as simple as IP addresses. If they did, we wouldn't have this thread. Various early RFCs specified IPv4 address in text form as dotted-quad with decimal only, used leading zeros in examples, prohibited leading zeros, or specified using a 32-bit unsigned integer in decimal. The sockets implementation that inspired most of the software on the Internet allows a much broader range of formats.
The presence or absence of a particul
Re: (Score:2)
Yeah, those weakly typed languages that will let a user change the format of a an integer in a string by putting a zero in front of it, like C.
sscanf '%i' format specifier will do this same thing.
Re: (Score:2)
Very few C APIs expect you to pass an integer value as a string, though.
One could reasonably argue that C has a problem in that compilers don't have to issue a diagnostic when you pass a wider integer to a function that takes a narrower integer. In contrast, the fact that number parsing normally accepts octal and hex as well as decimal doesn't make C a stringly typed language.
Re: (Score:2)
The thing is, a lot of libraries take strings for ip address. The conversion specifier of %i is just my illustration that the root cause of octal even being possible is probably linked to C code behavior.
the fact that number parsing normally accepts octal and hex as well as decimal doesn't make C a stringly typed language.
I think that's the first time I've heard someone claim C isn't strongly typed. The reality is that we can't have a language type for every possibly semantically significant meaning within the data it manipulates.
While typing helps with some issues, in this case I'd say the bigger issue is that javascript h
Barbra Streisand (Score:1)
Who said that 0177.0.0.1 must be parsed as octal? There is no law that says that. Outside the context of computers, in the real world, if you come across someone writing the number "013", you'll look at them, oddly, and then proceed as if it was 13.
You know these "Next Serving" displays in deli counters? You know, where you pull a paper ticket out of a funny-looking, circular dispenser and wait until your number comes up to get your ham and cheese? Question: when that display shows "Next Serving: 09", is t
Re: (Score:2)
Probably a bunch of networking code that used sscanf with %i not realizing that the weird octal representation implication would happen. Now we are stuck with a bunch of code that happened to support that octal notation that is too risky to change.
Re: (Score:2)
'Who said that 0177.0.0.1 must be parsed as octal?'
The moron who thought that prepending a "0" to a numeral should turn it into an octal based number.
Re: (Score:2)
Who said that 0177.0.0.1 must be parsed as octal? There is no law that says that.
While the IP RFCs certainly don't implementations of inet_addr and getaddrinfo across all of the major operating systems do behave this way.
Personally I think TFA is over the top even for Slashdot and while these types of misfeatures/misunderstandings are a source of unnecessary danger and confusion nobody is bypassing access lists with this and the justification on sick.codes is equally ridiculous. Classifying user submitted URLs as local or public as some kind of "security" measure is idiotic nonsense in
flaw or misunderstanding of specification (Score:2)
The article says 0177 should be interpreted as 127. Who specified that this is the correct interpretation. And what other systems will interpret that as an octal number that could lead to security issues? The article seems very overdramatic.
Re: (Score:1)
Every unix shell parse number as octal when they start with 0. And every widely-used programming language. Including C, Python and JAVASCRIPT.
Re: (Score:3)
Actually, not python3:
0177
^
SyntaxError: leading zeros in decimal integer literals are not permitted; use an 0o prefix for octal integers
Python decided that syntax was too weird, since 0b and 0x are used for binary and hex, 0o makes more sense to specificy the base as a prefix.
Re: (Score:2)
ping, firefox, curl, to name three.
I suspect it was at least an accident at first, an artifact of using 'auto-base' functions of C libraries (e.g. sscanf %i) that would let you do 0x or 0b for hex and binary, and in our early 'wisdom' plain old 0 meant octal.
Re: (Score:2)
A now-expired Internet draft RFC [ietf.org] traces this behavior back to 4.2BSD, calling it a "de facto standard", although the acceptance of octal, hex, or fewer than four parts, conflicts with in-passing descriptions of the format (specifying exactly four decimal parts in the range 0 to 255, or one 32-bit number) in several RFCs.
Move to IPv6 already... (Score:2)
How many? (Score:2)
This would be a really big deal if it interpreted normal IP representations incorrectly. But how many people have ever used the octal notation for an IP address?
Of the thousands or millions of users who have one of the 270,000 affected apps installed, how many of them sat down to configure it and said "I've got this big list of IP addresses that I don't want using this. I'm going to translate them into fucking octal before I type them into the config file?"
If the answer is bigger than about 2, I'd be amaz
Re: How many? (Score:2)
I can tell you how many: All of the people trying to crack the software using this library, who were somewhat persistent.
I think that's enough.
Re:How many? (Score:5, Informative)
It's a security sort of problem and you have to think about how it can be abused to do something that normally wouldn't happen rather than if it makes sense for people to normally do it.
I'm not a huge fan of 'trusted' networks so the idea of using netmask to check a peer against a 'whitelist' is anathema to me versus a stronger solution, however, let's say you do have a check and you want to make sure an IP address is *not* localhost, and your code checks and sees it's apparently 177.0.0.1 and that's fine.
Now once it gets past your filter and gets used, a large variety of libraries and utilities would go talk to 127.0.0.1:
# ping -c 1 0177.0.0.1
# curl http://0177.0.0.1/ [0.0.1]
Both of those will gleefully reach out to localhost.
Re: (Score:2)
And the person who owns 87.0.0.1 (aka 0127.0.0.1) is now sitting on a goldmine and accepting bids of 100K bitcoin for the IP :-)
From that day forward... (Score:1)
Why does it accept strings at all? (Score:1)
4 bytes for IPv4. Period.
This shit is what you get, when scriot kiddies with dynamic languages think they are programmer.
Easy scripting lanugages like BASIC or bash or JS or PHP or Python or Java were invented to enable amateurs to quickly use their computers to automate their work away (=programming). Like one-offs, shell scripts and other glue, formulas in spreadsheets, etc.
But now, this has been institutionalized and is "normal". Because the former kids grew up, became project managers, and nobody told t
Re: (Score:2)
and these same people received participation trophies when they were kids, leading them to believe they are brilliant now, and they assign themselves clever names like "SuperKendall" because they have no idea how stupid they are
It's one thing to do something dumb in code, it's quite another to put it in a library you intend the world to use. If you don't inherently know the various text encodings for integers you are unqualified to write this code, and if you do and you make this mistake you should be shot
Not sure how you would exploit this (Score:2)
Only seems to be an issue if you pass an octal number to the code, which you almost certainly won't be doing. When claiming this is a massive security issue they seem to be assuming the user supplies the IP address and could mislead you by giving something in octal. Seems more likely you'd be reading the IP address of a client in dotted decimal from network code and using that. I might be missing something, but I can't see many likely scenarios where this would be a problem.
Re: (Score:1)
The problem is "not" what "you" normaly will use as input *but* what a (BlackHad) hacker is using as a workaround for a security breach.!
But how... ? (Score:4, Interesting)
I'm struggling to see how, in the real world, the library would ever be presented with such an IP. Typically, you'd get the IP address using getpeername on a connected socket and then use inet_ntop to convert it to a text representation. And inet_ntop is certainly not going to give you an "octal-formatted" result.
So yes, it's a flaw that needs fixing, but I suspect it's very hard to exploit in the real world.
Re: (Score:2)
It's people who come up with opinions like these, and think highly enough of them to make them public, that are the reason we have crap like this.
Re: (Score:2)
You're assuming the party providing the address isn't malicious. For security you have to assume they are malicious and are constructing the address in a way that will break your software. In this case, doing something like providing a malicious address as part of a URL that scanning software will allow through (because it interprets the address one way) while the system will use the malicious destination (because it interprets the address the other way).
The problem is that IPv4 representation is ambiguous,
reading a string as an integer? (Score:2)
This is sad and embarrassing, plus is an indictment of current software development methodology of course, but...
"...simply stripping off the leading zero and reading the remaining parts of the octal string as an integer."
When "security" people are this stupid, is there any hope at all? Interpreting a string as an octal number is reading it as "an integer". Does the author not know the difference between an integer and various text encodings of that integer? BASE TEN.
This is what happens when we have Sup
Re: (Score:1)
There are lots of programmers (special jonger wans) who have never used octal or understand how it's working. Have even seen a (certified Delphi:( programmer asking me what the "const Last_Part = 0x0d;" (in a RS232 module) was doing / being used for as he did not see it as a hex presentation of a "return".
"integer" does not mean "decimal" (Score:2)
Someone doesn't know that octal also represents integers just fine.
History of programming (Score:1)