OpenOffice Vulnerability Exposes Users to Code Execution Attacks

21 September 2021

OpenOffice Vulnerability Exposes Users to Code Execution Attacks

A buffer overflow vulnerability in Apache OpenOffice could be exploited to execute arbitrary code on target machines using malicious documents.

Tracked as CVE-2021-33035 and discovered by security researcher Eugene Lim, the bug affects OpenOffice versions up to 4.1.10, with patches deployed in the 4.1.11 beta only, meaning that most installations out there are likely vulnerable.

The issue was identified while researching for potential security holes in software that parses the .dbf file format, explains Lim, a white hat hacker and researcher with the GovTech Singapore Cyber Security Group.

As part of his work, Lim came up with a dumb fuzzing template that would trigger the bug on a target machine and tested it on several DBF processors, which helped him discover two vulnerabilities, namely CVE-2021–35297 in Scalabium dBase Viewer and CVE-2021–33035 in Apache OpenOffice, an open source office suite with hundreds of millions of downloads.

The identified issue is a buffer overflow that basically exists because the buffer size of a DBF file is determined either by the fieldLength or the fieldType in the header. Thus, if one is trusted when allocating the buffer and the other one when copying into that buffer, an overflow could be triggered.

With that in mind, the researcher was able to use his dumb fuzzing template to trigger a crash but, because OpenOffice has protections such as address space layout randomization (ASLR) and Data Execution Prevention (DEP), a bypass of these was also needed for a return-oriented programming (ROP) chain.

Further analysis revealed that the libxml2 module in the office suite wasn’t compiled with DEP or ASLR protections, and the researcher was eventually able to exploit the vulnerability using a specially crafted .dbf file.

Although OpenOffice is an open-source application, meaning that it is likely scanned by numerous code analyzers, the issue was not identified because scanners such as LGTM were looking for Python and JavaScript code in the suite, but not for C++ code, where the bug resides.

“This demonstrates the importance of sanity-checking automated static analysis tools; if your tools don’t know the code exists, it can’t find those vulnerabilities,” Lim points out.

The security researcher reported the vulnerability in May and Apache updated OpenOffice’s source code on GitHub, but has yet to make the patches available in a stable release. The researcher, who agreed to an August 30 public disclosure, published details on the bug on September 18, after presenting it at HackerOne's Hacktivity online conference.

The bug in Scalabium dBase viewer was addressed in June, two days after it was reported.