Not a bug: Outlook Forms run VBScript even when macros are disabled
The fact that you can put a VBScript program inside an Outlook Form and have it execute—even if Outlook has been told not to run macros—has been raising red flags this week. But in spite of what you may have read, that questionable behavior isn’t readily exploited. There’s no gaping security hole to see here. Move along.
Yesterday Richard Chirgwin at The Register wrote how a Pen-tester was able to get past Microsoft VB macro barriers. The article points to research published late last week by etienne at Sensepost. To make a long story short, yes it’s possible to write a VBScript program, attach it to an Outlook Form, and have the script do just about anything on a PC (“within the context of the logged-on user”) when the Form is used.
The script will run even if the Outlook Trust Center has been set to show “Notifications for digitally signed macros, all other macros disabled.”
That’s not great, but in and of itself it’s a relatively minor problem, which hinges on the definition of “all other macros.” Sensepost explains that the VBScript engine is “separate from the VBA Macro script engine.” Is a VBScript script inside a Form really a macro? You decide.
The greater question is whether this particular approach can be used to compromise PCs. Are we looking at a long-standing security hole in Outlook?
The Register approached Microsoft with that question and received this reply:
The technique described in the blog is not a software vulnerability and can only be leveraged using an account that has already been compromised by another method.
As best I can tell, that’s correct. You can create a Form that exhibits the problematic behavior—but it isn’t at all clear that you can infect somebody else.
Poster NetDef on the AskWoody Lounge puts it this way:
You would have to export the form, get another user to install both files (.frm and .frx) and generate a self signed certificate for themselves. Or go to the expense of buying a cert, for distribution – which is not as hard for malware authors as it used to be. Either way, I see no way for a drive by infection using this method.
That is functionally equivalent to asking someone to buy a car, put it in Drive, run around to the front of the car, and have it run over their foot. If there’s another infection vector, I haven’t been able to find it.
It looks to me like Microsoft’s right. While the macro setting probably should apply to VBScripts inside Forms, the scenario is so convoluted that this really doesn’t amount to a security hole.
Can you come up with a more plausible vector? Hit me on the AskWoody Lounge.