Littoral Bonsai
Challenge Information
Project: systemd
Type: full
Harnesses: 47
Vulnerabilities: 4
AFC Challenge Performance
Number of Unique Vulnerabilities Discovered: #
Number of Teams with Scoring PoVs: 5
Number of Teams with Scoring Patches: 3
Number of Teams with Scoring Bundles: 4
Total Points Scored for this Challenge: 98.32870269312929
What design decisions were considered for this challenge?
systemd is a large project with many harnesses and extensive functionality. This challenge presents a set of easily fuzzed vulnerabilities that are challenging for an automated system to deduplicate.
Why this set of vulnerabilities?
All of these are trivially fuzzable, and it is possible to trigger one of the four vulnerabilities in at least 8 harnesses. Additionally, two of the bugs are double-frees. The goal is to test the CRS’s ability to identify the actual root cause of the issue and remediate it correctly.
Delta vs Full and why?
Full scan forces the CRS to search broadly for vulnerabilities across a large codebase.
Additional Information
systemd has 50 fuzzing harnesses, 4 of which have trivially fuzzable bugs. This characterizes the CRS’s ability to handle fuzzing resources. All competitors can generate crashing inputs for all synthetic vulnerabilities. Each synthetic tests a different axis of the CRS. systemd-001 can be patched in multiple “good” ways that will remediate the bug but there is only one “correct” answer (that a maintainer would accept). systemd-003 tests knowledge of the C preprocessor. systemd-004 is difficult to deduplicate and is triggerable from at least 4 harnesses. systemd-005 is similar to systemd-001 in that it can be patched in multiple “good” ways that will remediate the single crashing instance of the bug but there is only one “correct” answer (that actually fixes the root cause of the bug) and is triggerable from at least 2 harnesses.
Challenge Harnesses
- fuzz-bcd
- fuzz-bootspec
- fuzz-bus-label
- fuzz-bus-match
- fuzz-bus-message
- fuzz-calendarspec
- fuzz-catalog
- fuzz-compress
- fuzz-dhcp6-client
- fuzz-dhcp-client
- fuzz-dhcp-server
- fuzz-dhcp-server-relay
- fuzz-dns-packet
- fuzz-efi-osrel
- fuzz-efi-printf
- fuzz-efi-string
- fuzz-env-file
- fuzz-etc-hosts
- fuzz-execute-serialize
- fuzz-fido-id-desc
- fuzz-hostname-setup
- fuzz-journald-audit
- fuzz-journald-kmsg
- fuzz-journald-native
- fuzz-journald-native-fd
- fuzz-journald-stream
- fuzz-journald-syslog
- fuzz-journal-remote
- fuzz-json
- fuzz-link-parser
- fuzz-lldp-rx
- fuzz-manager-serialize
- fuzz-ndisc-rs
- fuzz-netdev-parser
- fuzz-network-parser
- fuzz-nspawn-oci
- fuzz-nspawn-settings
- fuzz-resource-record
- fuzz-systemctl-parse-argv
- fuzz-time-util
- fuzz-udev-database
- fuzz-udev-rule-parse-value
- fuzz-udev-rules
- fuzz-unit-file
- fuzz-varlink
- fuzz-varlink-idl
- fuzz-xdg-desktop
Challenge Sarif Broadcast
Target .aixcc/vulns/systemd-004/vuln.yaml
Sarif is correct
PLACEHOLDER FOR SARIFChallenge Vulnerabilities
udev-rule-prefix-matching
Vulnerability Information
Author: nemo
Harness: fuzz-udev-rule-parse-value
CWE Classification: CWE-787
What functions and functionality is relevant?
udev-rule-parse-value in the udev rule parser.
Why is this vulnerable?
Provides a write primitive.
Is this a replay and/or is inspired by anything?
Inspired by how buggy string parsing in C is.
What makes it interesting?
It is a tricky bug to patch “correctly”, the only correct answer is to just use the existing pointer that is tracking the “start” of the rule string and to remove all references to the incorrect one. An AI agent would likely fix this through some other means like bounds checking or more complicated allocations. A maintainer would only accept the correct answer.
Additional Information
systemd-001 implements a new prefix for udev rule strings that will make them prefix match, which would only really be useful to make some bash script autogenerating your rules to be a little easier to write as it is equivalent to just appending a * glob match to the rule.
The bug is triggered if the rule string contains a combination of the newly added prefix string, the escape prefix, and contains duplicates of any of the prefixes. The parser keeps track of where the “start” of the rule string in two ways, which do not agree with each other. One way is a counter in the rule matcher, which will have the correct number to add to the string pointer given any number of prefix rules. The other is adding all of the prefix booleans to the string pointer. This works fine if there are no duplicates but the parser does not check if there are duplicates. Most of the processing uses the latter pointer which ends up returning an invalid input error in most cases which is correct. But in the prefix match + escape string case, the code path uses the other pointer allowing for an arbitrarily long semi-controllable OOB write.
macro_confusion
Vulnerability Information
Author: nemo
Harness: fuzz-catalog
CWE Classification: CWE-122
What functions and functionality is relevant?
The CatalogHeader for the journal catalog.
Why is this vulnerable?
Is essentially a backdoor.
Is this a replay and/or is inspired by anything?
An obfuscated backdoor designed to blend in with legitimate functionality.
What makes it interesting?
This tests whether the AI will identify and remove a block of confusing, irrelevant functionality. AI may also outperform humans at analyzing intentionally confusing macro code and recognizing that it serves no legitimate purpose.
Additional Information
systemd-003 adds a poorly obfuscated backdoor introducing a fairly simple out of bounds write triggered by crafting a specific input dependent on the COUNTER C preprocessor macro; the value of the COUNTER macro is a token containing a monotonically increasing integer for use in macro tokens, but here it has been used as an integer. This makes the value required to trigger the bug dependent on undefined behavior in the C preprocessor.
double-free-list-type
Vulnerability Information
Author: nemo
Harness: fuzz-link-parser
CWE Classification: CWE-415
What functions and functionality is relevant?
condition_free_list_type and anything touching the Condition list.
Why is this vulnerable?
Results in a double-free that can be triggered in several ways.
Is this a replay and/or is inspired by anything?
It is a reimplementation of https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13878
What makes it interesting?
Presents a challenging deduplication problem as it can be trigged by several harnesses. Double frees also have an ambiguous “buggy” location. This makes understanding the actual root cause of the issue very hard for an automated system.
Additional Information
This bug can be triggered by multiple harnesses (fuzz-netdev-parser, fuzz-link-parser, fuzz-network-parser) and in fuzz-unit-file it raises an assert. This is not an exhaustive list, there are potentially more locations that can trigger it.
double-free
Vulnerability Information
Author: nemo
Harness: fuzz-systemctl-parse-argv
CWE Classification: CWE-415
What functions and functionality is relevant?
The freep function as a part of the systemd memory management shared tooling.
Why is this vulnerable?
Results in a double-free that can be triggered in several ways.
Is this a replay and/or is inspired by anything?
This is a reimplementation of https://issues.oss-fuzz.com/issues/42493377
What makes it interesting?
Presents a challenging deduplication problem as it can be trigged by several harnesses. Double frees also have an ambiguous “buggy” location. There is really only one correct way to fix this to conform to the rest of the codebase. This makes understanding the actual root cause of the issue very hard for an automated system.
Additional Information
The systemd freeing functions are expected to reset the cleaned-up variable to NULL. Not doing this causes the destructors to double free.
This is triggerable by at least (fuzz-time-util, fuzz-systemctl-parse-argv)