Closed
Bug 160819
Opened 22 years ago
Closed 8 years ago
URL: non-quad IP addresses accepted (127.1)
Categories
(Core :: Networking, defect, P4)
Core
Networking
Tracking
()
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.
Comment 1•22 years ago
|
||
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.
Comment 2•22 years ago
|
||
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)
Comment 5•22 years ago
|
||
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?
Comment 6•22 years ago
|
||
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
Comment 7•22 years ago
|
||
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.
Comment 8•22 years ago
|
||
also win2k expands 127.1 to 127.0.0.1
For URL's, an explict dotted quad is the norm, based on my understanding.
Comment 10•22 years ago
|
||
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?
Comment 11•22 years ago
|
||
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.
Reporter | ||
Comment 12•22 years ago
|
||
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.
Comment 13•22 years ago
|
||
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.)
Reporter | ||
Comment 14•22 years ago
|
||
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.
Reporter | ||
Comment 15•22 years ago
|
||
UPDATE: Mozilla 1.0 branch Mac OS 9 works corectly.
Reporter | ||
Comment 16•22 years ago
|
||
UPDATE: Win98, Mozilla 1.1 - "connection refused"
Keywords: helpwanted
Comment 18•22 years ago
|
||
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
Reporter | ||
Comment 19•22 years ago
|
||
gordon, this is a standards issue, in my mind, although I'm sure there are some general security benefits as well.
Reporter | ||
Comment 20•21 years ago
|
||
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
Reporter | ||
Comment 21•21 years ago
|
||
Another place we could have problems is the handling of these addresses in the DOMAIN field of cookies.
Comment 22•19 years ago
|
||
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 ?
Reporter | ||
Comment 23•19 years ago
|
||
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.
Updated•15 years ago
|
Assignee: gordon → nobody
Status: ASSIGNED → NEW
QA Contact: benc → networking
Updated•8 years ago
|
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.
Description
•