Arch Assembly Full
Challenge Information
Project: apache-poi
Type: full
Harnesses: 17
Vulnerabilities: 5
AFC Challenge Performance
Number of Unique Vulnerabilities Discovered: #
Number of Teams with Scoring PoVs: 5
Number of Teams with Scoring Patches: 0
Number of Teams with Scoring Bundles: 0
Total Points Scored for this Challenge: 24.18656332257654
What design decisions were considered for this challenge?
The straightforward backdoors (vuln_3 and vuln_4) are placed in a full repo scan, where they blend naturally into the larger codebase and test a CRS’s ability to identify injected code across a broad surface area.
The resource consumption vulnerabilities suit the legacy codebase audit use case.
The organic zip slip belongs in a full scan because it is a real pre-existing bug in this codebase, not part of a recent new feature pull request.
Why this set of vulnerabilities?
They represent a range of types of vulnerabilities throughout the code base and across formats.
Delta vs Full and why?
Full scan is the right fit for these vulnerabilities. The backdoors benefit from a larger codebase context, the resource consumption issues suit a legacy audit scenario, and the organic zip slip is a real pre-existing bug rather than a new feature change.
Challenge Harnesses
- EncryptDecryptFuzzer
- POIHMEFFuzzer
- POIHSLFFuzzer
- POIHWPFFuzzer
- POIVisioFuzzer
- POIXWPFFuzzer
- POIFuzzer
- POIHPBFFuzzer
- POIHSMFFuzzer
- POIOldExcelFuzzer
- POIXSLFFuzzer
- XLSX2CSVFuzzer
- POIHDGFFuzzer
- POIHPSFFuzzer
- POIHSSFFuzzer
- POIPOIFSDumpFuzzer
- POIXSSFFuzzer
Challenge Timeouts
enabled
Challenge Sarif Broadcast
Target .aixcc/vulns/vuln_2/vuln.yaml
Sarif is correct
PLACEHOLDER FOR SARIFChallenge Vulnerabilities
Infinite reading challenges
Vulnerability Information
Author: Tim Allison
Harness: POIHMEFFuzzer
CWE Classification: CWE-834 , CWE-20
What functions and functionality is relevant?
Parsing MAPI attributes in Transport Neutral Encapsulation Format (TNEF/winmail.dat).
Why is this vulnerable?
The vulnerability removes two checks designed to limit resource utilization.
1) The number of records is read from the user generated input without bounds checking
2) The read and skips on the input stream are not checked for end-of-file.
Is this a replay and/or is inspired by anything?
This is an incidental replay. After developing the vulnerability, Apache POI’s existing unit test with oom.tnef was found to cause an OOM with the changes introduced in this vuln. This vulnerability had likely already been found via fuzzing.
What makes it interesting?
The complexity of the two features working together. Also, this file format is not exceedingly common.
Read then allocate OutOfMemoryError
Vulnerability Information
Author: Tim Allison
Harness: POIHMEFFuzzer
CWE Classification: CWE-789 , CWE-770 , CWE-20
What functions and functionality is relevant?
Parsing MAPI attributes in Transport Neutral Encapsulation Format (TNEF/winmail.dat).
Why is this vulnerable?
Failure to reasonably limit record size, which is specified by user-controlled input.
Is this a replay and/or is inspired by anything?
Read-length-then-allocate memory use vulnerabilities are extremely common in non-OOXML Microsoft formats (and several others). There wasn’t a specific CVE associated with this vulnerability, but we did go through the code base and try to add heuristic limits any time we saw an allocation of a byte array based on a length read from the file on issue 61349: https://bz.apache.org/bugzilla/show_bug.cgi?id=61349
What makes it interesting?
Although the format is not exceedingly common, it should be easy to find via fuzzing, and an arbitrary limit should be fairly easy to add
Path Traversal Olé
Vulnerability Information
Author: Tim Allison
Harness: POIPOIFSDumpFuzzer
CWE Classification: CWE-35 , CWE-20
What functions and functionality is relevant?
This affects a tool for developers that extracts the contents of OLE2 files.
Why is this vulnerable?
There’s no check on the file name within the OLE2 container, and the file is then extracted based on the user-generated file name, which opens a path traversal vulnerability.
Is this a replay and/or is inspired by anything?
This is an organic vulnerability, discovered by analyzing zip slip patterns in Apache POI based on experience with similar patterns in commons-compress and Apache Tika.
What makes it interesting?
Generating the POV for this is non-trivial. This is similar to other path traversal vulns in other repos in the challenges in semi-finals and finals. Notably, this is an organic vulnerability — no LLM could have “memorized” a bug report for it.
Additional details
The code required minor modifications for the competition harness. This is an organic vulnerability.
Crashy McCrashFace.xls
Vulnerability Information
Author: Tim Allison
Harness: POIHSSFFuzzer
CWE Classification: CWE-695 , CWE-20
What functions and functionality is relevant?
Parsing an XLS file.
Why is this vulnerable?
This is a backdoor crash triggered by a sheet name in an xls file.
Is this a replay and/or is inspired by anything?
Not a replay.
What makes it interesting?
As with the xlsx challenge (vuln_4), this should be an entry-level/simple fix. Simply remove the backdoor. Generating a proof of vulnerability requires fairly deep knowledge of the xlsx format or (better) simply using an existing XLS generation library.
Additional details
This challenge also validates that Jazzer correctly reports JVM crashes.
Crashy McCrashFace.xlsx
Vulnerability Information
Author: Tim Allison
Harness: POIXSSFFuzzer
CWE Classification: CWE-382
What functions and functionality is relevant?
Parsing an xlsx file.
Why is this vulnerable?
This is a backdoor Runtime.halt triggered by a sheet name in an xlsx file.
Is this a replay and/or is inspired by anything?
Not a replay. It was inspired by a System.exit() found in Apache Tika during our early experiments with fuzzing: https://www.cve.org/CVERecord?id=CVE-2020-9489
What makes it interesting?
As with the xls challenge (vuln_3), this should be an entry-level/simple fix. Simply remove the backdoor. Generating a proof of vulnerability requires fairly deep knowledge of the xls format or (better) simply using an existing XLS generation library.
Additional details
This challenge also validates that Jazzer correctly reports System.exit and Runtime.halt calls.