Bug 331791 - inet_aton(), inet_atoi() are too permissive for inputs
inet_aton(), inet_atoi() are too permissive for inputs
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-10-15 03:09 EDT by matti aarnio
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-15 03:33:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description matti aarnio 2007-10-15 03:09:11 EDT
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.
Comment 1 Jakub Jelinek 2007-10-15 03:33:58 EDT
Google is your friend.
is very explicit how it should behave.
Comment 2 matti aarnio 2007-10-15 14:56:24 EDT
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, or

   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:


   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,  but not 
2130706433 (nor 0x7f000001, nor 017700000001).

Note You need to log in before you can comment on or make changes to this bug.