TFTP small blocksize heap buffer overflow
Project curl Security Advisory, September 11th 2019 - Permalink
libcurl contains a heap buffer overflow in the function
tftp_receive_packet()) that receives data from a TFTP server. It can call
recvfrom() with the default size for the buffer rather than with the size
that was used to allocate it. Thus, the content that might overwrite the heap
memory is controlled by the server.
This flaw is only triggered if the TFTP server sends an OACK without the BLKSIZE option, when a BLKSIZE smaller than 512 bytes was requested by the TFTP client. OACK is a TFTP extension and is not used by all TFTP servers.
Users choosing a smaller block size than default should be rare as the primary use case for changing the size is to make it larger.
It is rare for users to use TFTP across the Internet. It is most commonly used within local networks. TFTP as a protocol is always inherently insecure.
This issue was introduced by the add of the TFTP BLKSIZE option handling. It was previously incompletely fixed by an almost identical issue called CVE-2019-5436.
We are not aware of any exploit of this flaw.
This bug was introduced in January 2009 in commit 0516ce7786e9500c2e44.
The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2019-5482 to this issue.
CWE-122: Heap-based Buffer Overflow
Severity: 5.2 (Medium)
- Affected versions: libcurl >= 7.19.4 to and including 7.65.3
- Not affected versions: libcurl < 7.19.4
libcurl is used by many applications, but not always advertised as such.
We suggest you take one of the following actions immediately, in order of preference:
A - Upgrade curl to version 7.66.0
B - Apply the patch to your version and rebuild
C - do not use TFTP with curl with smaller than the default BLKSIZE
The issue was reported to the curl project on August 29, 2019. The fix was done, verified and communicated with the reporter on September 2, 2019.
We contacted distros@openwall on September 5.
This advisory was posted on September 11th 2019.
Reported and patched by Thomas Vegas.
Thanks a lot!