Speeding Up Security Reviews

Posted by yboily

0

At Mozilla we have a strong commitment to security; unfortunately due to the volume of work underway at Mozilla we sometimes have a bit of a backlog in getting security reviews done.

Want to speed up your security review request?  You can dramatically increase the turn around time for your security review request by providing the information below.  In addition to this, we are working to expand our overall security review process documentation; you can follow those efforts here.

1. Architecture Diagram

An architecture diagram illustrates how the various components of the service communicate with one another.  This information allows the individual doing the security review to understand which services are required, how and where data is stored, and provides a general understanding of how the application or service works.  Producing an architecture diagram is a good practice as it allows anyone to get a rapid view of how complex a system is, and can inform how much time it will take to work through a review of the system.

Legacy F1 Service Architecture

Examples

Note that these are just examples; the architecture diagram is intended to help the reviewer visualize what they are assessing.  It doesn’t have to be a fancy diagram, and our team has worked from camera shots of whiteboards from meetings!

Marketplace Architecture

2. Detailed Application Diagram

A Detailed Application Diagram is essentially a Dataflow diagram;  a data flow diagram enumerates each application or service that is a component of a system, and provides a list of the paths that data can flow through.  A dataflow diagram helps the security reviewer to understand how data moves through the system, how different operations are performed, and if detailed enough, how different roles within the system access different operations.

While there are a number of different opinions on the “best way” to do a DFD, it is more helpful to have the information than it is to focus on presenting the information “the right way”.

Examples

3. Data flow enumeration

An enumeration of data flows in the application explains how and what data moves between various components.  Note that this doesn’t need to be a rigorous explanation of fields; in this case we want a general description of the message, the origin of the message (browser, third party, service, database, etc), the general contents (e.g. “description of the add-on”, “content to be shared”, etc), and a list of sensitive fields.

Examples

4. Threat Analysis

The next step is reviewing all of this information to build out a list of the threats to an application.  The important bit here is that you, as a developer or contributor, know how an application or system works.  You know what a good set of the failure modes of the application are, and you understand the ‘business logic’ of the application.  Many developers have a working knowledge of vulnerabilities, and can identify these types of issues.
In order to properly perform a threat analysis a reviewer needs to understand how the various components of the system work, what threats exist, and be able to identify what mitigating controls have been put into place.
Here is an example of what a threat analysis might look like (links below):
The threat analysis should contain, at a minimum the following information:
  • ID – a identifier for the threat
  • Title – a concise description of the threat
  • Threat – a description of the threat
  • Mitigations – a recommendation for a control that can be implemented
  • Threat Agent – a list of the potential actors considered that would exploit a vulnerability
  • Notes – Related comments that contribute to the analysis, but don’t belong in other columns
  • Rating – A qualitative scoring for a vulnerability in the context of this application
  • Impact – A qualitative score representing the impact should a vulnerability be exploited
  • Likelihood – A qualitative score representing the likelihood of a vulnerability being exploited

Additional information on how we assess and rate threats will be published as part of the documentation for our risk rating and security review processes.

Examples

Help us help you!

Part of determining the scope of a security review is understanding how an application works and what the risks are; the documentation described in this post helps us to understand this and will ensure that we can complete a security review as quickly as possible.  Beyond that, as teams understand how security reviews are performed it gives them the opportunity to take ownership of security and build it more effectively into their own processes.

As with other Mozilla teams we are actively pursuing better community engagement and always welcome feedback.

 

Why an outdated Java Plugin is so serious

Posted by decoder

14

Recently, Mozilla responded to an imminent threat to Firefox users who have an outdated Java plugin installed: Vulnerable versions of the plugin were blocked automatically (see blog post). Since then, I’ve been asked a few times why this is important; others have complained that their <any large number> corporate/government installations don’t work anymore because they depend on an outdated Java version (note that some of these problems/complaints were probably caused by a bug in the initial deployment of the blocklisting entry itself that is now fixed). While we all understand that an operational Java Plugin is absolutely crucial for some users, I’d like to emphasize how critical the situation requiring the block is by providing more details concerning this incident and why it is indeed more serious than some people might think.

What’s wrong with the blocked version of Java?

With the most recent Java update, Oracle fixed quite a few security vulnerabilities (see advisory page), including a vulnerability listed as CVE-2012-0507. Up to this point, this isn’t really unusual, as most of these updates fix one or more security problems.

