Sunday, 4 July 2004

Download.Ject patch

There's now a patch available for the Download.Ject trojan - or rather, one of the holes it used (since the site hosting the code was taken down last week).

The Register: Microsoft half fixes serious IE vuln

The Register get it wrong again, of course: I anticipate that this is the full and final patch for this issue. The ADODB.Stream vulnerability is simply that a feature - the ability to write to a file anywhere on the hard disk - was made available to the web. The patch sets the 'kill bit' in the registry, preventing this control from being directly loaded from IE, as detailed in KB 870669. MS have clearly decided that compatibility and functionality have to be sacrificed on the altar of security.

A naive user reading that could argue that IE's security model is the wrong way round - instead of killing known unsafe controls, only known safe controls should be permitted. It actually does work that way, for most zones: controls must be marked 'safe for scripting' to be scripted and 'safe for initialization' to load parameters from the web page. The Local Machine Zone is different; that will be, by default, locked down in XP SP2 RC2. The 'kill bit' is for this situation - a control marked safe is in fact unsafe in a particular scenario.

The other vulnerabilities exploited were already patched in MS04-013 (client-side) and MS04-011 (server-side). If admins had applied the 04-011 patch rather than being scared off by adverse media reports, this wouldn't have happened. It's an admin's responsibility to not be an attack vector, as well as protecting their own systems. The Internet users may even have been collateral damage - IIS 5.0 is used much more widely in intranets. Of course there were incompatibilities with this patch, largely due to a new kernel binary being released for Windows 2000. We needed a hotfix and got stuck in the Product Support queue behind a bunch of the problem reports.

Yes, this exploit is a side-effect of IE being able to load and script any COM component in the local machine zone - get over it. As I say above, this will be locked down in XP SP2 (and already is in RC2). IE's come a long way since the bad days of IE 3.0, which didn't do any checking. It's also a side-effect of the user running as an Administrator, which we all know is a bad thing. If you're not running as Admin, I suspect that Download.Ject couldn't actually install the backdoor components.

Note that Firefox has the XPConnect module, which allows XPCOM plug-ins to be scripted, potentially leading to the exact same problems for any installed extensions. It's just no-one's found any vulnerabilities yet.

[Edit] That's a bit strong, really. It will only apply to Firefox extensions, not every control/component installed on the user's system. Still, that's probably enough scope, since almost everyone will have Flash installed. [/Edit]

No comments: