Add parsing of shorthand IPv4 addresses (compatible with inet_aton)

[Envek]

Implementation for Feature request #15734 from Ruby bug tracker.

---

Many applications (like browsers, curl, and ping) and even Ruby's own Net::HTTP library accepts shorthand IPv4 addresses like 127.1 or 2130706433 that both stands for 127.0.0.1.

$ irb
irb(main):001:0> require 'net/http'
irb(main):002:0> Net::HTTP.get(URI.parse("http://127.1/")) # Success if you have web server running locally
=> "<!DOCTYPE html>\n<html>\n<head>\n<title>Welcome to nginx!</title>…"

But IPAddr can't accept such addresses, and it is really confusing:

irb(main):003:0> IPAddr.new("http://127.1/")
IPAddr::InvalidAddressError (invalid address: http://127.1/)

This pull request makes parsing IPv4 to match the behavior of most well-known applications despite that isn't a standardized extension, but there is an RFC draft: Textual Representation of IPv4 and IPv6 Addresses.

Moreover, that mismatch in behavior could cause security vulnerabilities in Ruby applications that use network, allow users to provide URLs to access (like “Upload picture from URL”), and have incorrectly configured URL filtering. A malicious user then could provide a link like http://2130706433/private_file which currently will not be recognized as loopback IP address but Net::HTTP.get will happily query local host's web server for the private_file. This called an SSRF attack. Actually, I created this pull request because our security auditors reported such vulnerability in one of our applications.
NOTE: There is no security flaw in ipaddr itself! It is just possible to create it when you're developing your own application.

See also:

• Discussion at Reddit: https://www.reddit.com/r/networking/comments/7cf0zp/documentation_of_the_behavior_of_shorthand_ipv4/
• inet_aton man page: https://linux.die.net/man/3/inet_aton

[wacaw]

Hi All!

I created "pull request to this pull request" - Envek#1 (because my changes based on this PR changes) to support for IP addresses represented in hexadecimal, octal or even a combination, instead of the decimal encoding. This PR supports all of this formats:

IPFuscator
Author: Vincent Yiu (@vysecurity)
https://www.github.com/vysec/IPFuscator
Version: 0.1.0

IP Address:     127.0.0.1

Decimal:        2130706433
Hexadecimal:    0x7f000001
Octal:          017700000001

Full Hex:       0x7f.0x0.0x0.0x1
Full Oct:       0177.0.0.01

Random Padding:
Hex:    0x000000000007f.0x000000000000000000000000000000.0x0000.0x0000000000000000000000001
Oct:    00000000000000000000000177.000000000000000000.00000000000000000000000000000.000001

Random base:
#1:     0x7f.0x0.0.01
#2:     0x7f.0x0.0x0.1
#3:     0177.0x0.0x0.0x1
#4:     0x7f.0.0.01
#5:     127.0x0.0.0x1

Random base with random padding:
#1:     127.0x00000000.000000.000000000000000001
#2:     127.0x0000000000000.0x00000000000000000000000000000.0001
#3:     0000000000000000177.0x0000000000000000000000.0x00000000000000000000000000.1
#4:     0000000000000000000177.0.000000.1
#5:     127.0000000000000000000000.0x0000000000000000000.000000000000000000000000000001

(Take any representation and use it in commands such as ping)

More info about IPFuscation - https://vincentyiu.co.uk/red-team/cve-exploitation/ipfuscation

[Envek]

@taketo1113, following our talk at Kaigi on Rails, I've updated this pull request and resolved merge conflicts.

Here is also additional context on why we needed this change:

Back in 2019 security auditors found a possible security flaw in one of apps that allowed users to import pictures by URL. Malicious user could send pointing to localhost or local network and force our picture importer to hit private resources and hence there is possibility for making a (D)DoS attack.

So we needed a way to filter out non-public addresses:

nonpublic_address =
  ip.private? ||    # 10.0.0.0/8, 192.168.0.0/16 – local networks
  ip.loopback? ||   # 127.0.0.1 or [::1] – localhost
  ip.link_local? || # 169.254.0.0 – autoconfigured local networks
  ip.to_i.zero?     # 0.0.0.0 or [::] – any address, effectively localhost

The problem is that user (either malicious or not) can send an URL like https://127.1/whatever which is completely fine for Ruby's Net::HTTP or other tools, but not recognized by IPAddr which is simply confusing.