However, not even 6 weeks after the release of the Java update, the Microsoft Malware Protection Center received malware samples that exploit the specified vulnerability in a very reliable way and use it to install a well known trojan, called the ZeuS bot. There was now evidence that the vulnerability was not just theoretical, and had become a practical avenue to infect machines with malware. You can read the full blog post from Microsoft here (this is a technical post, so it’s likely only interesting to you if you have a technical background).

“I’m not getting attacked anyway”

Shortly after the Microsoft post, Brian Krebs published a blog post on the topic, stating that the exploit is now being integrated into well known exploit kits, e.g. the Blackhole exploit kit. These kits can be purchased on the black market and are usually integrated invisibly into hacked websites or indirectly served on websites through hacked content providers (imagine the number of vulnerable users you can reach when you break into an advertisement server and include your malware into banners served to other sites). With this step, the threat became more serious: Unless you just don’t browse the Internet at all, the risk of getting infected is very real. Of course there might be a minority of users that only ever browses a corporate intranet which will mitigate the risk, but this isn’t really the common use case for a web browser. If a user absolutely needs the older, vulnerable version of Java, they can still bypass the warning.

“I have a Mac, I’m safe”

While this might have been true at some point in the past, the threat landscape for Mac/OS X has changed quite a bit in the last few years. As the popularity of the Mac platform has grown so has its attactiveness as a target for attackers. Only a few days ago, F-Secure announced that the Flashback trojan, a well known piece of Mac malware, is now exploiting the very same vulnerability we’ve been discussing so far. You can read the post here to get all the technical details about it. According to recent reports, the number of infected Mac/OS X machines recently grew rapidly over half a million and is still growing. As such the threat to Mac users is evident and imminent, thus prompting our response on all platforms. Note that Apple has recently released a Java update as well that addresses this vulnerability.

Summary

In reviewing the actions and threats for this Java vulnerability, or, for that matter, any security issue, we take the balance of security vs. usability very seriously. This situation is an instance where we felt the balance had tipped towards taking a security action that has a minor adverse affect to the user community as a whole. The desired goal is to protect our users, to encourage them to upgrade to more recent, secure versions of plug-ins and to maintain our history of thoughtful security action.

Acknowledgements

Thanks to the various people involved in getting the proper blocks in place so quickly, that was an amazing job. Thanks also to Curtis Koenig, Dan Veditz and Ian Melven for reviewing/editing this post :)

Make Things Better (or, how I learned to stop worrying and love security again)

Posted by mgoodwin

3

Working in application security can be frustrating. Often you’re working around problems in software you have little control over, making ugly bandaids that must stay in place until a vendor wakes up to an issue.

Perhaps this is why security folk, as a community, have gotten into the habit of complaining about how things are broken and leaving it there; how often have you attended a presentation where a vendor is criticised for making a mistake, but no solution is suggested, or help offered?

This frustration is one of the reasons I was really excited about coming to Mozilla. “Finally! I can make a difference!”, I thought. It didn’t take long for me to realise I’d missed something important; there was nothing stopping me before. You don’t need to be a Mozilla employee to contribute.

Why?

Because Mozilla is open. Not ‘open’ as in “here’s this neat thing we built behind closed doors (and here’s the source)”, rather, the kind of open that allows anyone with good ideas and talent to make a difference. We develop everything in the open so you can contribute ideas, patches and security guidance too.

I didn’t realise that I could contribute in all of these ways; had it occurred to me, some of the things I’m working on now could have been in the browser I used years ago. Has it occurred to you?

So what can you do?

We’re going to be giving some additional ideas of areas where you can get involved over the coming weeks; watch this space!

– Mark Goodwin
Twitter: @mr_goodwin

ADBFuzz – A Fuzz Testing Harness for Firefox Mobile

Posted by decoder

Fuzz testing (automated, random testing) is an important part of nearly every application security life cycle. While there are a lot of tools, frameworks and harnesses available for regular desktop platforms/operating systems, there’s still a lot missing in the mobile sector which is becoming increasingly important.

In this article, I will describe the necessary implementation steps for a mobile fuzzing harness and provide a proof-of-concept implementation called ADBFuzz that allows anyone to run fuzzers written in Javascript in Firefox Mobile on Android. In the near future, we will also likely release internal fuzzers that can be used with this harness. Continue reading …

Update on Address Sanitizer

Posted by decoder

1

In a previous blog post, I outlined how the memory error detection tool Address Sanitizier (ASan) can be used with Firefox to find memory problems with a high degree of performance and how it can even detect certain errors that conventional tools missed.

