Apache OpenOffice is currently impacted by a remote code execution flaw

Apache OpenOffice (AOO) is currently impacted by a remote code execution flaw, tracked as CVE-2021-33035, that has yet to be fixed in the official release.

Security researcher Eugene Lim (@spaceraccoonsec) recently revealed technical details about a remote code execution flaw, tracked as CVE-2021-33035, (CVE-2021-33035) that impacts OpenOffice (AOO). The experts disclosed the flaw at HackerOne’s Hacktivity online conference after the company failed to address the vulnerability by August 30.

At the time of this writing, the flaw was only addressed with a beta software update and awaits the official release.

Apache OpenOffice (AOO) is currently vulnerable to a remote code execution vulnerability and while the app’s source code has been patched, the fix has only been made available as beta software and awaits an official release.

An attacker could trigger the flaw by tricking the victim into opening a specially crafted .dbf file.

Lim told El Reg the CVE-2021-33035 “is a buffer overflow by a .dbf file which overrides a return pointer with a DEP [data execution prevention] and ASLR [address space layout randomization] bypass to finally execute arbitrary commands by the attacker.”

The researcher used a format-based dumb fuzzer, named Peach Fuzzer, to discover vulnerabilities in simple DBF processors

The DBF format is composed of two main sections, the header and the body. The header includes a prefix that describes the dBase database version, the last update timestamp, and other metadata. The researcher ponted out that the header also specifies the length of each record in the database, the length of the header structure, the number of records, and the data fields in a record. The fields also include a FieldLength descriptor. The body simply contains all the records as described by the header.

Manipulating the fieldLength or FieldType values he was able to trigger a buffer overflow.

The researcher was able to exploit the flaw to open the file in OpenOffice Calc and cause a crash.

“Here, we can see a buffer nValue of size sal_Int32 (4 bytes) being instantiated for a field of type INTEGER. Next, memcpy copies a buffer of size nLen — which is an attacker-controlled value — into nValue without validating that nLen is smaller than or equal to 4. This pattern was repeated across various data types. Could this be a variation of the previous buffer overflow? I quickly modified my previous payload generator to the integer field type (I), increased the size of fieldLength to greater than sal_Int32, and opened the file in OpenOffice Calc. I got my crash!” wrote the Lim on Medium.

Despite the partial success, the researcher noticed that protections, such as address space layout randomization (ASLR) and Data Execution Prevention (DEP) prevented simple exploitation of the buffer overflow.

To bypass these protections Lim imported the libxml2 software library for parsing XML documents because it had not been compiled with these protections.

“I dumped all possible ROP gadgets with 0vercl0k’s rp tool and got to work. I quickly encountered a problem: no matter how I set fieldLength value, it appeared that the overwritten buffer was limited to about 256 bytes. This precluded a traditional GetModuleHandleA > GetProcAddress > VirtualProtect chain, forcing me to try harder to meet this size limit. I began by trying a few optimizations. I moved my final VirtualProtect skeleton before the ROP chain in the buffer, giving me a little more room for my ROP gadgets. For my stack pivot, I used a hard-coded add esp, 0x0C ; ret ; gadget so that I did not have to dynamically create the offset in my chain. Lastly, for the purposes of the proof-of-concept, I decided to simply load WinExec to pop calc.” concludes the expert. “This reduced the number of function calls I needed. With a bit of elbow grease, I was finally able to get my proof-of-concept to work:”

The beta installers that address the issue are available here and the source code that contains the patch is here.

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, OpenOffice)

---