Winter Of Security 2016

The Winter of Security (MWOS) is a program organized by Mozilla's Security teams to involve students with Security projects. Students who have to perform a semester project as part of their university curriculum can apply to one of the MWOS project. Projects are guided by a Mozilla Adviser, and a University Professor. Students are graded by their University, based on success criteria identified at the beginning of the project. Mozilla Advisers allocate up to 2 hours each week to their students, typically on video-conference, to discuss progress and roadblocks.

Projects are focused on building security tools, and students are expected to write code which must be released as Open Source. Universities are free to specify their own requirements to projects, such as written reports. Mozilla does not influence the way grades are allocated, but advisers will provide any information professors need in order to grade their students.

Note on language: English is required for code comments and documentation, but not for interactions between students and advisers. Advisers who speak the same language as their students are encouraged to interact in that language.

Contact us on irc.mozilla.org in the #security channel if you have questions.

Selection process

Projects are assigned to groups of students. Groups are defined by the universities, and can be of any size between 1 and 4 students. The selection process is open to all students in undergraduate/license and graduate/master programs. A group applies to up to 3 projects by submitting an application that contains:

• the names of the projects the team is applying to
• team introduction and motivation (max 1000 characters)
• presentation of the university program (max 500 characters)
• short description of each team member (skills, interest, ...) (max 500 character for each team member)
• links to relevant resources (university website, resumes, ...)

Click here to access the application form

Timeline

We will be opening the program for applications on July 29th, closing the application process on September 15th, and announcing results on September 30th.

The students and their professor can decide on the timeline, and make sure that it fits well with other classes. Ideally, projects should not take more than 6 months from start to finish. Mozilla advisors will be available weekly on video (Vidyo, Google Hangout or Skype) to discuss progress and roadblocks, and provide help. Professors can set intermediary deadlines if needed, and have complete control over the grading of their students.

Projects

Important Note: Students should apply to one or more project they are interested in. Mentors will pick one team per project. Some projects may not be selected if the mentors consider applicants don't have the necessary skills, or if priority is given to other projects.

MIG: A web interface for Mozilla Investigator

• Mentors: Julien Vehent and Aaron Meihm

MIG is primarily a command line tool, but a web interface would be a nice addition for people who just want to visualize results. This project would require changes to the backend API of MIG to handle various permissions levels, as well as a good knowledge of javascript to write the frontend.

ZAP: Field Enumeration

• Mentors: Simon Bennetts

This would allow a user to iterate though a set of (user defined) characters in order to identify the ones that are filtered out and/or escaped. The user should be able to define the character sets to test and will probably need to configure the success and failure conditions, as well as valid values for other fields in the form.

ZAP: Form Handling

• Mentors: Simon Bennetts

The ZAP traditional and Ajax spiders explore an application by putting basic default values in all forms. These may often not be valid values, for example using "ZAP" when an email address is required. The enhancement would allow the user to define default values based on pattern matching against the field names and/or ids. It would also be very useful if it could show the user all forms and their associated fields for an application, and then allow the user to update the default values.

ZAP: Automated authentication detection and configuration

• Mentors: Simon Bennetts

ZAP has extensive support for supporting application authentication, but configuring this is a manual process which can be tricky to get right. The enhancement would allow ZAP to detect as many forms of authentication as possible and automatically configure them using the existing ZAP functionality.

Plug'n'hack / ringleader: Support for e10s (and more)

• Mentors: Mark Goodwin, Simon Bennetts

Plug'n'hack is a mechanism for configuring a browser profile to work with security tools. Ringleader is a firefox addon implementation of Plug'n'hack that makes it easy to configure Firefox. Since Ringleader was written, there have been major changes to Firefox (most notably, e10s) that prevent the addon from working. We'd like to fix this.

This project requires familiarity with JavaScript and, optionally, some knowledge of making browser extensions (ideally, firefox add-ons).

NSS: Demos

• Mentors: Franziskus Kiefer, Tim Taubert, JC Jones

Using the NSS library in your own project isn't the easiest job to do. In this project a suite of NSS demos should be compiled (ideally web executable using something like Runnable) as reference for developers that want to use the library.

NSS: Server integration

• Mentors:Franziskus Kiefer, Tim Taubert, JC Jones

The TLS stack in NSS provides basic support for TLS servers such as [1]. With this code being rarely used and tested it contains significant shortcomings. This project should identify those problems, fix them, and provide integration for all major HTTP server.

