How do you know nobody uses them? I'd be willing to bet that there are many older in-house scripts puttering away in some dark, webbed corners of internal networks, which rely on this functionality, e.g. because they are getting their input from some obscure network appliances which print IP addresses like that.
I would fully expect support for these "weird" formats to be a (enabled by default) build-time option, but it's a good thing that curl maintainer is not just cutting it off right away.
People trying to circumvent censorship often look like "attackers".
When I was in middle school, I needed to research a paper in the school library computers. Their stupid computers were always messed up; first the proxy settings weren't configured in half the machines (I fixed that, and got scolded), then the anti-virus wasn't working (fixed that, got scolded). Then the proxies wouldn't let me search for my paper.
I was a budding hacker, so I figured out the numbering trick mentioned in this article, and was able to bypass the proxy and do my research for my paper. This was a long time ago but I bet the same situation is just as relevant today. (Doubtful that you'd use curl in this scenario, but nice to know they are preserving useful functionality rather than throwing it out)
Question: how did this trick help you bypass the proxy?
The only way I can think of this possibly helping you is by changing the Host header and that somehow fooling the proxy into allowing your connection through. However some random testing with both a modern browser and a really old version of firefox I have installed shows that it seems to convert the 'weird number format' into a proper IP address, even when using a proxy. In other words, I cannot see how using these weird IPs ever could make a difference from the proxy's perspective.
Slightly surprised that curl went this way, instead of actively rejecting them. Is there anyone using these obscure formats in the real world, except for attackers?
I had the same reaction, especially after Daniels paragraph on how the more obscure formats can and has been used by bypass validation filters.
But, I'm also happy for having curl be more consistent with itself, so that it has the same behaviour on developer workstation and in production, since I'd imagine most pen-testing happens by developers locally.
I agree. The article even says that these odd formats are used to bypass filters but cannot pinpoint why BSD 4.2 added support for them in 1983.
It hints that certificate validation fails in some cases, but that seems even more niche. What applications are using certs with IP-in-CN anyway in 2021? Shouldn't any IPs be in the "typed" SAN extension?
I would guess because the point of the number parsing is to end-up producing that final 32-bits value. If you already have the 32-bits value, there is no point in parsing it, so there is no point in supporting it in the address text parser.
Like the article mention, supporting obscure features just makes it more likely that they can be exploited for nefarious purposes. It's not worth saving typing 4-5 characters from times to times.
Before reading the article, I would have assumed for example that 127.1 would be 127.1.0.0, not 127.0.0.1.
> If you already have the 32-bits value, there is no point in parsing it, so there is no point in supporting it in the address text parser.
There is a point when the only interface to that program is via text. You still have to convert the 32-bit value to text, but there's a difference between that and converting it to IPv4's dot notation. The former is simpler.
> It's not worth saving typing 4-5 characters from times to times.
I don't think the main users of the feature are people manually typing those addresses.
> Before reading the article, I would have assumed for example that 127.1 would be 127.1.0.0, not 127.0.0.1.
I'm also slightly disappointed because I thought they either drop support or introduce a strict mode that can be used to disable support for esoteric formats.
Firefox will try and convert decimals (and perhaps numbers of other bases) into an IPv4 representation. I discovered this the other day after accidentally inputting “1” into the address bar.
Since IPv4 addresses are natively a 32-bit integer at the level of BSD sockets, it makes sense to allow curl to accept them without having it be re-parsed back out into a dotted-quad. Many tools and databases will store addresses natively this way. Let's say you were writing a script to take that information and probe it with curl; convenient to just printf("https://0x%x", ip_address), you know?
Didn't know they came from the same person. Thanks for bringing Rockbox back to mind! That was the first custom firmware I've been toying around with, trying to watch scaled down Star Wars - Clone Wars on the tiny 1,5inch screen of my iPod 2G :D
I wonder how much more effective malicious scripts might be if something like "curl -L 16843009" is used as an obfuscation. Sure, it would have to check the locally installed curl version first. But hiding something like this away in a deeply nested function .. anyway, don't do "curl | sudo bash", kids.
It's also ambiguous. Why is 127.1 equal to 127.0.0.1 but not 127.1.0.0? Why would 127.1.1 be equal to 127.1.0.1 but not 127.0.1.1 or 127.1.1.0? Neither of those addresses can be discarded because they're base addresses, since the subnet 127/8 only has one base address: 127.0.0.0
At least IPv6 made this practice non-ambiguous by requiring a double colon (::) and mandating that at most one :: can exist in a valid address.
It's not really ambiguous. 127.X does not equal 127.0.0.X. 127.X means, the first octet is described by the first number, and the last three octets is described by the second number, and X is not limited to 0-255. Thus 127.256 is equivalent to 127.0.1.0, something that would not be possible to express with your alternative interpretations.
Wow, almost thirty years on the internet and learned a new thing today.
I often wanted hexadecimal IP4 addresses because the standard format is hard to type and some octets in decimal expand to three digits. However seeing it in action and requiring the "0x…" prefix has made me less enthused:
ping 0x0a000101
ping 0x0a.0x00.0x01.0x01
Frankly that sucks, no wonder it never caught on. Something shorter with a fixed length like the below would have made me happier, though the ship sailed decades ago:
38 comments
[ 2.7 ms ] story [ 23.0 ms ] threadI would fully expect support for these "weird" formats to be a (enabled by default) build-time option, but it's a good thing that curl maintainer is not just cutting it off right away.
When I was in middle school, I needed to research a paper in the school library computers. Their stupid computers were always messed up; first the proxy settings weren't configured in half the machines (I fixed that, and got scolded), then the anti-virus wasn't working (fixed that, got scolded). Then the proxies wouldn't let me search for my paper.
I was a budding hacker, so I figured out the numbering trick mentioned in this article, and was able to bypass the proxy and do my research for my paper. This was a long time ago but I bet the same situation is just as relevant today. (Doubtful that you'd use curl in this scenario, but nice to know they are preserving useful functionality rather than throwing it out)
The only way I can think of this possibly helping you is by changing the Host header and that somehow fooling the proxy into allowing your connection through. However some random testing with both a modern browser and a really old version of firefox I have installed shows that it seems to convert the 'weird number format' into a proper IP address, even when using a proxy. In other words, I cannot see how using these weird IPs ever could make a difference from the proxy's perspective.
But, I'm also happy for having curl be more consistent with itself, so that it has the same behaviour on developer workstation and in production, since I'd imagine most pen-testing happens by developers locally.
It hints that certificate validation fails in some cases, but that seems even more niche. What applications are using certs with IP-in-CN anyway in 2021? Shouldn't any IPs be in the "typed" SAN extension?
Commit is here: https://github.com/curl/curl/commit/56a037cc0ad1b2a770d0c08d...
Like the article mention, supporting obscure features just makes it more likely that they can be exploited for nefarious purposes. It's not worth saving typing 4-5 characters from times to times.
Before reading the article, I would have assumed for example that 127.1 would be 127.1.0.0, not 127.0.0.1.
There is a point when the only interface to that program is via text. You still have to convert the 32-bit value to text, but there's a difference between that and converting it to IPv4's dot notation. The former is simpler.
> It's not worth saving typing 4-5 characters from times to times.
I don't think the main users of the feature are people manually typing those addresses.
> Before reading the article, I would have assumed for example that 127.1 would be 127.1.0.0, not 127.0.0.1.
But then it wouldn't be a valid IP.
> But then it wouldn't be a valid IP.
127.1.0.0 is a perfectly valid IP address. The loopback range is a /8.
Quite nifty I'd say.
I odo ccasionally use the (already-mentioned)
variants, but I use "these obscure formats" more frequently when dealing with 4-byte ASNs (cf. [0], for example).--
[0]: https://ccieblog.co.uk/bgp/bgp-4-byte-as-numbers
off-topic: thanks @Daniel Stenberg for curl and for rockbox back in the day when it first showed me the wonders of open-source.
Also I see rockbox is still active. Nice
But do "npm"? Is "npm" any safer?
> inb4 sudo
Have not seen many other programs adopt this. It's useful. Less to type.
At least IPv6 made this practice non-ambiguous by requiring a double colon (::) and mandating that at most one :: can exist in a valid address.
It doesn't just mean "fill in zeros".
I often wanted hexadecimal IP4 addresses because the standard format is hard to type and some octets in decimal expand to three digits. However seeing it in action and requiring the "0x…" prefix has made me less enthused:
Frankly that sucks, no wonder it never caught on. Something shorter with a fixed length like the below would have made me happier, though the ship sailed decades ago: