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. http://www.opengroup.org/onlinepubs/009695399/functions/inet_addr.html 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 atol() internally. 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 rest field. 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: ddd.ddd.ddd.ddd 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).