This mirrors Microsofts shipping of Nimda to Korea [LWN.net]

This mirrors Microsofts shipping of Nimda to Korea

Posted May 8, 2008 18:27 UTC (Thu) by proski (subscriber, #104)
In reply to: This mirrors Microsofts shipping of Nimda to Korea by NZheretic
Parent article: Mozilla ships a compromised extension

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.

(Log in to post comments)

This mirrors Microsofts shipping of Nimda to Korea

Posted May 9, 2008 12:09 UTC (Fri) by thumperward (subscriber, #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 (guest, #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.