LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityA trojan in a Firefox security add-onThere is an impressive list of Firefox security add-ons that makes up the Web Application Security Penetration Testing collection. It contains many of the most well-known addons (Firebug, Greasemonkey, etc.) along with a whole raft of lesser-known, but still useful add-ons—83 add-ons in all. Folks who install from the collection probably weren't expecting that it might also contain a trojan horse in the form of a password logger, but that's just what the "Mozilla Sniffer" add-on did, as Netcraft recently reported. The add-on in question was marked as "experimental", which means that it had not undergone the code review that add-ons get before turning off the experimental flag. That flag should make users more wary about installing those add-ons, but since it came from the Mozilla web site, and was listed in the collection, it's not hard to see how users, even seemingly security-conscious ones, might get fooled into installing it. The malware author did try to misdirect users by stating that "the addon was validated by MOZILLA validation", but the download page clearly indicated that it had not been reviewed. In any case, some 1800 users downloaded it, and it was in daily use by 334 at the time it was discovered to be a trojan. So, what did Mozilla Sniffer do? It didn't only "view and modify HTTP/HTTPS headers" as it claimed, but also checked each form that was submitted to see if there were password fields in the form. If so, it sent the form data, which would include the username and password, and the form destination URL off to a server that was presumably under the malware author's control. Essentially all credentials that were used while the add-on was installed were logged for whatever, undoubtedly nefarious, plan the attacker had. Mozilla Sniffer was uploaded to addons.mozilla.org on June 6, but its trojan nature was not discovered until July 12. Johann-Peter Hartmann had installed some add-ons from the collection to do some security testing of an online game when he noticed a strange HTTP request being made when he logged into the game. Noticing that it sent the credentials and URL to some IP address he didn't recognize, he started to dig deeper. Hartmann realized that one of the recently installed add-ons was likely to blame, so he started poking around in the source code for those, looking for the destination URL for the unexpected HTTP request. He found it in the popular (and reviewed by Mozilla) Tamper Data add-on, which was rather surprising. It turns out that Mozilla Sniffer had used Tamper Data's universally unique identifier (UUID) so it was able to overwrite the data in the Tamper Data directory—in effect masquerading as that add-on. The add-on was quickly removed once Hartmann reported it to security@mozilla.org. Mozilla also put out a security announcement on the add-ons blog, but for a substantial number of users, the damage was already done. Mozilla Sniffer was added to Mozilla's add-on blocklist, which will cause users to be prompted to uninstall the add-on. That should remove the problem going forward, but it is likely that some credentials were sent off to the author's site so affected users should probably change any passwords they used after installing Mozilla Sniffer. Mozilla is currently working on a proposal to change the add-on review process so that unreviewed add-ons are not available from addons.mozilla.org:
Having unreviewed add-ons exposed to the public, even with low visibility,
has been previously identified as an attack vector for hackers. For this
reason, we're already working on implementing a new security model for
addons.mozilla.org that will require all add-ons to be code-reviewed before
they are discoverable in the site.
The new review process would essentially require all add-ons to get at least a preliminary, cursory code review for malicious code before it could appear on the site. Add-ons that had not passed that initial review would not appear when users searched or browsed add-ons. That would remove the implicit—though clearly disclaimed—Mozilla "stamp of approval" for unreviewed add-ons. Even those that pass the preliminary review will still be marked as "unverified" and be subject to a number of limitations (lowered search ranking, click-through warning on install, etc.). The preliminary review is meant to get the add-on out in front of users fairly quickly so that developers can get feedback before requesting a full review. The full review will take longer, but passing it will give the add-on full privileges at the Mozilla add-on site. While it is rather ugly for the users affected, the effects of the attack were not all bad. It should help lead to better procedures for reviewing add-ons as well as making it clearer what the limitations of the current review process are. The attack itself wasn't terribly sophisticated, so it would presumably have been detected immediately if a review had been requested. A more subtle attack, that might remain undetected even with a full review, would be much more dangerous. In the end, installing an add-on requires some level of trust in the author. Reviewers can make mistakes, as can automated review tools. Since Mozilla does not do any vetting of the add-on authors, it would seem possible, likely even, that some day a determined attacker will slip something through Mozilla's review process. That will be a really bad day.
Brief items Quote of the week
Presumably if you are submitting to talk at a hacker con, you're familiar
with how this goes - talk about something awesome, do live demos, pop shells,
drop zero day and you'll be sweet. No vendor shillin', no whitehat illin',
and we're all sick of hearing about google hacking and PCI compliance.
No extra points for unix beards, apple ][ era tattoos or other ostentatious
nerd-uppery.
-- Kiwicon IV CFP
Adamski: Contextual IdentityMozilla's Director of Security Engineering, Lucas Adamski, looks at privacy, identity, and security on his blog. "So maybe its not a surprise that many social networks have ended up with privacy egg in their face. Part of the problem is that by presuming that users should have only a single, canonical identity on their network (and indeed, often the entire web), they lack the flexibility for individuals to express their various identities appropriately in different contexts."
Refresh of the Mozilla Security Bug Bounty ProgramThe Mozilla Security Blog has announced a refresh of the Mozilla security bug bounty. The amount awarded for bugs has gone from $500 to $3000, and bugs for Firefox Mobile and Mozilla services are explicitly included, along with other changes. "In concert with those changes, we are also updating the eligibility language to make it clear that Mozilla reserves the right to disqualify bugs from the bounty payment if the reporter has been deemed to have acted against the best interests of our users. To be very clear, we are not modifying our position regarding payment for publicly disclosed bugs; Mozilla bounty payments are not contingent upon confidential disclosure. While Mozilla strongly encourages researchers to disclose bugs to us privately (and most researchers have), we also believe that researchers should ultimately retain control over when and how the details of their research are disclosed."
Google: Rebooting responsible disclosureThe Google security blog is carrying a manifesto of sorts on how disclosure of security holes should be handled. "So, is the current take on responsible disclosure working to best protect end users in 2010? Not in all cases, no. The emotionally loaded name suggests that it is the most responsible way to conduct vulnerability research - but if we define being responsible as doing whatever it best takes to make end users safer, we will find a disconnect. Weve seen an increase in vendors invoking the principles of 'responsible' disclosure to delay fixing vulnerabilities indefinitely, sometimes for years; in that timeframe, these flaws are often rediscovered and used by rogue parties using the same tools and methodologies used by ethical researchers. The important implication of referring to this process as 'responsible' is that researchers who do not comply are seen as behaving improperly. However, the inverse situation is often true: it can be irresponsible to permit a flaw to remain live for such an extended period of time."
New vulnerabilities firefox et al: multiple vulnerabilities
freetype: multiple vulnerabilities
mlmmj: directory traversal
mozilla products: server spoofing
openldap: denial of service
openoffice.org: Python macro security bypass
pcsc-lite: privilege escalation
thunderbird: code execution
thunderbird: information disclosure
vte: arbitrary code execution
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||