Message-ID: <4CBF687C.7080800@security-assessment.com>
Date: Thu, 21 Oct 2010 11:09:00 +1300
From: Roberto Suggi Liverani <roberto.suggi@...urity-assessment.com>
To: Michal Zalewski <lcamtuf@...edump.cx>
Cc: "bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>,
	full-disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection
 class - Same-of-Origin (SOP) Policy Bypass

Hi Michael,
 
Let me share some background on this advisory...

I came to this result when I was looking into a way of exploiting the
Apache Web Server "Compatibility with older browser feature". A separate
paper has been published here:
 
http://www.security-assessment.com/files/whitepapers/Leveraging_XSRF_with_Apache_Web_Server_Compatibility_with_older_browser_feature_and_Java_Applet.pdf


Interestingly enough, I got the idea of using Java Applet to achieve the
attack described above after I bumped into the following from your
browser security handbook
(http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_Java): 


"The ability to send same-origin HTTP requests using the browser stack
via the URLConnection API, with virtually no security controls,
including the ability to set Host headers, or insert conflicting caching
directives. On the upside, it appears that there is no ability to read
30x redirect bodies or httponly cookies from within applets".
 
After that, I thought Java Applet could be quite handy when it comes to
force the browser performing a non-standard/malformed HTTP request (e.g.
multiple Host: headers which exploits the Apache feature mentioned above).
 
At the same time, I also realised that in my testing environment I was
using virtual hosts resolving to the same IP address. Following a
discussion with Apache Security Team and after further research, I have
found that the Java Applet could be used to control the cookie header
sent to a different domain...
 
But let's come back to your response - you mention about a bug from
Stefano but I am not aware if it is the same bug or a different one
though. When I contacted the vendor, they created a new ticket for the
bug and told me that it would have been fixed with the next critical
patch release in October 2010. They haven't mentioned about anyone with
an identical bug was already reported, as they normally do when
cross-referring bug reports. Apologies in advance if this is a bug
Stefano or someone else reported before August the 1st .
 
Furthermore, my testing was performed on the latest version JRE (build
1.6.0_21-b07) so I assumed (wrongly?) that all previous critical bugs
were fixed.
 
The main issue reported is related to the getRequestProperty('cookie')
property which can be controlled by a Java Applet. This could lead to
leaking cookie to unauthorised domains given the attack is performed
between domains that resolve to the same IP address.
 
The fix provided by Oracle is that getRequestProperty('cookie') now
returns a 'Null' value and cannot be any more controlled via the Java
Applet, even if URLconnection class is used to performed a cross site
request between domains that resolve to the same IP address. The fix
effectively mitigates the attack shown in the PoC but does not resolve
the behavior you mention:
 
"Two hosts are considered equivalent if both host names can be resolved
into the same IP addresses"

Unfortunately, the above statement is still enforced in Java Applet as
the URLConnection class can be used to make a request between two
domains that resolve to the same IP address without  a crossdomain.xml
policy.

In my advisory, I stated: "The Java Applet bypasses the Same-of-Origin
policy (SOP) as an unsigned Java Applet should not be able to
communicate from www.badsite.com to www.targetsite.net without a
crossdomain.xml".
 
According to the documentation/design, there is no SOP bypass as both
hosts are considered equivalent. However, in practice, there is a SOP
bypass, as cookie can leak to an unauthorised domain.
 
Hope this sheds some light on this research ;-). Apologies if I didn't
explain well enough the above in the original advisory.
 
Cheers,

Roberto

Michal Zalewski 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
>
> "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
>   

-- 
Roberto Suggi Liverani
Senior Security Consultant
Mob. +64 21 928 780
www.security-assessment.com

Powered by blists - more mailing lists