Why aren't Microsoft Office macros sandboxed?

Question

For about 20+ years now, Microsoft Office macros have been used to spread malware. Even in recent years those threats have not disappeared and they often resurface in one form or another e.g. World’s most destructive botnet returns with stolen passwords and email in tow and It’s 2016, so why is the world still falling for Office macro malware?. Over the years the only significant change Microsoft did was to make the macros not run by default, which just prompts the criminals to engage in some clever social engineering to make the user press the enable button. As far as I am aware, these macros are working as intended and are not exploits (check second article), because they are designed to be able to run unsandboxed arbitrary code. It's virtually impossible to run these macros in a safe environment, and MS Office makes no distinction between a macro that performs some simple automation that affects only the document itself and the ones that call some dangerous shell command that have impact in the whole OS (e.g. file system access). This answer makes it clear how painfully it is to run a macro safely.

Let's compare this approach with how Chrome works. Chrome's daily job is to run untrusted code by using a very elaborated way of sandboxing that makes sure merely visiting a web page is safe. Unlike MS Word, someone using Chrome can visit a website that has never visited before and it will gladly run all kinds of JS code on the page without ever prompting the user for permission i.e. no "enable content" button. This is because JS has very little power outside of the website that is being rendered. To make code that escapes this sandbox means to burn a precious zero-day exploit. Google pays good money for these exploits and it usually means issuing an emergency version with a fix.

For me both programs have more or less the same threat model: users will often open documents from unknown sources as they will often open web pages that they have never visited before. Yet what is a we-must-issue-a-patch-now situation for Chrome is just normal business for Microsoft Office applications. In the 20+ years that these macros have been raging on as an effective malware entrypoint, why didn't Microsoft update the threat model and put efforts into sandboxing these macros so they can only affect their own document? Why isn't there a way to run macros safely in the same way Chrome and other browsers run arbitrary untrusted code?

Answer 1

Microsoft Office macros are a design of the past. Do note that they were designed back in the days when a userland program could overwrite memory of another application (or even the kernel!), boundaries were not checked when processing network packets, etc.

It is also similar to the ActiveX web page additions that were created by Microsoft. Rather than running inside a sandbox, like java applets, they directly ran unconfined code (in the same memory space as the browser, I guess), with full access to the system. The security they got added was one of signed with a code certificate, do you trust this company?.

I think it is fair to say that security was never part of the macro design. The macro language (VBA) relies heavily on the program OLE interfaces and existing Visual Basic / VBScript engine.

You could design a sandboxed interface for Office macros. You would basically remove dangerous primitives (such as Shell) and disallow importing of foreign objects. Most macros (affecting only its own document) would still work. Macros using complex actions (such as accessing an url, or opening a Word document from Excel) would fail. Some "internal" would also need to be reviewed and filtered somehow (such as "Saving the current document with a given name" or modifying other opened documents).

Blocking all macros is a more simple approach than redesigning their macro system. It also avoids breaking documents with macros designed before the sandbox addition that were not able to be run. Microsoft could add a flag for "this is a macro with no external effects", so that they could opt-in to "safe execution", thus keeping backwards compatibility.

It would be a feature interesting to have, so that some macros could be allowed in the environment, without risking the whole system (I'm sure we would then see exploits and buffer overflows in those "safe macros" being abused, but those would be bugs). Although that wouldn't fully solve the problem: the social engineering would continue to "enable insecure macros". It would help administrators block macros, without such a big pushback for "we need documents with macros, which are business-critical".

Apparently, Microsoft hasn't deemed that use case profitable enough to the effort of developing a "sandboxed macros" feature.