FTP path trickery leads to NIL byte out of bounds write
curl can be fooled into writing a zero byte out of bounds. This bug can trigger when curl is told to work on an FTP URL, with the setting to only issue a single CWD command (`--ftp-method singlecwd` or the libcurl alternative `CURLOPT_FTP_FILEMETHOD`). curl then URL-decodes the given path, calls strlen() on the result and deducts the length of the filename part to find the end of the directory within the buffer. It then writes a zero byte on that index, in a buffer allocated on the heap. If the directory part of the URL contains a "%00" sequence, the directory length might end up shorter than the filename path, making the calculation `size_t index = directory_len - filepart_len` end up with a huge index variable for where the zero byte gets stored: `heap_buffer[index] = 0`. On several architectures that huge index wraps and works as a negative value, thus overwriting memory *before* the intended heap buffer. By using different file part lengths and putting %00 in different places in the URL, an attacker that can control what paths a curl-using application uses can write that zero byte on different indexes.
02 / AFFECTED SOFTWARE
Affected packages
92 explicit affected versions
185 explicit affected versions
2 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
A buffer overflow exists in curl 7.12.3 to and including curl 7.58.0 in the FTP URL handling that allows an attacker to cause a denial of service or worse.
curl can be fooled into writing a zero byte out of bounds. This bug can trigger when curl is told to work on an FTP URL, with the setting to only issue a single CWD command (`--ftp-method singlecwd` or the libcurl alternative `CURLOPT_FTP_FILEMETHOD`). curl then URL-decodes the given path, calls strlen() on the result and deducts the length of the filename part to find the end of the directory within the buffer. It then writes a zero byte on that index, in a buffer allocated on the heap. If the directory part of the URL contains a "%00" sequence, the directory length might end up shorter than the filename path, making the calculation `size_t index = directory_len - filepart_len` end up with a huge index variable for where the zero byte gets stored: `heap_buffer[index] = 0`. On several architectures that huge index wraps and works as a negative value, thus overwriting memory *before* the intended heap buffer. By using different file part lengths and putting %00 in different places in the URL, an attacker that can control what paths a curl-using application uses can write that zero byte on different indexes.
curl can be coerced into writing a zero byte out of bounds. This bug can trigger when curl is told to work on an FTP URL, with the setting to only issue a single CWD command (--ftp-method singlecwd or the libcurl alternative [CURLOPT_FTP_FILEMETHOD](https://curl.se/libcurl/c/CURLOPT_FTP_FILEMETHOD.html)). curl then URL-decodes the given path, calls strlen() on the result and deducts the length of the file name part to find the end of the directory within the buffer. It then writes a zero byte on that index, in a buffer allocated on the heap. If the directory part of the URL contains a `%00` sequence, the directory length might end up shorter than the file name path, making the calculation `size_t index = directory_len - filepart_len` end up with a huge index variable for where the zero byte gets stored: `heap_buffer[index] = 0`. On several architectures that huge index will wrap and work as a negative value, thus overwriting memory before the intended heap buffer. By using different file part lengths and putting the string `%00` in different places in the URL, an attacker that can control what paths a curl-using application uses can write that zero byte on different indexes.
05 / REFERENCES
Further evidence
- http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html
- http://www.oracle.com/technetwork/security-advisory/cpuoct2018-4428296.html
- http://www.securityfocus.com/bid/103414
- http://www.securitytracker.com/id/1040531
- https://access.redhat.com/errata/RHBA-2019:0327
- https://access.redhat.com/errata/RHSA-2018:3157
- https://access.redhat.com/errata/RHSA-2018:3558
- https://access.redhat.com/errata/RHSA-2019:1543
- https://access.redhat.com/errata/RHSA-2020:0544
- https://access.redhat.com/errata/RHSA-2020:0594
- https://curl.haxx.se/docs/adv_2018-9cd6.html
- https://lists.debian.org/debian-lts-announce/2018/03/msg00012.html
- https://usn.ubuntu.com/3598-1/
- https://usn.ubuntu.com/3598-2/
- https://www.debian.org/security/2018/dsa-4136
- https://www.oracle.com/technetwork/security-advisory/cpujan2019-5072801.html
- https://www.oracle.com/technetwork/security-advisory/cpujul2019-5072835.html
- https://www.oracle.com/technetwork/security-advisory/cpuoct2019-5072832.html
- https://curl.se/docs/CVE-2018-1000120.html
- https://github.com/coapp-packages/curl
- https://nvd.nist.gov/vuln/detail/CVE-2018-1000120
- https://usn.ubuntu.com/3598-1
- https://usn.ubuntu.com/3598-2
- https://web.archive.org/web/20201220134105/http://www.securitytracker.com/id/1040531
- https://web.archive.org/web/20201220134609/http://www.securityfocus.com/bid/103414