"A successful attack may allow attackers to access sensitive information and potentially execute malicious commands on a vulnerable computer," Symantec said in the alert, which was sent to users of its DeepSight security intelligence. The vulnerability was reported by researcher Debasis Mohanty.

The issue relates to the ability to load ActiveX controls in an Office document and is not a vulnerability but an Office feature, a Microsoft representative said. "This behavior is by design and by itself does not represent a security risk to customers," he said. An ActiveX control is a small application typically used to make Web sites more interactive.

-- Office hit by another security problem (ZDNET)

It's not a bug, it's a feature!

(It's amazing how much of this article is unchanged from the one I wrote in 2004 about the security enhancements that Microsoft was planning for Longhorn, now Vista. But then, this "vulnerability feature" has been embedded in Windows since 1997)

The vast majority of security breaches on Windows are due to this "feature". The "default open" design of their internet access and HTML technologies, and the way they're integrated into the OS to such an extent that every program has to consider that any filename or object it's passed may be part of an exploit, means that instead of having a single security boundary around one application that deals with potentially malicious data, every program in the system is responsible for re-implementing the security boundary that should have been created by the web browser.

There are only two possible paths forward: one, add more and more layers of aggressive security to try and keep patching holes as fast as they're found. Two, rethink the fundamental design of the user interface and separate the browser into two parts to isolate the problem as much as possible. The component responsible for displaying web pages should have no built-in mechanisms for accessing content, installing plugings, and so on. It must be inherently sandboxed, with access and permissions completely mediated by the application that's calling it. Plugins must be explicitly installed, and under the user's control. That is, running downloaded content anywhere but in a completely sandboxed interpreter should be handled by the user's request, not the attacker's.

That way there wouldn't be "active content" in Office documents, because browser plugins wouldn't show up in word processors.

About ten years ago, when Microsoft started integrating the browser and the desktop, I managed to get Internet Explorer, Outlook, and other applications that used the same interface banned in our office. Over the next several years we continued to use Windows and other Windows applications and tools, and we took a relatively lightweight approach to security other than banning IE. Result? Occasional single-workstation virus alerts, almost never an infection beyond one user's machine... and a large percentage of the time it was a user running Outlook "unofficially" that caused the problem. Far fewer problems than my counterparts at sites that imposed heavy restrictions but standardized on IE.

So, ten years ago the "opportunity" that this "feature" would create was obvious to my non-genius-level brain. I've been warning people that things are just going to get worse from both sides - system reliability and system security - until Microsoft stops depending on patches and rethinks their fundamental design.

Microsoft apologists endlessly praise the new bandaids that Microsoft is adding, and tell me that "every system has security holes". Why, yes, but on most of them these holes are bugs, not features. Bugs are much easier to fix.

 IO
Lynx-enhanced by <peter at taronga.com> (Peter da Silva)