SecOutreachy

From MozillaWiki
Jump to: navigation, search

Yes! You made it to the wiki page describing how to start contributing to the Outreachy project Security audit of Firefox code.

There are two types of tasks you can perform to demonstrate your interest in the project and your ability to get involved in security engineering.

Don't hesitate to get in touch if you have any question, either by email at arroway@mozilla.com, or on IRC: this page shows you how to connect, and you'll find me on the #contentsecurity channel, under the nickname arroway.

1. Do the first steps of a security review for a 3rd party library used in Firefox

1. Select a library to look at in the following list: https://public.etherpad-mozilla.org/p/libs_list

If everything happens to be assigned already, contact me and I will update it with new items or re-check the page a bit later.

2. Do an overview of the security state of the lib

  • Impact
    • What does the lib do?
    • Which platforms is it on?
    • Can it be disabled by a pref?
    • Does it have telemetry?
  • Security practices
    • Do they acknowledge security bugs in changelog/releases?
    • Is there a bugtracker? Any open issues related to security?
    • Is anyone else than Mozilla fuzzing?
    • Identify areas to look at in priority because security impact of a vulnerability would be high

3. Submit your work for review: send me your review notes at arroway@mozilla.com, and we will talk together about your findings.


2. Document the history of programming practices who lead to security issues and how to fix them

Firefox has a list of security vulnerabilities which have been fixed over the years. The idea is to identify and document programming patterns which lead to security isues and show them to developers. You can look at this page as a source of inspiration: https://software.intel.com/en-us/articles/the-ultimate-question-of-programming-refactoring-and-everything

1. Find a bug with a review+ patch which landed.

2. Figure out what the security issue was.

3. Understand how it was fixed.

4. Is it a problem that could happen again in a different configuration?

5. If , document what a good practice to help developers understand and avoid hitting this issue in their code.

6. Submit your work for review: send me an email with your notes at arroway@mozilla.com, and we will talk together abour your findings.