A common phenomenon in the tech world is when vendors trash their own past products in an effort to convince you of the value of shiny new ones.

Here is an example. Microsoft’s security advisory 937696 and the related KB 935865 tells us of the dangers posed by Office binary formats including .doc, .xls and .ppt:

MOICE uses the 2007 Microsoft Office system converters to convert the Office binary format files into the Office Open XML format. This process helps remove the potential threat that may exist if the document is opened in the binary format. Additionally, MOICE converts incoming files in an isolated environment. This helps protect the computer from a potential threat.

What’s MOICE? It’s the Microsoft Office Isolated Conversion Environment, proving that even after Silverlight, the department of verbose and meaningless names is alive and well in Redmond. It is an add-on to Office 2003 or 2007 that automatically converts Office binary formats to Office Open XML (OOXML). Further, administrators can now choose to implement File Block, which prevents users from opening specified binary document types without first converting them.

The presumption here is that OOXML documents are safer. Probably true, especially since documents containing macros now require a different extension (.docm, .xlm) to flag the fact that they contain macros.

A side effect is that MOICE spreads the adoption of OOXML. Like Joe Wilcox, I can’t help wondering whether it was this, rather than security, which has prompted this release.

OOXML has real advantages, yet it can also be tiresome. Users install Office 2007, email a Word document to someone, then get a perplexed reply saying that the document won’t open. I’ve been known to show people how to set the default back to the old binary formats to avoid this problem – I would love to know how many Office 2007 rollouts do this as a matter of course.

After all, it is late in the day for Microsoft to consider blocking these formats. The Sophos web site has a Top Ten Viruses page with a neat feature: you can see stats for the last 10 years. These confirm my hunch. Back in 1999, there were 9 office macro viruses in the top 10 (Sophos prefixes these with WM or XM). Today? None. Further, note that the top 10, according to Sophos, account for 94.6% of all viruses in the wild.

The reason is that in the intervening years Microsoft has built reasonably good macro protection into Office. A factor here is that emailed documents rarely need to contain macros, so if you double-click an attachment and it wants to run a macro, that’s a big clue that something is awry.

That said, there is clearly still some risk from macro viruses, or from documents with crafted corruptions that infect a PC. Recently, Open Office has also been shown to be vulnerable. So MOICE has a value, but is it enough to compensate for the cost in terms of inconvenience? After all, while Office binary formats are almost universally readable, that’s not the case for OOXML. If you run Windows, and have Office 2000 or higher, and broadband Internet, and sufficient rights to install the converter, then the process is reasonably smooth; but that is a long way from universal.

MOICE strikes me as low priority in security terms, but nevertheless an intriguing development in the battle for XML office format adoption.

Ian Griffiths has a nice post on why you should not disable UAC, even if you are are a developer.

I’ve followed that advice and it works for me, though there are still one or two apps where I have to Run As Administrator.

That does not include Visual Studio 2005. Despite the warning which it issues, I find it works for me without it (I realise there are scenarios where this won’t be the case).

The intriguing thing is that (as Griffiths notes) even Microsoft is not solidly behind UAC. I’ve commented on this before.

Since there is still a myth that running Vista with UAC enabled results in an avalanche of intrusive dialogs, it’s worth popping up from time to time to say that it is not so.

Windows security affects all of us, even if you do not like Windows or use it. UAC (and IE7’s protected mode, which depends on it) is a step forward and worth supporting.

Tech journalists have a tough job. They are meant to take the vast complexity of things like computers and operating systems and translate them into terms that ordinary people can understand.

Of course there is never a one-to-one mapping between the complex and the simple. The simplified explanation is a compromise.

So let’s look at the question: how secure is Windows Vista? Unfortunately the question is not amenable to a simple answer. Perhaps the best you can do is to try and explain the issues, the ways in which it is more secure than earlier versions of Windows, the ways in which it remains insecure.

Now read this piece on weaknesses in Vista’s UAC (User Account Control). Looks bad, right? About some insightful researcher who “found out — from Microsoft officials — that the default no-admin setting isn’t even a security mechanism anymore.”

This is a misunderstanding of a typically balanced and well-reasoned piece by Microsoft’s Mark Russinovich on UAC in Vista. At least the link is there in the ZDNet article, so you can read it for yourself.

Apparently, “In an e-mail interview, the Polish malware researcher said she was “pissed off” by what she perceived as Russinovich’s flippant attitude to the potential risk.”

Frankly, I defy anyone to read and understand Russinovich’s article and call it “flippant”. He explains how the mechanism works, he explains why it works as it does, acknowledges areas of compromise, and shows how to achieve higher security if you want it:

Without the convenience of elevations most of us would continue to run the way we have on previous versions of Windows: with administrative rights all the time. Protected Mode IE and PsExec’s -l option simply take advantage of ILs to create a sandbox around malware that gets past other security defenses. The elevation and Protected Mode IE sandboxes might have potential avenues of attack , but they’re better than no sandbox at all. If you value security over any convenience you can, of course, leverage the security boundary of separate user accounts by running as standard user all the time and switching to dedicated accounts for unsafe browsing and administrative activities.

He’s right. And personally I think ZDNet is giving too much weight to the strident researcher who calls Vista security “a big joke“, while doing too little to examine the real issues which Russinovich explains.

Of course that doesn’t prevent Slashdot and others picking up the story and presuming, because that’s what they want to believe, that Vista security is shot to bits.

It’s not. It is a real advance on XP, not least because of the point Russinovich highlights:

Why did Windows Vista go to the trouble of introducing elevations and ILs? To get us to a world where everyone runs as standard user by default and all software is written with that assumption.

Update

This story gets more curious the more you investigate. The gist of this researcher’s original complaint was that Vista forced her to run setup and installer applications with local admin rights:

That means that if you downloaded some freeware Tetris game, you will have to run its installer as administrator, giving it not only full access to all your file system and registry, but also allowing e.g. to load kernel drivers!

It’s a fair point, though problematic on examination. Installing applications is an administrative task. Still, it’s correct that many installers do not need full admin rights, so the system could be more granular. Fortunately Vista covers this. You can disable the automatic elevation of setup applications in local security policy. In fact, enterprise rollouts have this disabled by default. The researcher is actually aware of this, but says:

Even though it’s possible to disable heuristics-based installer detection via local policy settings, that doesn’t seem to work for those installer executables which have embedded manifest saying that they should be run as administrator. I see the above limitation as a very severe hole in the design of UAC.

Now she’s lost me. The complaint has shifted – there is no problem running setup applications with less than full admin rights, but if the developer specifies with a manifest that full admin rights are required, then Vista automatically prompts for elevation. This of course is working as designed. If you downloaded a “freeware Tetris game” and discovered a manifest insisting on full admin rights, you would likely be wary in any case.

So where is the “very severe hole in the design of UAC”? There is a “severe hole” here, but it is not in the design of UAC. The core problem is that users may try to install malware. They are browsing the web, and perhaps come across a flashing advertisement that says their PC has spyware, but this utility will fix it. They download it. They pass a dialog warning that the file is from the internet and might not be safe. They pass a dialog requesting elevation. At this point, only anti-virus software or something like Windows Defender might save them. How do you fix this, without taking away the user’s right to do what they want with the computer they own?

That said, there is a weakness in UAC in the potential of non-elevated processes to interfere with elevated processed. Mark Russinovich covers this well in his post referenced above. Bottom line is that it’s still best not to run with full admin rights, even with UAC enabled. The long-term purpose of UAC is to get Windows across the hump of legacy applications to a point where local admin rights for day-to-day use are unnecessary.