A Matter of Trust

A bug is a bug - and it's not going away by defining matching design goals. By Jürgen Schmidt of heise Security.

During the last months Microsoft seemed to be on the right path. They acknowledged long known bugs as such and changed the behaviour of functions which had previously been declared as necessary design features. A lot of Internet Explorer exploits could write their malware directly to the local disk with ADODB.stream - just because the user opened the wrong web page.

For about a year Microsoft argued along the well known line 'this is not a bug, it's a feature'. Then came Download.JECT and a month ago Microsoft suddenly deactivated calls of ADODB.stream in Internet Explorer. This raised hopes that Microsoft had finally learned its lesson and the software giant is finally serious about the security of its customers.

After playing around with the new security features of SP2 a couple of days, I discovered a bug. Windows Explorer starts an application that is marked as insecure without the proper warning because there is some outdated security information in its cache which belonged to a long-gone file with the same name.

This is a classic programming bug. By far not comparable to ADODB.stream, but a bug that needs to be fixed. So I filled out Microsoft's bug report form.

Microsoft Security Response Center answered: 'the behavior you are seeing does not conflict with the design goals of this feature' and 'at this time we do not see these as issues that we would develop patches or workarounds to address'.

Here it is again: the old Microsoft which backs off to a position like: 'this is not a bug, it's a feature'. Their intention is clear: if Microsoft admitted that there is a bug in one of the new security functions, this would result in a lot of bad publicity. So Microsoft prefers that some security experts raise their eyebrows, hopes that nothing serious will happen and that the discussion stays limited to small insider groups.

This might even work this time. But once more the hope is shattered, that there are some fundamental changes happening within Microsoft. In the long run this behaviour will come back on Microsoft. Trust like it is claimed in 'Trustworthy Computing' has to be built up through a slow and continuous process - but it is gambled away quickly.

A bug is a bug - and it's not going away by defining matching design goals. Especially in security related functions, bugs have to be removed as soon as possible - regardless of whether they can be exploited directly or not.

Too often we have seen that only the combination of small problems allowed a serious exploit. Download.JECT was a classic example. We can only hope that Microsoft changes its mind and fixes this caching problem of Windows Explorer before it can be exploited.