Microsoft rolls back blocking Office VBA macros by default

Microsoft is rolling back a planned change to block Visual Basic for Applications (VBA) macros in various Office apps by default. Announced earlier this year, Microsoft had been planning to prevent Office users from quickly enabling certain content in files downloaded from the internet, including macros, to improve security against malicious files.

Microsoft had tested this change before a planned rollout to all Microsoft 365 users in June but suddenly reverted the block on June 30th.

Microsoft notified IT admins last week that it was rolling back the VBA macroblock based on feedback from Office users testing the changes. "We appreciate the feedback we've received so far, and we're working to make improvements in this experience," reads a Microsoft 365 message.

The unusual rollback has surprised some Microsoft 365 users, as many had been waiting years for Microsoft to be more aggressive about blocking macros from Office files. Hackers have been regularly targeting Office documents with malicious macros, and Office has typically prompted users to click to enable macros running with a simple button. Unfortunately, Microsoft's planned changes meant Office users could only allow the macros by precisely ticking an unblock option on the properties of a file.

Some users haven't well-received those extra steps. "Another terrible update idea from Microsoft," remarked one commenter on Microsoft's original announcement, and others criticized how difficult it was for end-users to enable macros. Others are surprised Microsoft is rolling back the changes without effectively communicating to IT admins that the company is reworking the VBA macroblock. Many IT admins had been preparing users for the macro modifications, as it's a shift that would require user training.

Microsoft hasn't explained its plans to improve the VBA macros block or when it will roll out again. "Based on feedback received, a rollback has started," says Angela Robertson, a principal group product manager for Microsoft 365. "An update about the rollback is in progress. I apologize for any inconvenience of the rollback starting before the update about the change was made available."

Code written in VBA is compiled to Microsoft P-Code (pseudo-code), a proprietary intermediate language, which the host applications (Access, Excel, Word, Outlook, and PowerPoint) store as a separate stream in COM Structured Storage files (e.g., .doc or .xls) independent of the document streams. The intermediate code is then executed by a virtual machine (hosted by the host application).

Despite its resemblance to many old BASIC dialects (particularly Microsoft BASIC, from which it is indirectly derived), VBA is incompatible with any of them except Visual Basic. The source code of VBA modules and classes can be directly imported and shares the same library and virtual machine. Compatibility ends with Visual Basic version 6; VBA is incompatible with Visual Basic .NET (VB.NET). VBA is proprietary to Microsoft and is not an open standard apart from the COM interface.

Interaction with the host application uses OLE Automation. Typically, the host application provides a type library and application programming interface (API) documentation that document how VBA programs can interact with the application. This documentation can be examined inside the VBA development environment using its Object Browser.

Visual Basic for Applications programs written to use one application's OLE Automation interface cannot be used to automate a different application, even if that application hosts the Visual Basic runtime, because the OLE Automation interfaces will be other. So, for example, a VBA program written to automate Microsoft Word cannot be used with a different word processor, even if that word processor hosts VBA.

Conversely, multiple applications can be automated from one host by creating Application objects within the VBA code. References to the different libraries must be made within the VBA client before any methods, things, etc., become available in the application. It is achieved through what is referred to as Early or Late Binding. These application objects create the OLE link to the application when they are first created. Commands to the different applications must be done explicitly through these application objects to work correctly.

VBA code written in Microsoft Access can establish references to the Excel, Word, and Outlook libraries; this allows the creation of an application. It runs a query in Access, exports the results to Excel and analyzes them, and then formats the output as tables in a Word document or sends them as an Outlook email.

VBA programs can be attached to a menu button, a macro, a keyboard shortcut, or an OLE/COM event, such as opening a document in the application. In addition, the language provides a user interface in the form of UserForms, which can host ActiveX controls for added functionality.

Inter-process communication automation includes the Dynamic Data Exchange (DDE) and real-time data (RTD), which allows calling a Component Object Model (COM) automation server for dynamic or real-time financial or scientific data.

As with any common programming language, VBA macros can be created with malicious intent. Using VBA, most of the security features lie in the hands of the user, not the author. The VBA host application options are accessible to the user. Users who run any document containing VBA macros can preset the software with user preferences. End-users can protect themselves from attack by disabling macros from running in an application or by granting permission for a document to run VBA code only if they are sure that the document's source can be trusted.