Re: Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass

[Roberto Suggi Liverani <roberto.suggi () security-assessment com>]

Hi Chris, Billy and Michal,
 
The Host: headers and the ability to perform non-standard HTTP request
is a separate issue from what I reported to Oracle on SOP bypass. 
 
I have only done some research on a XSRF attack involving use of a Java
Applet with two multiple Host: headers matching the same domain. 
 
More details here:
http://www.security-assessment.com/files/whitepapers/Leveraging_XSRF_with_Apache_Web_Server_Compatibility_with_older_browser_feature_and_Java_Applet.pdf

 
The above attack seems effectively mitigated by the latest JRE patch.
 
However, I don't think this was patched in response of my bug report on
Java JRE SOP bypass ;-)
 
Also, I did share the above research only with Apache Security Team. Not
sure if this leaked or someone else separately reported the fact of
having Java Applet to control Host: headers in the HTTP request as a bug.
 
At the link below, several people have been thanked in the credit
statement from Oracle, but not all details of the bugs have been shared
publicly yet.
 
http://www.oracle.com/technetwork/topics/security/javacpuoct2010-176258.html

 
 
Regarding my testing, here are some details.
 
In my test environment, www.badsite.com and www.targetsite.net resolve
to the same IP address.
 
After loading the MaliciousJavaApplet from www.badsiste.com which makes
a request with two Host: headers matching the same domain (in this case
www.targetsite.net) to www.targetsite.net,
the Java Applet makes the browser perform the following request:
 
GET /private/secret.html HTTP/1.1
accept-encoding: gzip
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_22
Host: www.targetsite.net
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Proxy-Connection: keep-alive
If-Modified-Since: Sat, 24 Jul 2010 12:08:48 GMT
Cookie: aa=aa
 
This was tested with Firefox 3.5.8 in Windows XP SP3 and the latest JRE
version.
 
With the previous JRE version, the HTTP GET request was the following:
 
GET /private/secret.html HTTP/1.1
Host: www.targetsite.net
Host: www.targetsite.net
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_21
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Proxy-Connection: keep-alive
Cookie: aa=aa
 
The two Host: headers were included in the request. 
 
To be honest, I haven't spent much time on looking how to perform
malformed HTTP requests with Java Applet as my original focus was on SOP
bypass and leaking sensitive data.
Not sure either what is the impact of the latest JRE patch on other
aspects that Billy raise such as file extension, content-type, or
content-disposition. This definitely needs more time for an
accurate review.
 
At this stage I can only say that the attack described in my paper is
indeed mitigated by the latest JRE patch.
 
Cheers,
 
Roberto

Chris Evans wrote:
> On Wed, Oct 20, 2010 at 2:29 PM, Billy Rios <billy.rios () gmail com
> <mailto:billy.rios () gmail com>> wrote:
>
>     In the patch for CVE-2008-5343 (GIFAR) Sun tightened their file
>     parsing rules for remote JAR files, making it harder to smuggle
>     JAR files onto the end of other filetypes.  This makes it more
>     difficult to create a GIF+JAR hybrid file.  AFAIK, local JAR files
>     were considered out of scope and will not be subject to the
>     additional file parsing scrutiny.
>
>
> Do you have a link to details on how the new parsing heuristic works,
> and how "remote" is determined?
>
>
>     Sun/Oracle has not removed the ability to modify arbitrary HOST
>     headers.
>
>
> Isn't that what they fixed in response to Roberto's latest report?
> Roberto, any idea what was changed?
>
>
> Cheers
> Chris
>  
>
>     So, if an attacker can upload a JAR file to a web app, they will
>     have the ability to jump to any domain (virtual hosted or
>     subdomain) that exists on the server.  The cookies sent by the
>     applet will be from the domain provided in the URL object, however
>     the content returned by the server will be from the domain
>     specified in the HOST header.  This can cause havoc for places
>     where separation relies on subdomains (like wordpress.com
>     <http://wordpress.com> et al.) where users have by-design control
>     of content on one subdomain and uses that content to target users
>     on a different subdomain.  
>
>     Java also doesn't respect file extension, content-type, or
>     content-disposition returned by the web server making it a bit
>     easier to upload JAR files to unsuspecting web apps.
>
>
>     BK
>
>
>     On Wed, Oct 20, 2010 at 1:18 PM, Chris Evans
>     <scarybeasts () gmail com <mailto:scarybeasts () gmail com>> wrote:
>
>         On Wed, Oct 20, 2010 at 8:58 AM, Michal Zalewski
>         <lcamtuf () coredump cx <mailto:lcamtuf () coredump cx>> wrote:
>
>             > Security-Assessment.com follows responsible disclosure
>             > and promptly contacted Oracle after discovering
>             > the issue. Oracle was contacted on August 1,
>             > 2010.
>
>             My understanding is that Stefano Di Paola of Minded
>             Security reported
>             this back in April; and further, the feature was a part of
>             reasonably
>             well-documented functionality of Java pretty much ever since:
>
>             http://download.oracle.com/javase/6/docs/api/java/net/URL.html
>
>
>         The Host: header trick was also used back in 2008 in Billy
>         Rios' GIFAR attack -- to get around the fact that Picasa hosts
>         images on a separate domain:
>
>         http://xs-sniper.com/blog/2008/12/17/sun-fixes-gifars/
>
>         The blog post title was "SUN Fixes GIFARs", although it's not
>         immediately obvious to me what was changed or fixed.
>
>         If anyone knows what was changed back then and/or in this
>         latest release, it would be interesting to see it documented.
>
>
>         Cheers
>         Chris
>          
>
>
>
>             "Two hosts are considered equivalent if both host names can be
>             resolved into the same IP addresses"
>
>             This was a pretty horrible design, so it's good to see it
>             gone, though.
>
>             /mz
>
>             _______________________________________________
>             Full-Disclosure - We believe in it.
>             Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>             Hosted and sponsored by Secunia - http://secunia.com/

-- 
Roberto Suggi Liverani
Senior Security Consultant
Mob. +64 21 928 780
www.security-assessment.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/