full-disclosure - Re: Internet Explorer URL parsing vulnerabi lity

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20031213032426.HTJG306659.fep03-mail.bloor.is.net.cable.rogers.com@BillDell>
From: full-disclosure at royds.net (Bill Royds)
Subject: Re: Internet Explorer URL parsing vulnerabi	lity

Although RFC2396 describes the general format of all URI schemas (its title
is Uniform Resource Identifiers (URI): Generic Syntax), not the syntax for
HTTP URI. A particular RFC for an application protocol can what parts of the
general URI scheme are allowed and those that are not. In particular, HTTP
is not supposed to use the userinfo part of the URI. RFC2396 itself
recommends not to use userinfo for the user:password schema that IE
implements. From section 3.2.2

Some URL schemes use the format "user:password" in the userinfo
   field. This practice is NOT RECOMMENDED, because the passing of
   authentication information in clear text (such as URI) has proven to
   be a security risk in almost every case where it has been used.
RFC2616 which defines HTTP 1.1 section 3.2.2 (coincidentally) does not allow
userinfo part at all.
3.2.2 http URL

   The "http" scheme is used to locate network resources via the HTTP
   protocol. This section defines the scheme-specific syntax and
   semantics for http URLs.

   http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

   If the port is empty or not given, port 80 is assumed. The semantics
   are that the identified resource is located at the server listening
   for TCP connections on that port of that host, and the Request-URI
   for the resource is abs_path (section 5.1.2). The use of IP addresses
   in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If
   the abs_path is not present in the URL, it MUST be given as "/" when
   used as a Request-URI for a resource (section 5.1.2). If a proxy
   receives a host name which is not a fully qualified domain name, it
   MAY add its domain to the host name it received. If a proxy receives
   a fully qualified domain name, the proxy MUST NOT change the host
   name.

SO the situation we have here is an implementation of an HTTP browser that
breaks the RFC and creates a security problem with doing so.
That is called a vulnerability to my mind. 

-----Original Message-----
From: full-disclosure-admin@...ts.netsys.com
[mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of Nick FitzGerald
Sent: December 12, 2003 6:09 AM
To: full-disclosure@...ts.netsys.com
Subject: RE: [Full-Disclosure] Re: Internet Explorer URL parsing vulnerabi
lity

jbruce@...tedscience.com wrote:

> Using internet explorer, you can also put http://whateverhere@...gle.com
> and that will take you to google. It only matters what you put after the
> @ sign. I noticed that one day while putting in my email address in for
> hotmail. 

And not _just_ in IE.

What you have described is, in fact, more or less the "expected 
behaviour" of a web browser given the input you described and RFC 2396. 
Surely to comment in such a thread you have read the RFC that defines 
the format of URIs:

   ftp://ftp.rfc-editor.org/in-notes/rfc2396.txt

Search for "userinfo".

...

I'll repeat my earlier suggestion that I'm sure it would be greatly 
appreciated all round if only moderately clueful responses were posted 
in this thread...

Regards,

Nick FitzGerald

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html