by Mitja Kolsek, the 0patch Team
Introduction
In October, a Dynamic Data Exchange-borne attack vector in Office was published by Sensepost and got quickly adopted by attackers. While Microsoft's official stance at the time was that DDE was behaving as intended and the issue was "considered for a next-version candidate bug," we at 0patch decided to create a micropatch that would prevent all supported versions of Word - and by extension, Outlook - from launching external applications via DDE field updates.
As real-world exploits became more prevalent, Microsoft issued a security advisory explaining how to disable auto-updating of DDE fields (echoing prior guidance from the community). The subsequent release of Windows 10 Fall Creators Update also brought the Attack Surface Reduction feature, which blocked some DDE-borne attacks (although not via Outlook).
Three weeks after we have released our micropatch, Microsoft updated various Office components (including wwlib.dll which we micropatched) for unrelated reasons, prompting us to re-issue micropatches for the modified modules.
Porting micropatches to new product versions (or old versions, for that matter) is a standard procedure with us, so it took us just a few hours from obtaining Microsoft's updates and having all Office versions covered with the new micropatches. Our users didn't notice anything, and that's how we believe vulnerability patching should work in this century.Service Update: Recent Patch Tuesday modified MS Office's wwlib.dll, prompting us to port our DDE/DDEAUTO micropatches to new versions. These will be downloaded and applied automatically without disturbing your work. https://t.co/rZsObtaQIh— 0patch (@0patch) November 17, 2017
Enter Vendor's Official Fix
Yesterday, 42 days after we have initially released our DDE micropatch, Microsoft issued an update for Word that provides registry-based configuration of DDE behavior. Users are now able to select whether:
- DDE is entirely disabled (this is the default);
- DDE works exactly as specified by Microsoft's documentation, i.e., it communicates with already launched applications, but doesn't launch applications itself (this is the behavior implemented by our micropatch);
- DDE works as before, allowing DDE-borne attacks.
So what happens on computers with 0patch Agent when this official Word update is installed? Elegantly, our micropatches stop being applied by design when executables they're patching are modified, because that changes their cryptographic hash. Microsoft's update modifies the target module for our DDE micropatches (wwlib.dll), resulting in (1) our micropatches becoming obsolete and (2) DDE getting disabled due to the default setting of the above-mentioned configuration.
We will not port our micropatch to this new Word update as there is no need for that: Office users who apply the latest Word update and want to keep using DDE without the fear of launching malicious executables can create a DWORD registry value AllowDDE under HKEY_CURRENT_USER\Software\Microsoft\Office\version\Word\Security and set it to 1 as described in Microsoft's advisory.
However, users who haven't applied the Word update yet or can't apply it for any reason, will remain protected by our micropatches. If you happen to be in such situation and don't have 0patch Agent yet, simply download, install and register it. It's free.
How does this Microsoft's DDE fix compare to our DDE micropatch?
- Behavior: The behavior of Microsoft's fixed code is almost identical to our micropatch for AllowDDE value 1. (The former is actually a bit better as it doesn't even ask your permission to launch the application.) For AllowDDE value 0, DDE is completely disabled - our micropatch doesn't provide this option and we actually don't see any security value in it other than reducing the amount of code accessible by malicious documents. Then again, perhaps Microsoft is aware of some other DDE-related attack that this option blocks, or they're simply trying to steer users away from using DDE;
- Timing: Our micropatch for the DDE issue was available 42 days before Microsoft's official fix;
- Ease of installation: Installing Microsoft's update requires a computer restart (although the relevant changes are actually applied without that), while a micropatch is installed and applied without any disruption, even while the user is editing a document in Word;
- Ease of use: Microsoft's DDE configuration is done via registry, while our patch can be turned on and off either via registry or via 0patch Console's graphical user interface. Also, any user can configure DDE for themselves while only administrator can turn our micropatch on or off. (In other words, 0patch doesn't allow users to make themselves vulnerable again because they liked the way things worked before.)
- Portability: It would be extremely expensive for Microsoft (not to mention undesirable in the business sense) to port this new DDE configurability to older versions (builds) of Office, especially the end-of-life versions. In contrast, it's trivial for us to port our micropatches to any previous version and build as needed by our users.
Conclusion
In conclusion, this 42-day exercise nicely demonstrated the value of 0patch and micropatching. We proved that a micropatch can be quickly developed for numerous product versions and distributed to all users without disturbance. We showed that when a micropatched product is modified by its vendor, we can quickly re-issue micropatches for it (by the way, there's lots of room for further improvement there). And finally, as this DDE issue was officially patched by the vendor and this fix applied on users' computers, our micropatches for it have reached their intended end of life. For those, however, who for any reason can't apply the Word update or must delay its application due to comprehensive testing requirements, our micropatch remains there for you, for free and for however long you need it. This is exactly how we intend to bridge the security update gap.
Keep your feedback coming! Thank you!
@mkolsek
@0patch
