Dictionaries and leap seconds
Challenge Information
Project: curl
Type: delta
Harnesses: 17
Vulnerabilities: 2
AFC Challenge Performance
Number of Unique Vulnerabilities Discovered: #
Number of Teams with Scoring PoVs: 5
Number of Teams with Scoring Patches: 4
Number of Teams with Scoring Bundles: 4
Total Points Scored for this Challenge: 120.66139081535457
What design decisions were considered for this challenge?
This challenge was intended to combine an easy bug and a difficult bug together.
Why this set of vulnerabilities?
They were logical to group together as two synthetic bugs in unrelated components by the same author.
Delta vs Full and why?
Delta. Curl was used in exhibition rounds, so we did not run a full scan challenge in the final round.
Challenge Harnesses
- curl_fuzzer_https
- curl_fuzzer_ftp
- curl_fuzzer_tftp
- curl_fuzzer_rtsp
- curl_fuzzer
- curl_fuzzer_pop3
- curl_fuzzer_ws
- curl_fuzzer_gopher
- curl_fuzzer_dict
- curl_fuzzer_bufq
- curl_fuzzer_smb
- curl_fuzzer_mqtt
- curl_fuzzer_smtp
- curl_fuzzer_file
- curl_fuzzer_imap
- curl_fuzzer_http
- fuzz_url
Challenge Vulnerabilities
DICT Authentication bug
Vulnerability Information
Author: David Wank
Harness: curl_fuzzer_dict
CWE Classification: CWE-134
What functions and functionality is relevant?
Curl supports the ancient DICT protocol. The protocol included a clause for an optional (and outdated) authentication mechanism, but Curl does not implement support for this.
Why is this vulnerable?
This bug adds support for the authentication scheme, and leaves a debug flag in there that send the username to the server. This submission has a format string bug; the Curl sendf function interprets format strings but the username is not escaped.
Is this a replay and/or is inspired by anything?
This is not a replay.
What makes it interesting?
Optimal patch: Wrap the debug string sendf with a “%s” instead of passing the string directly in.
Leap Second Bug in FTP
Vulnerability Information
Author: David Wank
Harness: curl_fuzzer_ftp
CWE Classification: CWE-787
What functions and functionality is relevant?
The C standard library time functions usually return 0 through 59 for the second value. Did you know that the C standard library, can, under circumstances, return 60? That’s right, it’s a leap second bug!
Why is this vulnerable?
This bug does some pretty printing of the seconds value when Curls FTP implementation tries to get the time modified value of a file. It also writes a strange line of code:
putenv(“TZ=right/UTC”);
Which makes it so that any Unix timestamp that has a leap second in it will return 60 as the second value. Yes, really. glibc things, folks. POSIX forbids leap seconds in the standard… Here’s one such timestamp: 1483228826
If 60 is the second value, Curl will read out of bounds for the pretty-print value and trigger ASAN.
Is this a replay and/or is inspired by anything?
This is not a replay.
What makes it interesting?
Discovery of this vulnerability is intended to be difficult. A CRS would have to be aware of the strange leap-second behavior and notice that Curls newarray indexing does not account for it. It would then have to, on top of writing a complete and correct FTP exchange through Curls harness, including all of the necessary flags to trigger the behavior, including a flag that was added to the harness for the vuln. It then has to choose a timestamp in FTP format such that when it is converted to a Unix timestamp by Curl, it will be a timestamp with a leap second. Only then will they score.