curl security problems:
CVE-2019-5481: FTP-KRB double-free libcurl can be told to use kerberos over FTP to a server, as set with the CURLOPT_KRBLEVEL option. During such kerberos FTP data transfer, the server sends data to curl in blocks with the 32 bit size of each block first and then that amount of data immediately following. A malicious or just broken server can claim to send a very large block and if by doing that it makes curl's subsequent call to realloc() to fail, curl would then misbehave in the exit path and double-free the memory. In practical terms, an up to 4 GB memory area may very well be fine to allocate on a modern 64 bit system but on 32 bit systems it will fail. Kerberos FTP is a rarely used protocol with curl. Also, Kerberos authentication is usually only attempted and used with servers that the client has a previous association with. CVE-2019-5482: 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.