FreeBSD: VID-9FB4E57B-D65A-11E9-8A5F-E5C82B486287 (CVE-2019-5481): curl -- multiple vulnerabilities

Description

Details for this vulnerability have not been published by NIST at this point. Descriptions from software vendor advisories for this issue are provided below.

From VID-9FB4E57B-D65A-11E9-8A5F-E5C82B486287:

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.