Microsoft Office is a very commonly used software that can be found on almost any standard computer. It is also integrated inside many products of the Microsoft/Windows ecosystem such as Office itself, Outlook and Office Online. In this blog, we describe our attempts to fuzz a specific component in Microsoft Office and how the results affect this whole ecosystem. We also evaluate the pros and cons of the different fuzzing solutions we experimented with in the course of our research. Our Target We chose the MSGraph COM component (MSGraph.Chart.8, GRAPH.EXE) as our fuzzing target, as it is quite an old piece of code that has existed since at least the days of Office 2003 or earlier. To our knowledge, this component has not received too much attention from the security community until now, making it a fertile ground for bugs. MSGraph is a component that can be embedded inside many Microsoft Office products (such as Word, Outlook, PowerPoint, etc.), and is used to display graphs and charts. In terms of attack surface, MSGraph is quite similar to . However, unlike Microsoft Equation Editor, MSGraph is still updated in every Office patch and receives the latest mitigations (such as ASLR and DEP), which makes successful exploitation harder. We later found that this attack surface also applies to other Microsoft Office products, including Excel and Office Online, that share the same code. Microsoft Equation Editor 3.0 Microsoft Office is not an easy target to fuzz MSGraph is a piece of software that utilizes the Windows COM model in some parts of its code. This makes MSGraph a not-so-trivial target to harness and fuzz. On top of that, MSGraph specifically, and Office in general, utilizes and runs a very large number of components and external DLLs, making the process of reverse-engineering harder. As this is a graybox target (we do not have source code, but we do have the ability to modify the binary, place breakpoints and examine the disassembly), harnessing the program can be tricky. There is no obvious “this_function_parses_stuff” function exported, and even the function that we identified as the parsing function contained some GUI calls that made the fuzzing process slow and clumsy. symbol-less Harnessing MSGraph In fuzzing terminology, a “harness” usually refers to a small program that triggers the functionality we want to fuzz. To learn more about this topic, we recommend reading our previous blogpost: . The simplest way to create a harness for graybox targets is to utilize an exported function. This didn’t work in our case as we didn’t have such a function. An alternative is to trace and reverse-engineer the execution process of the application to find which function is responsible for the parsing logic and then call it directly. 50 CVEs in 50 Days: Fuzzing Adobe Reader While IDA was processing the binary (which took some time), we decided to test our luck and try a slightly mutated input. We used to mutate a legitimate input file and we manually tested the results (by clicking buttons in the GUI). We managed to find a crashing input (int29h / Assertion Error) on our 8th attempt. Talk about luck… radamsa Although this crash is not interesting by itself, it definitely helped us identify which code is responsible for the parsing process, or at the very least, is prone to bugs. This is also when we understood why it was probably a good idea for Microsoft to “isolate” this component inside a COM object. In case this component happens to crash, the whole Word document still remains intact. Fuzzing MSGraph As we mentioned earlier, our target is graybox, so we have to use some Dynamic Binary Instrumentation (DBI) engine to instrument our target in order to collect coverage and fuzz efficiently. We tested multiple DBI solutions for this purpose and here are our results. You should remember, however, that MSGraph is a complicated target and these results can vary across different targets! – A veteran DBI solution that has existed since 2002 (!). It has great integration within and a set of utilities that can be very useful for research. Most notable is drcov, that can produce coverage for the execution of the binary. However, DynamoRIO currently does not support the latest releases for Windows 10. Unfortunately, when we attempted to use drcov with our target, it crashed before reaching the target function. DynamoRIO WinAFL – Part of the , which rightfully receives a lot of love in the security community. Frida is an incredible tool that is capable of doing lots of research-related tasks and is commonly known for its JavaScript bindings. Collecting coverage with Frida Gum (the C++ bindings for Frida) was relatively simple and we even managed to port WinAFL to use Frida as a coverage module. However, when we attempted to fuzz our actual target, we encountered some difficulties using the Frida API, so we decided to opt for another DBI solution instead. It is also important to mention that Frida has a very active Telegram channel that we found very useful. Frida Gum Frida toolkit – A tool developed for the purpose of collecting execution coverage using debugging API (int3), coded in Rust. Mesos utilizes IDA to extract all of the basic block offsets in the target binary. It then uses some fast technique to apply breakpoints on all of these offsets. Once a breakpoint is hit, the input that triggered it is cached, and will not trigger again as the breakpoint is removed. Even though this method increases the speed of the execution by reducing the number of breakpoints hits, it prevents us from getting code coverage, which we believe helps the fuzzing process tremendously. Mesos edge – A relatively new lightweight DBI solution that is actively maintained by Google Project Zero and is already supported by . It is essentially a binary rewrite solution that works in runtime. When the program reaches new code in a traced module, it parses its functions recursively and adds instrumentation for each basic block. TinyInst Jackalope TL;DR Tracing Solution Pros + Cons – DynamoRIO Integration within WinAFL. Utilities: drrun, drcov. Newer builds for Windows are not supported. Crashes MSGraph. Frida Gum Javascript Bindings. Very active Telegram channel for developers. Difficulties on our side. Mesos Designed to be easily modified. Requires IDA. Uses INT3. Doesn’t produce edge coverage. TinyInst Worked for us out-of-the-box. Jacaklope integration. Relatively new. In theory, we could have invested more time to understand why each solution did not work for us, and we would probably have done so if TinyInst had not worked so well for us. Jackalope vs MSGraph As TinyInst ended up working for us out-of-the-box and has a good integration with Jackalope, we decided to use Jackalope as our fuzzing solution. We also used gflags to help us catch heap-related bugs. After about a week of on-and-off fuzzing, Jackalope managed to find 4 different bugs in MSGraph. These are the CVEs: – Memory Corruption CVE-2021-31179 – OOBR CVE-2021-31174 – Integer Underflow to OOBR CVE-2021-31178 – UAF CVE-2021-31939 As Jackalope is still in the early development stages, it lacks some statistical information that is currently present in AFL, for example. Usually this information is used as a convenient way to measure the efficiency of the fuzzing process. However, working out-of-the-box is a major plus 🙂 Another great feature of Jackalope is that it is easily customizable and hackable. The process of adding a custom mutator to the fuzzer was pretty straight-forward and increased our fuzzing effectiveness with very little development cost. Code Similarity After we identified the vulnerable function inside MSGraph, we found through code similarity checks that the vulnerable function is commonly used across multiple different Microsoft Office products, such as Excel (EXCEL.EXE), (EXCELCNV.EXE) and Excel for OSX. We successfully reproduced some of the bugs in these products. Office Online Server As you can see in the images below, the same crash can be reproduced on these different products: Summary Even though we researched a single component of Microsoft Office, we managed to find several vulnerabilities that affect multiple products in this ecosystem. The results of this research were a set of files that could be embedded in different ways to potentially exploit different Office products across multiple platforms. As a bonus, we also had the opportunity to experiment with multiple different fuzzing solutions. We hope you find our notes useful. Disclosure Timeline 28 Feb 2021 – Initial report to Microsoft. 11 May 2021 – Microsoft fixes CVE-2021-31174, CVE-2021-31178, CVE-2021-31179 (Patch Tuesday) 08 Jun 2021 – Microsoft fixes CVE-2021-31939 (Patch Tuesday) 08 Jun 2021 – Blog release

Adobe

Google

Microsoft

Target

Trace

How the Security of Remote Work Has Evolved With the Rise of Zero Trust

How a New Cyber Espionage Weapon in Southeast Asian Government Got Detected

Visit us

Too Long; Didn't Read

Automate Security Across All Your Cloud Environments

How we Fuzz Tested the Microsoft Office Ecosystem

How we Fuzz Tested the Microsoft Office Ecosystem

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

How a Supply-Chain Breach Put at Risk Atlassian Accounts

11 Best Automation Testing Tools to Try in 2021

145 Stories To Learn About Test Automation

Python-Powered Performance Testing for QA Testers: A Beginner's Guide to Cloud API Load Testing

57 Stories To Learn About Automated Testing

How a Supply-Chain Breach Put at Risk Atlassian Accounts

11 Best Automation Testing Tools to Try in 2021

145 Stories To Learn About Test Automation

Python-Powered Performance Testing for QA Testers: A Beginner's Guide to Cloud API Load Testing

57 Stories To Learn About Automated Testing

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps