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/
Current thread:
- Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass Roberto Suggi Liverani (Oct 20)
- Re: Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass Stefano Di Paola (Oct 21)
- <Possible follow-ups>
- Re: Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass Michal Zalewski (Oct 20)
- Re: Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass Dan Kaminsky (Oct 20)
- Re: Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass Chris Evans (Oct 20)
- Re: Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass Billy Rios (Oct 21)
- Re: Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass Chris Evans (Oct 20)
- Re: Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass Roberto Suggi Liverani (Oct 20)
- Re: Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass Roberto Suggi Liverani (Oct 20)
- Re: Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass Early Warning (Oct 21)
- Re: Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass Stefano Di Paola (Oct 21)