Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass
From: Roberto Suggi Liverani <roberto.suggi () security-assessment com>
Date: Thu, 21 Oct 2010 12:55:17 +1300

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/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]