Details:

• An Apache module for NSS exists but lacks important features such as HTTP/2 support.
• NGINX lacks TLS module support entirely. We recently started a push to make it agnostic to the used TLS library. This works has to be continued and requires a new module for NSS.

This project is ideal for a self-motivated group that prefers an open project definition with lots of freedom to shape directions and outcome of it.

NSS: Blake2 Implementation

• Mentors: Franziskus Kiefer, Tim Taubert, JC Jones

SHA-3 is a new cryptographic hash functions. This project should provide basic SHA-3 support for NSS.

NSS: Formal Verification

• Mentors: Tim Taubert, Franziskus Kiefer, JC Jones

This project should formally verify implementations (or parts of) of e.g. ciphers, the TLS protocol, libmpi, libec in the NSS library.

NSS: TLS Interop

• Mentors: Tim Taubert, JC Jones, Franziskus Kiefer

This project should ensure NSS' TLS implementation interoperates with that of other crypto libraries like OpenSSL. It should also automate interoperability testing to integrate with our CI.

ssh_scan: Improving Scalability and Feature Set

• Mentors: Jonathan Claudius, pwnbus

This project would work on improving the scalability and feature set of ssh_scan, a tool for scanning for ssh policy and compliance (mainly attributes found here https://github.com/claudijd/ssh_scan/blob/master/examples/192.168.1.1.json). This tool is currently open-sourced as more of a prototype tool here (https://github.com/claudijd/ssh_scan). Current feature gaps include the ability to detect the types of authentication (password/key-based/auth), nmap-style targeting and scanning, and IPv6 support. Lastly, it might be useful to have some server-side infrastructure components/API developed for this service with a cool front end to assist with scanning/compliance automation. These are the sorts of things this project team would attempt to solve and deliver during the project window.

Security Testing Workflow and Toolchain for Python Websites and Services

• Mentors: Adam Muntner

Manual security reviews are time consuming, expensive, and important for the most critical websites and services. By documenting testing goals, trying to best approximate them, and measuring, we can create an efficient, reusable workflow with known properties and a plan to improve it in the future, a Maturity Model approach. The goal of this project is to use Maturity Model approach to create a reusable workflow and toolkit for manual "grey-box" security review of Python websites and services. We will create a maturity model that describes the target capabilities of an ideal reusable "grey box" workflow documentation and toolkit, test available tools, document what works and what's missing according to the Maturity Model, create a test environment that can be dropped in to an existing test environment such as a Docker and used with minimal configuration,and create a roadmap for future work. We will script integration of existing tools and methods to create a reusable test harness that reports testing coverage and supports remote debugging, automate setup to use an IDE to remote debug an application while testing it with Zap proxy, identify the best ways to test for Python-specific issues, make the IDE as tester-friendly as possible, use Python AST visualization to visualize security decisions in code, and making the toolkit as quick to deploy and use as possible, etc. We'll use the toolkit to evaluate complex real-world services like Mozilla Addons. Some preparatory work has already begun for this project, the MWOS goal is to move it to a point where it is a usable, ongoing project.

FAQ

What is meant by "Presentation of the University program" in the application form?

We would like to see what kind of degree you are currently pursuing (e.g. Bachelor of Science in Computer Science or Master of Science in IT Security, ..), as well as a description of the university itself. This is another data point that gives us more information about the applicants' chances to successfully complete a project.

Can students apply to multiple projects?

Yes. Students can apply to one or more projects. Students cannot apply twice for the same project, even if their team compositions varies.

What criteria will you use to select the candidates?

The skills and passion of the team members are key points. The size of the team may play in the favor of applicants, but is not a requirement. A single candidate who can show a portfolio of successful projects will have the same chances as larger teams. Commitment from the University is a strong requirement. Students need to demonstrate that their professors support them, and will give them time to work on the projects. The ideal situation is for a team to pick a MWoS project as their final thesis, and work on the project for a full semester. Not all students will be able to do so, and we will evaluate all applications with the same level of scrutiny.

Are multiple universities allowed to collaborate and have a single team?

Yes. We will ask that students mentored by multiple professors get approval from all of their professors.

Can I still work on Mozilla projects if I am not selected for MWoS?

Yes! We continuously have projects that are available for students to grab! Take a look at the Mentorship program, and reach out to us in the #security IRC channel if you are interested.

Project pages

"showparent=no" has no sub pages.

Media

All media files are available under license MPLv2 and can be reused freely.