01.27.11 - 06:13pm
It has been just over a month since we announced the expansion of our bounty program to include selected web applications. We have received many bug reports and have awarded $40,000. We will make the resolved bugs public shortly as these issues are no longer a threat to the community and our users.
Since the announcement of the web bounty program, we have received many security bug reports for sites outside of the bounty. We want to reiterate the eligible sites and applications for the bounty.
- addons.mozilla.org
- aus*.mozilla.org
- bugzilla.mozilla.org
- download.mozilla.org
- getpersonas.com
- pfs.mozilla.org
- services.addons.mozilla.org
- versioncheck.addons.mozilla.org
- www.mozilla.com/org
- www.firefox.com
- www.getfirefox.com
- *.services.mozilla.com
We want to focus our attention on security issues that protect Firefox users. We excluded other sites for various reasons, including: we plan on replacing them, or we have put these systems in a read only state to lessen their impact. Further details can be found on the Web Security Bounty FAQ, which should be reviewed before submitting a web bounty bug.
Thanks to all the bug submitters for their contributions; the program has been a great success. Beyond the monetary rewards, we sent Mozilla T-shirts to an additional 23 people who submitted security bugs that did not qualify for the web bug bounty. We are in the process of triage for the next round of payments and more should be going out soon.
Chris Lyon
Director of Infrastructure Security
Category: Security | Tags: Web-Bounty, Web-Security | 4 Comments »
12.27.10 - 10:35pm
On December 17th, Mozilla was notified by a security researcher that a partial database of addons.mozilla.org user accounts was mistakenly left on a Mozilla public server. The security researcher reported the issue to us via our web bounty program. We were able to account for every download of the database. This issue posed minimal risk to users, however as a precaution we felt we should disclose this issue to people affected and err on the side of disclosure.
The database included 44,000 inactive accounts using older, md5-based password hashes. We erased all the md5-passwords, rendering the accounts disabled. All current addons.mozilla.org accounts use a more secure SHA-512 password hash with per-user salts. SHA-512 and per user salts has been the standard storage method of password hashes for all active users since April 9th, 2009.
It is important to note that current addons.mozilla.org users and accounts are not at risk. Additionally, this incident did not impact any of Mozilla’s infrastructure. This information was also sent to impacted users by email on December 27th.
Chris Lyon
Director of Infrastructure Security
Category: Security | | 19 Comments »
12.14.10 - 02:57pm
Many people are not aware that we have paid a bounty in the past on web application security vulnerabilities which impact client security. We have only paid on critical or extraordinary web application vulnerabilities which have a direct impact against the client. We are now going to include critical and high severity web application vulnerabilities on selected sites. We are giving a range starting at $500 (US) for high severity and, in some cases, may pay up to $3000 (US) for extraordinary or critical vulnerabilities.
We want to encourage the discovery of security issues within our web applications with the goal of keeping our users safe. We also want to reward security researchers for their efforts with the hope of furthering constructive security research.
This new policy will go into effect starting December 15th, 2010 PST, and any new web application bugs will fall under this new policy. It is important to note that nothing else has changed with the original security bounty program and the updated amount which was announced back in July.
The Web Security Bounty FAQ includes which types of vulnerabilities will be considered and which sites will be considered to be apart of the Web Application Bounty Program.
The full text of the security bounty program:
http://www.mozilla.org/security/bug-bounty.html
Chris Lyon
Director of Infrastructure Security
Category: Security | Tags: Security, Web-Security | 6 Comments »
10.27.10 - 10:30am
There have been a number of reports about a new Firesheep tool that exposes a weakness in website security, letting attackers snoop on people using public networks, steal their cookies, access their accounts and pose as them on sites such as Facebook and Twitter. While the developers chose to use the Firefox add-on API, the tool could have just as easily been written and distributed as a stand-alone program.
The introduction of this tool reinforces the importance of websites configuring themselves to require secure connections.
Not too long ago we announced HTTP Strict-Transport-Security that can be used to — among other things — ensure your Facebook or Twitter cookies can’t be sniffed by someone using a tool like Firesheep. In fact, it’s built into Firefox 4. To protect their users from the this attack, a site simply needs to set the Strict-Transport-Security HTTP header when they serve you a secure log-in page, and make the rest of their site available over HTTPS. Firefox will take care of the rest: automatically fetching that site over a secure connection and blocking any third parties from seeing the unencrypted traffic.
We recommend that website authors make use of this header in order to protect their users.
But this technology is new to Firefox 4. To get HTTP Strict-Transport-Security support in Firefox 3.6, you will need to install an add-on that implements it such as ForceTLS. ForceTLS also gives you a way to opt-in to this extra security for sites who haven’t yet started sending that helpful HTTP header; it provides a user interface to add and remove sites that should never be contacted insecurely. Both HSTS and the manual opt-in are also available as part of NoScript. However, manually opting-in to HSTS on a site which does not yet make itself fully available securely may break the site; not all sites are ready for secure access.
If you are already using Firefox 4 beta or nightly versions, you can enable the additional controls with the STS-UI add-on. While the core Strict-Transport-Security features are already built into Firefox 4, this UI gives advanced users the ability to further ensure the security of their connections.
Sid Stamm
Conspiracy Theorist
Category: Firefox, Security | Tags: Firefox, HSTS, https, Security, strict-transport-security | 18 Comments »
10.26.10 - 02:30pm
Update (Oct 27, 2010 @ 20:12):
A fix for this vulnerability has been released for Firefox and Thunderbird users.
Firefox 3.6.12 and 3.5.15 security updates now available
Thunderbird 3.1.6 and 3.0.10 security updates now available
Issue:
Mozilla is aware of a critical vulnerability affecting Firefox 3.5 and Firefox 3.6 users. We have received reports from several security research firms that exploit code leveraging this vulnerability has been detected in the wild.
Impact to users:
Users who visited an infected site could have been affected by the malware through the vulnerability. The trojan was initially reported as live on the Nobel Peace Prize site, and that specific site is now being blocked by Firefox’s built-in malware protection. However, the exploit code could still be live on other websites.
Status:
We have diagnosed the issue and are currently developing a fix, which will be pushed out to Firefox users as soon as the fix has been properly tested.
In the meantime, users can protect themselves by doing either of the following:
Credit:
Morten Kråkvik of Telenor SOC
—
Brandon Sterne
Man-in-the-middle
Category: Security, Vulnerabilities | | 33 Comments »
09.08.10 - 02:56pm
One of the security enhancements included with Firefox 3.6.9 is support for the x-frame-options header. This optional header can be included within the HTTP response to instruct the client’s browser on whether the returned content is allowed to be framed by other pages.
A website can choose to include the x-frame-options header to protect against malicious framing of web content by third parties. For example a malicious site might frame a website from another domain and surround the framed site with advertisements. Alternatively, a malicious site could use a CSS layer attack called ClickJacking to trick users into performing unintended actions within the framed website that is obscured by overlaid CSS layers.
The x-frame-options header supports the following values:
SAMEORIGIN – allows only sites from the same domain to frame the page
DENY – prevents any site from framing the page
Additional Reading:
Mozilla Developer Network article
Microsoft Developer Network article
OWASP Clickjacking Article
Michael Coates
Web Security
Category: Firefox, Security | Tags: clickjacking, Firefox, Security | 4 Comments »
08.27.10 - 10:16am
A while ago, we talked about Force-TLS that lets sites say “hey, only access me over HTTPS in the future” and the browser listens. Well, this idea has been solidifed into a draft spec for HTTP Strict Transport Security (HSTS) and we’ve landed support for it into our source tree. This means that HSTS will be shipped with Firefox 4, and will be deployed as soon as the next beta release.
We’re excited about this because it enables sites to easily give their users lots more protection from man-in-the-middle attacks when they’re using an untrustworthy network.
Grab a nightly build, and let us know what you think! The folks over at PayPal are serving a Strict-Transport-Security header, if you’d like to check it out.
More Info:
Sid Stamm
Conspiracy Theorist
Category: Firefox, Security | | 4 Comments »
08.23.10 - 05:19pm
Zack Weinberg did a great blog post explaining the recent changes in Firefox 3.5.11 and 3.6.7 to mitigate cross-site data theft using CSS. This is a mitigation for an issue originally “rediscovered” by Chris Evans.
Category: Uncategorized | | Comments Off
08.17.10 - 03:39pm
Issue
There has been discussion today about a Firefox feature that warns users when a site’s URL is deceptive. When a Firefox user visits a site with a url that might be deceptive (e.g. http://www.good.com@evil.com/) , Firefox will stop the load and confirm with the user that they are really visiting the site they expected to visit (in this example, evil.com is the actual site loaded). The discussion today has identified the fact that this same warning is not presented when an iframe on the page attempts to load such a URL.
Impact to Users
This issue poses very low risk to users. This attack relies on user confusion about the true destination of a link, and only someone examining the HTML source of the page would ever see the deceptive URL. Most users do not view the source of loading pages, and are therefore unlikely to be impacted by this attack.
Status
We are aware of the discussion. There is currently no fix in plan since Mozilla does not believe this can be used to attack users. Firefox ships with built-in phishing and malware protection that warns users if they are attempting to visit a dangerous URL, and these attempts at deception do not impact that protection.
Credit
This bug was originally reported by Aditya K Sood.
Johnathan Nightingale
Director of Firefox Development
Category: Uncategorized | | 3 Comments »
07.16.10 - 12:32am
I’ve posted some of my recent thinking on privacy and identity. For some time we’ve generally seen privacy treated as its own problem domain, oddly divorced from the realms of security and identity. Perhaps its time for a different approach?
Category: Musings, Privacy, Security | | 2 Comments »
