554596 - Non-standard IP address specifications in URLs are a security risk

Status: RESOLVED DUPLICATE of bug 67730

(Core :: Networking, defect)

Description

[Neil Harris]

According to this post: http://www.viruslist.com/en/weblog?weblogid=208188044 , Firefox still supports a number of obscure and outdated formats for IP addresses, including octal and hex representations and representing the entire IP address as a single 32-bit number.

Currently these seem to have no mainstream use other than as an obfuscation technique used to evade third-party URL filters. According to the post cited above, this technique is currently being used in the wild.

Removing support for these formats would increase security without removing any significant functionality.

The following test cases, all of which currently resolve to access a google.com webserver, are provided by the post cited above:

* http://0x42.0x66.0x0d.0x63
* http://0x42660d63
* http://1113984355
* http://00000102.00000146.00000015.00000143

Comment 1

[Neil Harris]

There would seem to be two logical places to apply this restriction:
* at the text-string-to-IP-address lookup interface
* in the URL parser

Rather than attempt to detect abusive formats, implementations should instead rigorously check that the text string provided the RFC-based definitions of IP address formats before passing those text strings down to lower-level routines.

Whatever implementation is put in place should enforce similarly conservative restrictions on both IPv4 and IPv6 address strings.

Comment 2

[Neil Harris]

net_IsValidHostName() in nsURLHelper.cpp and/or PR_StringToNetAddr() in prnetdb.c may be good places to put this logic

Comment 3

[Neil Harris]

Suggested logic:

If a name is 

     entirely made out of one or more sequences of digits, each optionally prefixed by "0x" or "0X", separated by label separators

then 

    it is invalid, 

    _unless_ every one of those sequences is a decimal number in the range 0-255, without either leading zeroes or a 0x-prefix.

Comment 4

[Neil Harris]

Attachment: Small python program to test out ideas in comments above

This is a small Python program designed to explore the problem space.

Comment 5

[Neil Harris]

Attachment: Small python program to test out ideas in comments above

Output of enclosed program:

test case: http://google.com valid
test case: http://0x42.0x66.0x0d.com valid
test case: http://0x42.0x66.0x0d.0x63 bogus: numeric alias
test case: http://0x42.0x66.0xd.0x63 bogus: numeric alias
test case: http://0x42660d63 bogus: numeric alias
test case: http://1113984355 bogus: numeric alias
test case: http://00000102.00000146.00000015.00000143 bogus: numeric alias
test case: http://00000102.00000146.00000015.0x63 bogus: numeric alias
test case: http://0x42.0x66.0x0z.0x63 valid
test case: http://0x4266.0x0z.0x63 valid
test case: http://1.2.3.4 valid

Comment 6

[Neil Harris]

Reviewing inet_pton.c and gethnamaddr.c in the source of glibc makes the puzzle deeper: these ambiguous hex and octal strings are clearly being resolved somewhere, but where?

Comment 7

[Neil Harris]

OK, the badness appears to be happending in inet_aton(). Various implementations of inet_aton() have exciting semi-documented features such as two- and three-part dotted numerical addresses, thus:

 a.b -- 8.24 bits -- example: http://0x42.0x660d63 
 a.b.c -- 8.8.16 bits -- example: http://0x42.0x66.0x0d63

Other interesting features seem to be numeric overflow bugs in some implementations, allowing even more aliases to be created, all of which resolve to the same IP address.

Comment 8

[Neil Harris]

More useful information:

http://tools.ietf.org/html/draft-main-ipaddr-text-rep-00 -- see section 2.1.1, "Early Practice", which explains how the 4.2BSD inet_aton() became the de-facto standard for IPv4 address interpretation, and that compatibility with this lingers to this day. It concludes:


   The 4.2BSD inet_aton() has been widely copied and imitated, and so is
   a de facto standard for the textual representation of IPv4 addresses.
   Nevertheless, these alternative syntaxes have now fallen out of use
   (if they ever had significant use).  The only practical use that they
   now see is for deliberate obfuscation of addresses: giving an IPv4
   address as a single 32-bit decimal number is favoured among people
   wishing to conceal the true location that is encoded in a URL.  All
   the forms except for decimal octets are seen as non-standard (despite
   being quite widely interoperable) and undesirable.

http://www.pc-help.org/obscure.htm contains a number of different examples of IP address obfuscation techniques, including uses of the numeric overflows described above.

Comment 9

[Neil Harris]

After some more thought, the proper solution of this looks much easier than the complex code I was considering above. In psuedo-code:

def lookup_name(name):
   try:
       address = lookup_numeric_address(name)
   except:
       return DNS_lookup(name)

   if name == numeric_address_representation(address):
       return address
   else:

Comment 10

[Neil Harris]

That was cut off prematurely. Let's try that again:

def lookup_name(name):
   try:
       address = lookup_numeric_address(name)
   except:
       return DNS_lookup(name)

   if name == numeric_address_representation(address):
       return address
   else:
       raise bad_numeric_address

Comment 11

[Neil Harris]

A thought... since the code of inet_aton() in the GNU libraries _is_ the BSD code, and is already BSD-licenced, we can simply use a cut-down version of the code there to detect these sorts of numeric cases, triggering the double-check that the IP address is in the canonical form.

Comment 13

[Jesse Ruderman]

> According to this post: http://www.viruslist.com/en/weblog?weblogid=208188044

This URL is now the front page of the blog.  The post is now at

http://www.securelist.com/en/blog/148/New_Brazilian_banking_Trojans_recycle_old_URL_obfuscation_tricks