Weekly Edition
Return to the Security page
| |||||||||||
Mozilla ships a compromised extension
From the Mozilla security blog: "The Vietnamese language pack for Firefox 2 contains inserted code to load remote content. This code is the result of a virus infection, but does not contain the virus itself. This usually results in the user seeing unwanted ads, but may be used for more malicious actions.
Everyone who downloaded the most recent Vietnamese language pack since February 18, 2008 got an infected copy." Presumably this is only an issue for Windows users, but it is still scary. More information can be found in bugzilla.
(Log in to post comments)
Mozilla ships a compromised extension Posted May 8, 2008 8:50 UTC (Thu) by thumperward (guest, #34368) [Link] It's not only an issue for Windows users. The compromise is the addition of a <script> tag at the bottom of one of the xhtml files in the language pack, so it affects any instance of Firefox where Javascript is enabled. - Chris
This mirrors Microsofts shipping of Nimda to Korea Posted May 8, 2008 11:29 UTC (Thu) by NZheretic (guest, #409) [Link] 17 June 2002 : Microsoft accidentally ships Nimda in KoreaMicrosoft has confirmed that it accidentally distributed to developers a copy of the W32/Nimda virus in Korean versions of its Visual Studio.net package Maybe the Mozilla project should to look into setting up and using a trust-able build service for all packages that contain either executable binaries or un-restricted scripting. See step 12 Trusted Build Agent (TBA) in Twelve Step TrustABLE IT.
This mirrors Microsofts shipping of Nimda to Korea Posted May 8, 2008 18:27 UTC (Thu) by proski (subscriber, #104) [Link] I believe Trusted Build Agent would not help. The corrupted files were help files in HTML format. It's possible to generate such files from some other format, but I think it would be a major overkill to change the build system to prevent such incidents. Viruses can still damage something, maybe even patch Mozilla source code. What matters is keeping committers' systems secure.
This mirrors Microsofts shipping of Nimda to Korea Posted May 9, 2008 12:09 UTC (Fri) by thumperward (guest, #34368) [Link]
Furthermore, as described in the bug (never thought lwn was going to succumb to rtfa
syndrome...) it wasn't the virus itself which was distributed, but fallout from the virus on
the machine of the developer who originally uploaded the language pack, in the form of an
advert-generating Javascript include. Code review would have caught this ("what does that
script tag at the bottom do?") but as it's essentially an arbitrary change to the source
detection in a generic way isn't just a case of running a virus scanner.
- Chris
This mirrors Microsofts shipping of Nimda to Korea Posted May 10, 2008 15:18 UTC (Sat) by dvdeug (subscriber, #10998) [Link] The right scan could get this. For one thing, if there's not supposed to be Javascript in the files, a sweep for script tags would get it. Even if there is, it's likely checkable that the only script tags are the ones that are supposed to be there.
Scan would have prevented this Posted May 15, 2008 1:51 UTC (Thu) by dwheeler (subscriber, #1216) [Link] Actually, language packs are only supposed to have a VERY limited set of constructs, and that is already documented in the Mozilla information. The problem is that currently there's no automated chack for this currently (this is a known bug, and hopefully this will spur quick repair of this).Human review would ALSO have dealt with this, but language packs are unique among OSS packages: Most developers CANNOT understand the contents of most language packs, because they're specific to a language. This is actually an interesting exploit to counter the OSS "mass review" - pick a component that CANNOT be reviewed by nearly everyone. Thankfully, the solution is obvious too... for language packs, permit only a very few (secure) constructs and forbid the rest.
|
|||||||||||