Closed Bug 160819 Opened 22 years ago Closed 8 years ago

URL: non-quad IP addresses accepted (127.1)

Categories

(Core :: Networking, defect, P4)

defect

Tracking

()

RESOLVED DUPLICATE of bug 67730
mozilla1.4alpha

People

(Reporter: benc, Unassigned)

References

()

Details

(Keywords: helpwanted, testcase)

The original test case is based on bug 12748 #16, which suggested that 127.1
works as 127.0.0.1 in some places.

Mozilla 1.1b, Mac OS X behaves correctly.
Chimera 0.4 does not.

STEPS:
Use "127.1" as IP address

EXPECTED BEHAVIOR: 
should receive error that says "hostname cannot be found"

OBSERVED BEHAVIOR:
in some platforms, seems to attempt connection to 127.0.0.1.
This should be marked INVALID. This is proper TCP/IP behavior. Please don't
screw with it or block it. I used this all the time on 10.0.0 networks to
connect to hosts.
I don't think so : 127.0.0.1 is not the same as 127.1.0.0 or 0.0.127.1
127.1 -> 127.0.0.1 IS a correct expansion, according to standards; I'm trying to
find the proper document ID for you.
I'nm unable to find an exact reference right now; although I just made sure that
it works like that in UNIX (a.b ==> a.0.0.b, a.b.c ==> a.b.0.c)
127.1 is an invalid host, but there are lots of invalid hosts currently 
accepted by the url parser.  Is there any strong following to break with 
backwards compatibility and strictly follow the standard here?
This *IS* "strictly follow the standard"s.

% ping 127.1
PING 127.1 (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=210 usec

--- 127.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.210/0.210/0.210/0.000 ms
% telnet 127.1
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
% ftp 127.1
ftp: connect: Connection refused
I was unaware that "ping", "telnet", or "ftp" was normative.  Here's the actual 
standard (per rfc 2373, 2396, and 2732):

host          = hostname | IPv4address | IPv6reference
hostname      = *( domainlabel "." ) toplabel [ "." ]
domainlabel   = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel      = alpha | alpha *( alphanum | "-" ) alphanum
ipv6reference = "[" IPv6address "]"
IPv6address   = hexpart [ ":" IPv4address ]
IPv4address   = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
hexpart       = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
hexseq        = hex4 *( ":" hex4)
hex4          = 1*4HEXDIG

In particular, ipv4 addresses must be in the form of dotted quads to be legal 
in a URI.  But like I said before, strict standards compliance probably needs 
support to overcome backwards compatibility.  Especially since this is a SHOULD 
instead of a MUST.
also win2k expands 127.1 to 127.0.0.1
For URL's, an explict dotted quad is the norm, based on my understanding.
Yes, it's the norm.

Bug what problem is this behavior causing that we want to add EXTRA CODE BLOAT
to EXPLICITLY DENY a standard form for entering TCP/IP v4 addresses?

What reason is there to go out of our way to block IP expantion?
All BSD-derived resolver libraries (including ISC's BIND package) have 
this interesting comment the the code for inet_addr/inet_aton:

   /*
    * Internet format:
    *      a.b.c.d
    *      a.b.c   (with c treated as 16 bits)
    *      a.b     (with b treated as 24 bits)
    */

I doubt this is there by accident. I am sure this is allowed in some rfc 
somewhere. In any case it is common practice and it is a system-level 
feature on essentially all unix platforms. Mozilla should not deny it.
The URL BNF requires a full dotted quad.

Even if there is an RFC that says you can do this, I don't think they are
legitimate URLs. 

From the perspective of allowing user-input, this is probably another behavior
that is acceptable for user-input, which you can send to URIfixup. 

But for the URL interfaces, I don't think this should be acceptable. We already
have a lot of stranger liberailites, like large single decimal numbers for IP
addresses. Even if the API of a specific OS or library allows this, they do not
conform to the standard. This creates a lot of ugly problems in areas such as
interoperability, error handling, security, and obfuscation.

No, cripes no. Don't do it in URIfixup. I'll withdraw my complain, but don't do
decimal/hex/oct/"c treated as 16 bits" in the app. Go ahead, block it to prevent
obfuscation. (Interoperability isn't a problem it creates, actually, blocking it
creatues interop problems. Every other app takes those sorts of IP addresses,
even IE.)
URI fixup needs to be modularized, it has become too much of a mess of
undesigned accomodations.

However, I think you are wrong about the interoperability. Many IP interfaces,
like admin servers, the ARIN WHOIS database, etc, do not seem to accept this
funny numbering, only utilities that are closely connected to the IP stacks and
access the interfaces in sort of a raw way. You shouldn't encourage it.

The costs of obfuscation are very high. Spamers and other verimin use
obfuscation to make it hard for users to clearly see what is going on. I don't
see why anyone should have to go find some kind of special de-obfuscation
utility to find out where spam came from or where the ad's source in the URL is.

I could write my bug comments in a rigid RFC, techo-gobblygook all the time, but
that wouldn't do anyone any good.
UPDATE: Mozilla 1.0 branch Mac OS 9 works corectly.
UPDATE: Win98, Mozilla 1.1 - "connection refused"
Keywords: helpwanted
gordon, could you look at this?  
Assignee: new-network-bugs → gordon
127.1 expands to local host on Netscape 4.78 (Linux).  Ultimately, were just
passing the ip address (127.1) to the OS to make the socket connection.

Ben, what is the specific problem we would solve by disabling this 'feature'?

The 1.0 branch on Mac OS 9 behaves strangely: it tries to connect to 'www.127.1'
and fails, but I would need to investigate more to determine exactly why.

I'll leave this bug open for now, but I'm not sure which way it should be
resolved yet.
Status: NEW → ASSIGNED
Priority: -- → P4
Target Milestone: --- → mozilla1.4alpha
gordon, this is a standards issue, in my mind, although I'm sure there are some
general security benefits as well.
gordon: the likely reason you saw "www.127.1" was because domain guessing gets
in the way. Tha is a preference you can switch off, as of Mozilla 1.3b.
Keywords: testcase
Another place we could have problems is the handling of these addresses in the
DOMAIN field of cookies.
We are using in my company hostnames such as "123.mycompany.com", which are 
valid and standard DNS names (see RFC 1034 and 1035).

We are encoutering this bug with Firefox 1.0/WinXP, with browser translating 
any number into IP addresses without any check (funny example: 
http://99999999999999999999 is translated into 99.15.255.255 ...).

I'm quite surpise regarding the comments below: as Nick Allen said, there are 
standards and RFCs. Do we have to argue about the necessity to respect them ?

If yes, here is our: this 'feature' is doing in our network nothing else but 
hostname spoofing and hides part of the web. 

Only solution we see now is to replace FireFox by Internet Explorer as this 
one behave correctly regarding this aspect, which is quite a pity.

Also, and regarding the "ping" example: making a snoop, you will see that ping 
first try to resolve "127.1"+".localdomain", before falling back to IP address 
if it receives a DNS error response. Can we at least expect to have such 
behaviour implemented ?
Karel: your problem is actually bug 67730, and it is not really our fault. We
just send the string to the OS, and in some cases, it does not behave as expected.
Assignee: gordon → nobody
Status: ASSIGNED → NEW
QA Contact: benc → networking
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.