From f49df54a36a39995be32782154f3ca2692f17ac4 Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Tue, 6 Dec 2005 23:05:51 +0000 Subject: 7.15.1 with the now to be announced security flaw fixed --- CHANGES | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) (limited to 'CHANGES') diff --git a/CHANGES b/CHANGES index b1cad112b..5a8496d6f 100644 --- a/CHANGES +++ b/CHANGES @@ -8,6 +8,39 @@ +Version 7.15.1 (7 December 2005) + +Daniel (6 December 2005) +- Full text here: http://curl.haxx.se/docs/adv_20051207.html Pointed out by + Stefan Esser. + + VULNERABILITY + + libcurl's URL parser function can overflow a malloced buffer in two ways, if + given a too long URL. + + These overflows happen if you + + 1 - pass in a URL with no protocol (like "http://") prefix, using no slash + and the string is 256 bytes or longer. This leads to a single zero byte + overflow of the malloced buffer. + + 2 - pass in a URL with only a question mark as separator (no slash) between + the host and the query part of the URL. This leads to a single zero byte + overflow of the malloced buffer. + + Both overflows can be made with the same input string, leading to two single + zero byte overwrites. + + The affected flaw cannot be triggered by a redirect, but the long URL must + be passed in "directly" to libcurl. It makes this a "local" problem. Of + course, lots of programs may still pass in user-provided URLs to libcurl + without doing much syntax checking of their own, allowing a user to exploit + this vulnerability. + + There is no known exploit at the time of this writing. + + Daniel (2 December 2005) - Jamie Newton pointed out that libcurl's file:// code would close() a zero file descriptor if given a non-existing file. -- cgit v1.2.3