full-disclosure - Re: The Extended HTML Form attack revisited

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] [thread-next>] [day] [month] [year] [list]

Date: Thu, 19 Jun 2008 11:09:48 +1000
From: kuza55 <kuza55@...il.com>
To: "Sandro Gauci" <publists@...blesecurity.com>
Cc: full-disclosure@...ts.grok.org.uk, websecurity@...appsec.org
Subject: Re: The Extended HTML Form attack revisited

Hi,

Just thought I'd let you know that Wade Alcorn wrote a similar paper
in 2006: http://www.bindshell.net/papers/ipc (Using IMAP3 too), but of
course things have changed since then (namely this attack not working
against Firefox 2 or 3).

Also, there is a complete list of ports that Firefox blocks here:
http://www.mozilla.org/projects/netlib/PortBanning.html (which Wade's
paper references), and the default protocol handlers which can speak
to the blocked ports. Do you know if there's a list of ports published
by Microsoft/Opera/Apple about which ports are blocked in their
browsers? If not, would you be able to publish the ports you found
blocked in an appendix (I'm sure it wouldn't be too much code to whip
up to test it, but if you've already done so then there's no point in
duplicating work)?

I also did some digging myself and found that the reason Firefox
doesn't render the response as HTML is because it searches for the
string "http" (case-insensitive, no quotes) in the first 8 bytes of
the response; if you can satisfy that condition somehow then you can
still get it to happen, but of course that seems pretty unlikely.

IE also tries to search for a string, in this case "http/"
(case-insensitive, no quotes) in the first 1024 bytes, but only so
that it can identify http headers, so if you can inject data into the
first 1024 bytes of the response you can inject headers to do cache
poisoning, etc. (You can probably do header injection against Firefox
if you can trigger this, but the problem is of course triggering it on
FIrefox)

 - kuza55

2008/6/19 Sandro Gauci <publists@...blesecurity.com>:
> Hi -
>
> Back in 2002 I had published details of a vulnerability affecting most
> web browsers. It detailed a security flaw that allows attackers to
> abuse non-HTTP protocols to launch Cross Site Scripting attacks even
> when a target web application was not vulnerable to XSS.
>
> Six years later I'm releasing an update to this research in this
> paper. This security vulnerability still affects popular web browsers
> nowadays and the following browsers were tested as vulnerable:
>
>   * Internet Explorer 6
>   * Internet Explorer 7
>   * Internet Explorer 8 (beta 1)
>   * Opera 9.27
>   * Opera 9.50
>   * Safari 1.32
>   * Safari 3.1.1
>
> Others have described how to abuse behavior for purposes other than
> Cross Site Scripting. NGSSoftware previously published a paper called
> "Inter-Protocol Exploitation" which references the original EyeonSecurity paper.
>
> Paper at:
> http://resources.enablesecurity.com/resources/the%20extended%20html%20form%20attack%20revisited.pdf
>
> or http://tinyurl.com/5d88ll
>
> --
> Sandro Gauci
> EnableSecurity
> Web: http://enablesecurity.com/
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/