Tuesday, November 5, 2024
Latest:
The Register 

Apache OpenOffice can be hijacked by malicious documents, fix still in beta

TH Author

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.

That means that most people running the open source office suite, which has been downloaded hundreds of millions of times and was last updated in May, probably have vulnerable versions of the software.

On Saturday, September 18, security researcher Eugene Lim revealed details about the vulnerability (CVE-2021-33035) at HackerOne’s Hacktivity online conference after an August 30 public disclosure date came and went without the fix being fully deployed.

Lim, known online as SpaceRacoon, is a vulnerability researcher at Gulf Tech Singapore’s cybersecurity group. CVE-2021-33035, he explained, “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.” That means a malicious file opened by the software can execute malware on the machine.

Lim found the flaw after examining the .dbf file format, which first appeared as part of the dBase II application in 1983, and setting up a template to fuzz the format – inject data into the stack in the hope of causing a crash.

What he found was that the .dbf file format can use one of two values in its header – fieldLength or fieldType – to determine the buffer size of a database record. So it’s possible to allocate a buffer using one and to use the other to set the size of a copy operation into that buffer, leading to a buffer overflow.

OpenOffice’s .dbf parsing code looked like this:

else if ( DataType::INTEGER == nType ) { sal_Int32 nValue = 0; memcpy(&nValue, pData, nLen); *(_rRow->get())[i] = nValue; }

“Here, we can see a buffer nValue of size sal_Int32 (4 bytes) being instantiated for a field of type INTEGER,” explained Lim in a blog post. “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.”

Revising his previous payload generator to the integer fieldType (I), he increased the size of fieldLength to greater than sal_Int32, and was able to launch a proof-of-concept attack that consisted of opening the file in OpenOffice Calc and causing a crash.

To fully exploit this and achieve reliable code execution, on Windows at least, Lim had to bypass DEP and ASLR. To do so, he looked for imported modules that had not been compiled with those protections and found libxml2, a software library for parsing XML documents.

“So I could use this library as a starting point for a return-oriented programming chain, or ROP chain, in order to bypass DEP eventually,” he said.

ROP, as Lim explained, is a technique that chains together snippets of code that resides within an application’s memory – like cutting out letters from newspapers and magazines to spell out a sentence, but in this case it’s lining up software instructions to execute – until a specific goal has been accomplished. Because the overwritten pointer he’d obtained offered only about 256 bytes to work with, his ROP chain became GetModuleHandleA and then GetProcAddress to locate the WinExec code to execute his own shell commands. At this point, he can run whatever he wants on the victim’s machine.

Lim in his post said that he wondered why this hadn’t been caught and noticed that GitHub’s LGTM automated security scan for open-source projects has Apache OpenOffice tagged for Python and JavaScript but not C++.

“Browsing the files on LGTM, I noticed that there were no C++ files included,” he observed. “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 said the vulnerability also affected Scalabium dBase Viewer (CVE-2021–35297) and because that project was run by a single developer the fix was quick. With Apache OpenOffice, which has struggled to sustain itself in recent years, the initial disclosure occurred on May 4 and with any luck the fix will be finalized before the end of September.

“The Apache OpenOffice Project Management Committee (PMC) are in regular communication with Eugene Lim, who has confirmed our fix and has committed to point users to the beta patch,” said Dave Fisher, on behalf of the Apache OpenOffice PMC, in a statement emailed to The Register. “We endeavor to roll the release for Apache OpenOffice 4.1.11 within the month, hopefully sooner, and publish the CVE-2021-33035 before the release.”

For those disinclined to wait, the beta installers can be found here and the source code has been patched. ®

READ MORE HERE