# All Your (d)Base Are Belong To Us, Part 1: Code Execution in Apache OpenOffice (CVE-2021-33035)

Apache OpenOffice DBF parser memcpy'd attacker-controlled fieldLength into a 4-byte sal_Int32, yielding stack buffer overflow and code execution via ROP.

- Payout: Research
- Severity: high
- Program: Apache OpenOffice
- Write-up by: Eugene Lim
- Disclosed: 2021-09-29
- CVE: CVE-2021-33035
- Write-up quality: 8/10
- Original: https://spaceraccoon.dev/all-your-d-base-are-belong-to-us-part-1-code-execution-in-apache-openoffice/
- Library page: https://bugbountylibrary.com/r/blog%3Aspaceraccoon-dev-all-your-d-base-are-belong-to-us-part-1-code-execution-in-apache-openoffice
- Tags: area:os domain:desktop impact:rce kind:research platform:research sev:high tech:windows technique:fuzzing technique:reverse-engineering technique:source-review vuln:memory-corruption vuln:rce

**Target:** DBF file parser in OpenOffice Calc (dbase module)
**Root cause:** The DBF parser allocates a fixed-size sal_Int32 (4 bytes) for INTEGER fields but memcpy's nLen bytes where nLen comes from the attacker-controlled fieldLength header, with no bounds check.
**Steps:**
1. Craft DBF header with field type 'I' (INTEGER) and fieldLength > 4 (e.g. 255).
2. Place payload bytes in the record data; parser memcpy overflows the 4-byte stack buffer.
3. Observe crash in OpenOffice Calc; SEH overwrite occurs but SAFESEH blocks handler.
4. Trace validation check (cmp edi,eax in dbase+0x2f87); set the checked offset to 0x00000001 to pass.
5. Use libxml2.dll (no ASLR/DEP) as ROP gadget source; keep chain under ~256 bytes.
6. Stack pivot via `add esp, 0x0C ; ret`, then WinExec to pop calc.
**How found:** Chose DBF as under-researched format; dumb-fuzzed small DBF viewers with Peach, found SEH overwrite caused by undocumented fieldType '2' where fieldLength exceeded the 2-byte short int buffer. Generalized hypothesis: buffer size determined by fieldType but copy size by fieldLength. Grepped OpenOffice source for the same memcpy pattern and found INTEGER branch copying nLen into sal_Int32.
**Exploitation:** Local file-open exploitation: victim opens malicious .dbf in OpenOffice Calc; overflow overwrites return pointer, ROP chain built from non-ASLR libxml2 gadgets pivots stack and calls WinExec to execute arbitrary code.
**Escalation:** Chained dumb-fuzzing insight (fieldLength vs fieldType mismatch) into source review of OpenOffice, then bypassed SAFESEH/ASLR/DEP via unprotected libxml2 module.
**Insight:** When a format has two size descriptors (fieldType vs fieldLength), hunt for code that allocates by one and copies by the other; also check LGTM/CodeQL coverage — OpenOffice was indexed only as Python/JS so its C++ was never scanned.