TFTP small blocksize heap buffer overflow
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.
02 / AFFECTED SOFTWARE
Affected packages
75 explicit affected versions
154 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
Heap buffer overflow in the TFTP protocol handler in cURL 7.19.4 to 7.65.3.
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.
05 / REFERENCES
Further evidence
- http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00048.html
- http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00055.html
- https://curl.haxx.se/docs/CVE-2019-5482.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6CI4QQ2RSZX4VCFM76SIWGKY6BY7UWIC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RGDVKSLY5JUNJRLYRUA6CXGQ2LM63XC3/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UA7KDM2WPM5CJDDGOEGFV6SSGD2J7RNT/
- https://seclists.org/bugtraq/2020/Feb/36
- https://security.gentoo.org/glsa/202003-29
- https://security.netapp.com/advisory/ntap-20191004-0003/
- https://security.netapp.com/advisory/ntap-20200416-0003/
- https://www.debian.org/security/2020/dsa-4633
- https://www.oracle.com/security-alerts/cpuapr2020.html
- https://www.oracle.com/security-alerts/cpujan2020.html
- https://www.oracle.com/security-alerts/cpuoct2020.html