While it was very complex to build Firefox with ASan support in the past, we now provide a much easier way (achieved by landing bug 727445). One of the most important changes is that from now on, no patching of Clang/LLVM is required anymore. Secondly, no further patches to Firefox are required for building, only a custom build configuration must be used. The build manual has been updated accordingly to reflect these changes. We hope that this encourages more people to try this tool and help us to improve Firefox.

- Christian Holler
Security Engineer

Brenda Larcom presentation on Threat Modeling Using Trike

Posted by abillings

On Monday, February 27, security researcher Brenda Larcom came to Mozilla to present on security threat modeling. This was a discussion on the Trike methodology for threat modeling that she and others have been developing over the last nine years.

Threat modeling is heavily used by the Mozilla Security team in order to analyze potential threats and weaknesses in Firefox and also our other systems, such as addons.mozilla.org, browserID, etc. This allows us to address potential security issues or weaknesses as we develop new features and systems at Mozilla. Trike’s goal is automate the repetitive parts of threat modeling to make it more efficient and effective. It also has the benefit of producing testcases that can be used as the basis of repeatable, automated testing.

You can read more about Trike on their site, octotrike.org or you can watch Brenda’s presentation, as it was recorded and broadcast on Air Mozilla.

- Al Billings
Security Program Manager

Mozilla at the University of Warwick

Posted by mgoodwin

On Tuesday 28th February, Mark Goodwin from Mozilla’s Application Security team will be presenting a guest lecture at the University of Warwick.

This session will introduce students to web security and equip them with the skills to identify, resolve and prevent common web vulnerabilities

The talk will not be recorded, although slides and notes will be made available sometime afterwards.

-Mark Goodwin
Application Security

Mozilla Security Changes

Posted by Curtis

We’ve decided to reorganize our security teams and as part of the change we are going to be using this blog in some new ways.

The most notable change is this blog will now host posts on a variety of topics including product security, application security and network/server security. We merged the work of our platform, web application and infrastructure security teams to form the Security Assurance team. This team will continue the work of verifying and guiding the best possible security practices across three spaces and combine some duplicate effort. Complementing this, our Security Engineering team will focus on creating and shepherding new security and privacy features into our products following the roadmaps at https://wiki.mozilla.org/Security/Roadmap and https://wiki.mozilla.org/Privacy/Roadmap

Traditionally this space has been used to announce security incidents and their impact, major changes to security process and security update information. In addition to that content, this space will also host posts about the different projects and features team members are working on, including topics in web security and fuzzing. We also want to share our perspectives on security related developments in the community, as well as insights into security conferences and ideas.

To make the transition easier for our readers, who may not want to read all of our posts, we will be using categories for our posts so you can filter what interests you. In particular, we will make use of tags such as “Announcements”, “Security Updates” and “Vulnerabilities” to cover posts that detail information required to stay on top of Mozilla product security notifications.

We are very excited to share more with our community and have a broader conversation with regards to security and we hope that you feel the same way and engage with us in the comments of this blog.

-Curtis Koenig
Security Program Manager

*edit: minor change to first line, second paragraph

Message to Certificate Authorities about Subordinate CAs

Posted by Johnathan Nightingale

12

Earlier today we sent an email to all certificate authorities in the Mozilla root program to clarify our expectations around certificate issuance. In particular, we made it clear that the issuance of subordinate CA certificates for the purposes of SSL man-in-the-middle interception or traffic management is unacceptable. We made it clear that this practice remains unacceptable even when the intended deployment of such a certificate is restricted to a closed network.

In addition to this clarification, we have made several requests. We have requested that any such certificates be revoked, and their HSMs destroyed. We have requested the serial numbers of those certificates and fingerprints of their signing roots so that we, and other relying parties, can detect and distrust these subCA certificates if encountered. We have requested that any CAs who have issued subCA certificates fulfill these requests no later than April 27, 2012.

Finally, we re-iterated our belief that each root is ultimately accountable for every certificate it signs, directly or through its subordinates. Participation in Mozilla’s root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe, up to and including the removal of root certificates that mis-issue, as well as any roots that cross-sign them. Nevertheless, we believe that security is best served when browsers and CAs can work together; we hope that frank communication and clear expectations can resolve these issues before any such action is required. We must also be diligent in looking for new ways to improve the security systems of the web. Those systems are built on the trust of web users, and we all have a responsibility to be strong stewards of that trust.

Johnathan Nightingale
Senior Director of Firefox Engineering