Incoming details.
CVE-2018-1000120: FTP path trickery leads to NIL byte out of bounds write =========================================================================== curl can be fooled into writing a zero byte out of bounds. This bug can trigger when curl is told to work on an FTP URL, with the setting to only issue a single CWD command (--ftp-method singlecwd or the libcurl alternative CURLOPT_FTP_FILEMETHOD). curl then URL-decodes the given path, calls strlen() on the result and deducts the length of the file name part to find the end of the directory within the buffer. It then writes a zero byte on that index, in a buffer allocated on the heap. If the directory part of the URL contains a "%00" sequence, the directory length might end up shorter than the file name path, making the calculation size_t index = directory_len - filepart_len end up with a huge index variable for where the zero byte gets stored: heap_buffer[index] = 0. On several architectures that huge index will wrap and work as a negative value, thus overwriting memory before the intended heap buffer. By using different file part lengths and putting %00 in different places in the URL, an attacker that can control what paths a curl-using application uses can write that zero byte on different indexes. https://curl.haxx.se/docs/adv_2018-9cd6.html CVE-2018-1000121: LDAP NULL pointer dereference =========================================================================== curl might dereference a near-NULL address when getting an LDAP URL. The function ldap_get_attribute_ber() is called to get attributes, but it turns out that it can return LDAP_SUCCESS and still return a NULL pointer in the result pointer when getting a particularly crafted response. This was a surprise to us and to the code. libcurl-using applications that allow LDAP URLs, or that allow redirects to LDAP URLs could be made to crash by a malicious server. https://curl.haxx.se/docs/adv_2018-97a2.html CVE-2018-1000122: RTSP RTP buffer over-read =========================================================================== curl can be tricked into copying data beyond end of its heap based buffer. When asked to transfer an RTSP URL, curl could calculate a wrong data length to copy from the read buffer. The memcpy call would copy data from the heap following the buffer to a storage area that would subsequently be delivered to the application (if it didn't cause a crash). We've managed to get it to reach several hundreds bytes out of range. This could lead to information leakage or a denial of service for the application if the server offering the RTSP data can trigger this. https://curl.haxx.se/docs/adv_2018-b047.html
Please note that curl-7.59.0 (latest version addressing the above issues) is on the tree. Its ready for rapid stabilization: KEYWORDS="alpha amd64 arm arm64 hppa ia64 ppc ppc64 sparc x86"
amd64 stable
alpha stable
ppc/ppc64 stable
x86 stable
ia64 stable
arm64 stable
hppa stable
arm stable, all arches done.
GLSA request filed. sparc was not CC'ed so giving them a chance.
This issue was resolved and addressed in GLSA 201804-04 at https://security.gentoo.org/glsa/201804-04 by GLSA coordinator Aaron Bauman (b-man).
Re-opened for cleanup and hopefully sparc can stabilize.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=de11a48ccc58edcc85ec60d95049595535957c2e commit de11a48ccc58edcc85ec60d95049595535957c2e Author: Rolf Eike Beer <eike@sf-mail.de> AuthorDate: 2018-04-11 17:38:25 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-04-11 21:21:52 +0000 net-misc/curl: stable 7.59.0 for sparc Bug: https://bugs.gentoo.org/650056 Package-Manager: Portage-2.3.24, Repoman-2.3.6 RepoMan-Options: --include-arches="sparc" net-misc/curl/curl-7.59.0.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)}
CC'ing exp arches due to the importance of curl.
cleanup will happen in bug 655266
