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

This mirrors Microsofts shipping of Nimda to Korea

Posted May 8, 2008 11:29 UTC (Thu) by NZheretic (guest, #409)
Parent article: Mozilla ships a compromised extension

17 June 2002 : Microsoft accidentally ships Nimda in Korea

Microsoft 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.

(Log in to post comments)

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 (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.