However, compared to modern coverage-based fuzzers that trace the execution flow with each iteration, Peach Fuzzer only instruments execution (via Intel PIN) in its corpus minimisation tool. Peach Fuzzer claims to be “smart” due to the way it records and analyses crashes as they occur. I used GitLab’s open-source Peach Fuzzer - something I previously wrote about - as my dumb fuzzer. For my research, I fuzzed Windows applications due to the relative abundance of Windows DBF processors. Lastly, this allowed me to isolate any crashes to the file format parsing logic itself. Secondly, there was a greater likelihood that these less well-maintained applications would be vulnerable to format-based exploits. Firstly, it would be much faster to fuzz with dumb fuzzers, which run the entire application rather than a minimal harness. I focused on tiny applications whose sole job was to open and display DBF files rather than complex enterprise applications. provided a list of programs that could open DBF files. Dumb Fuzzing with GitLab’s Peach Fuzzerīefore diving into coverage-guided fuzzing (which I will write about in part 2), I decided to validate my understanding of the file format by using a format-based dumb fuzzer to discover vulnerabilities in simple DBF processors. The various versions and extensions of the DBF format provide ample opportunities for programmers to introduce parsing vulnerabilities. The Library of Congress lists an amazing catalogue of file formats, including DBF. Many spreadsheet and office applications have continued to support DBF, including Microsoft Office, LibreOffice, and Apache OpenOffice.įortunately, it was relatively simple to discover the file format documentation for dBase Wikipedia has a simple description of version 5 of the format and dBase LLC also provides an updated specification. However, due to its status as a legacy file format across multiple platforms, dBase databases still popped up in interesting places, such as in the shapefile geographic information system (GIS) format. Although it continued to support more use cases with each revision, the format still suffered from significant limitations in storage and media support, eventually losing out to more advanced competitors. As far as possible, I also wanted to focus on a less-researched file format that may have escaped the notice of other researchers.Īfter a bit of Googling, I found the dBase database file (DBF) format (.dbf).Ĭreated almost 40 years ago, the dBase database format was used as a data storage mechanism for a variety of applications, from spreadsheet processors to integrated development environments (IDEs). This helped to simplify my fuzzing templates rather than dealing with nested file containers and reduced the amount of complexity when conducting root cause analysis. I needed to select a file format that was not simply a ZIP file in disguise, (e.g. However, not all file formats are created equal. Overall, it is a good way to get started in vulnerability research. Lastly, file format fuzzing tends to be much simpler to set up than protocol fuzzing. Furthermore, common file formats are well-documented by Request for Comments (RFCs) or open-source code, reducing the amount of effort required to reverse-engineer the format. Firstly, as a beginner, I lacked the experience to quickly identify unique attack vectors in individual applications, whereas file format parsing tends to be a common entrypoint among many applications. There are two main advantages to this approach. One piece of advice I received early in the vulnerability research journey was to focus on a file format, not a specific piece of software. In part two, I will disclose additional vulnerabilities that I discovered via coverage-guided fuzzing - including CVE-2021–38646: Microsoft Office Access Connectivity Engine Remote Code Execution Vulnerability. I will also discuss some management aspects of vulnerability research such as CVE assignment and responsible disclosure. I will outline my approach to getting started in vulnerability research including dumb fuzzing, coverage-guided fuzzing, reverse engineering, and source code review. This two-part series will share how I got started in vulnerability research by discovering and exploiting code execution zero-days in office applications used by hundreds of millions of people. Coming from a background in primarily web and application security, I had to shift my hacking mindset towards memory corruption vulnerabilities and local attack vectors. Venturing out into the wilderness of vulnerability research can be a daunting task. All Your (d)Base Are Belong To Us, Part 1: Code Execution in Apache OpenOffice (CVE-2021–33035) Introduction
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |