Red Hat Bugzilla – Bug 331791
inet_aton(), inet_atoi() are too permissive for inputs
Last modified: 2007-11-30 17:12:18 EST
Description of problem:
inet_addr() and inet_aton() accept questionable values as IP literals.
In particular: 0x3eb7878d 1052215181
Because applications like web browsers then often look at host name parts
of URLs as "let system resolve this", whatever system does by default will
result in oddball functional URLs that are in active use by phisers.
http://0x3eb7878d/ is just a flash clock, but far more sinister URLs
do appear daily in spams.
Also commands like: "telnet 0x3eb7878d 80" and "telnet 1052215181 80"
do work, so it isn't limited on web-browsers only.
On bug 122038 the issue was also considered and resolved as "NOTABUG"
because POSIX says that such should be accepted. In this regard POSIX
is wrong by being much too permissive. (I don't have referred POSIX
document available to me, thus can't verify what was said there.)
Version-Release number of selected component (if applicable):
This has been functional for several years and still is.
Google is your friend.
is very explicit how it should behave.
On this particular detail the POSIX is wrong. Authoritative on what
constitutes as valid IPv4 address literals are IETF's RFC document series.
What POSIX codifies is essentially BSD 4.2 fast-and-loose behaviour using
RFC 820: Assigned numbers
second document in series which describes the "dotted decimal" notation,
and does it better than RFC 819 which mentions it all too briefly
One commonly used notation for internet host addresses divides the
32-bit address into four 8-bit fields and specifies the value of each
field as a decimal number with the fields separated by periods. This
is called the "dotted decimal" notation. For example, the internet
address of ISIF in dotted decimal is 010.002.000.052, or 10.2.0.52.
The dotted decimal notation will be used in the listing of assigned
network numbers. The class A networks will have nnn.rrr.rrr.rrr, the
class B networks will have nnn.nnn.rrr.rrr, and the class C networks
will have nnn.nnn.nnn.rrr, where nnn represents part or all of a
network number and rrr represents part or all of a local address or
In the "dotted decimal" there is at least one dot!
And leading zeroes are just ignored, NOT treated as a sign of octal
or possibly hex.
RFC 822 defines that SMTP receivers must accept domain-literals, which are
IP addresses in square brackets, and gives extremely permissive syntax..
RFC 1123 on chapter 2.1 discusses further proper behaviour of dotted-decimal
parsing. By the RFC 1122/1123 time, the domain-literal of form "[#1234567890]"
was already deprecated.
RFC 2133 page 27 / RFC 2553 page 31 / RFC 3493 page 32:
(discussing about inet_pton(), but refers to inet_addr() et al.)
If the af argument is AF_INET, the function accepts a string in the
standard IPv4 dotted-decimal form:
where ddd is a one to three digit decimal number between 0 and 255.
Note that many implementations of the existing inet_addr() and
inet_aton() functions accept nonstandard input: octal numbers,
hexadecimal numbers, and fewer than four numbers. inet_pton() does
not accept these formats.
I do find "telnet 127.1 25" quite useful shorthand, but officially it is
not proper dotted-decimal, and should not be accepted. If we are to extend
the specification, I would permit 127.1, 127.0.1, and 127.0.0.1, but not
2130706433 (nor 0x7f000001, nor 017700000001).