I like to use these "funny" addresses for two purposes:

  ping 1.1

(1.0.0.1 - cloudflare dns server)

  use 10.1 10.2 10.3 as IP addresses in my home network

(10.0.0.1/24)

off-topic: thanks @Daniel Stenberg for curl and for rockbox back in the day when it first showed me the wonders of open-source.

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

Also I see rockbox is still active. Nice

Nice! Rockbox was the first open source project I was involved in. In the iRiver H120 days. Really cool to see it still alive.

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?

Storing ipv4 addresses as 32bit numbers is common so I can certainly see a use for that.

I'm not sure why you were downvoted. If this is true, it seems like it would save developers a conversion step when making a request.

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.

But then it wouldn't be a valid IP.

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

127.1.0.0 is a perfectly valid IP address. The loopback range is a /8.

You're right. I got confused a bit.

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?

Commit is here: https://github.com/curl/curl/commit/56a037cc0ad1b2a770d0c08d...

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?

I use them fairly often, but I'm a network engineer.

I odo ccasionally use the (already-mentioned)

  $ ping 1.1

  $ 10.1

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

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.

Syslinux, specifically PXELINUX: https://wiki.syslinux.org/wiki/index.php?title=PXELINUX#Conf...

Quite nifty I'd say.

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.

Most *nixes accept a lot of these weird formats in many contexts.

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:

    ping 0a00.0101

Curl is so awesome :)

This is so wholesome: https://twitter.com/bagder/status/1384147826133790724?s=20

Original netcat supports abbreviated addresses such 127.1 instead of 127.0.0.1

Have not seen many other programs adopt this. It's useful. Less to type.

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.

It doesn't just mean "fill in zeros".

It should be supported by most programs that use the c library to resolve hostnames, I believe.

I just tried it in Safari and it worked, so that's nice at least. Thanks for the tip!

Wouldn't it make more sense to just not support those weird formats? Nobody uses them and they can help attackers (mentioned in the post).

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.

Hoe many of those old in house scripts that aren't maintained or updated are keeping curl up to date?

Some kind of build option or runtime CURLOPT would be ideal for this. I think we'd want to disable it by default in Fedora though.

I've seen software that uses the "single decimal number" representation in order to store IP address in a database integer type column

That's how they're stored in memory too, but that's just for storage. It is probably decoded to normal dotted form by the database layer.

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.

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.

> don't do "curl | sudo bash", kids.

But do "npm"? Is "npm" any safer?

> inb4 sudo