
====================================================================

                             CERT-Renater

                 Note d'Information No. 2019/VULN274

_____________________________________________________________________

DATE                : 11/09/2019

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running libcurl versions 7.19.4 up to and
                                  including 7.65.3.

=====================================================================
https://curl.haxx.se/docs/CVE-2019-5481.html
_____________________________________________________________________

FTP-KRB double-free
===================

Project curl Security Advisory, September 11th 2019 -
[Permalink](https://curl.haxx.se/docs/CVE-2019-5481.html)

VULNERABILITY
-------------

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.

We are not aware of any exploit of this flaw.

INFO
----

This bug was introduced in November 2016 in [commit
0649433da53c7165f839e2](https://github.com/curl/curl/commit/0649433da53c7165f839e2).

The Common Vulnerabilities and Exposures (CVE) project has assigned the
name CVE-2019-5481 to this issue.

CWE-415: Double Free

Severity: 6.3 (Medium)


AFFECTED VERSIONS
-----------------

- Affected versions: libcurl >= 7.52.0 to and including 7.65.3
- Not affected versions: libcurl < 7.52.0

libcurl is used by many applications, but not always advertised as such.

THE SOLUTION
------------

A [fix for
CVE-2019-5481](https://github.com/curl/curl/commit/9069838b30fb3b48af0123e39f664cea683254a5)

RECOMMENDATIONS
--------------

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 `CURLOPT_KRBLEVEL`


TIMELINE
--------

The issue was reported to the curl project on September 3, 2019. The
fix was done, verified and communicated with the reporter on September
3, 2019.

We contacted distros@openwall on September 5.

This advisory was posted on September 11th 2019.


CREDITS
-------

Reported by Thomas Vegas. Patch by Daniel Stenberg.

Thanks a lot!



 / daniel.haxx.se | Get the best commercial curl support there is -
                    from me
                  | Private help, bug fixes, support, ports, new
                    features
                  | https://www.wolfssl.com/contact/

_____________________________________________________________________

TFTP small blocksize heap buffer overflow
=========================================

Project curl Security Advisory, September 11th 2019 -
[Permalink](https://curl.haxx.se/docs/CVE-2019-5482.html)

VULNERABILITY
-------------

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.

INFO
----

This bug was introduced in January 2009 in [commit
0516ce7786e9500c2e44](https://github.com/curl/curl/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
-----------------

- 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.

THE SOLUTION
------------

A [fix for
CVE-2019-5482](https://github.com/curl/curl/commit/facb0e4662415b5f28163e853dc6742ac5fafb3d)


RECOMMENDATIONS
--------------

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


TIMELINE
--------

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.


CREDITS
-------

Reported and patched by Thomas Vegas.


Thanks a lot!




 / daniel.haxx.se | Get the best commercial curl support there is -
                    from me
                  | Private help, bug fixes, support, ports, new
                    features
                  | https://www.wolfssl.com/contact/

=========================================================
+ CERT-RENATER        | tel : 01-53-94-20-44            +
+ 23/25 Rue Daviel    | fax : 01-53-94-20-41            +
+ 75013 Paris         | email:cert@support.renater.fr   +
=========================================================



