From ${URL} : 1. VULNERABILITY libcurl is vulnerable to a case of bad checking of the input data which may lead to heap corruption. The function curl_easy_unescape() decodes URL encoded strings to raw binary data. URL encoded octets are represented with %HH combinations where HH is a two-digit hexadecimal number. The decoded string is written to an allocated memory area that the function returns to the caller. The function takes a source string and a length parameter, and if the length provided is 0 the function will instead use strlen() to figure out how much data to parse. The "%HH" parser wrongly only considered the case where a zero byte would terminate the input. If a length-limited buffer was passed in which ended with a '%' character which was followed by two hexadecimal digits outside of the buffer libcurl was allowed to parse alas without a terminating zero, libcurl would still parse that sequence as well. The counter for remaining data to handle would then be decreased too much and wrap to become a very large integer and the copying would go on too long and the destination buffer that is allocated on the heap would get overwritten. We consider it unlikely that programs allow user-provided strings unfiltered into this function. Also, only the not zero-terminated input string use case is affected by this flaw. Exploiting this flaw for gain is probably possible for specific circumstances but we consider the general risk for this to be low. The curl command line tool is not affected by this problem as it doesn't use this function. There are no known exploits available at this time. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2013-2174 to this issue. 2. AFFECTED VERSIONS Affected versions: from libcurl 7.7 to and including 7.30.0 Not affected versions: libcurl before 7.7 and >= 7.31.0 libcurl is used by many applications, but not always advertised as such! 3. THE SOLUTION libcurl 7.31.0 implements a proper check that the following hexdigits are within the provided input length. 4. RECOMMENDATIONS We suggest you take one of the following actions immediately, in order of preference: A - Upgrade to curl and libcurl 7.31.0 B - Apply this patch and rebuild libcurl http://curl.haxx.se/libcurl-unescape.patch C - Double-check your curl_easy_unescape() usage (for example use it with the 'length' argument set to 0), or avoid using that function 5. TIME LINE Vulnerability found by Timo Sirainen. Patched by Daniel Stenberg. It was reported to the curl project on May 19th 2013. We contacted linux-distros on June 12th. curl 7.31.0 was released on June 22nd 2013, coordinated with the publication of this advisory. 6. CREDITS Reported by Timo Sirainen. Thanks a lot! @maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.
7.31.0 is currently in the tree.
Arches, please stabilize =net-misc/curl-7.31.0, target arches: alpha amd64 arm ppa ia64 ppc ppc64 s390 sh sparc x86. Thanks!
(In reply to Chris Reffett from comment #2) > Arches, please stabilize =net-misc/curl-7.31.0, target arches: alpha amd64 > arm ppa ia64 ppc ppc64 s390 sh sparc x86. Thanks! Good idea. It seems to be working fine.
(In reply to Chris Reffett from comment #2) > Arches, please stabilize =net-misc/curl-7.31.0, target arches: alpha amd64 > arm ppa ia64 ppc ppc64 s390 sh sparc x86. Thanks! the arch teams were never cc-ed
(In reply to Anthony Basile from comment #4) > (In reply to Chris Reffett from comment #2) > > Arches, please stabilize =net-misc/curl-7.31.0, target arches: alpha amd64 > > arm ppa ia64 ppc ppc64 s390 sh sparc x86. Thanks! > > the arch teams were never cc-ed stable ppc ppc64
amd64 stable
alpha stable
sparc stable
x86 stable
arm stable
CVE-2013-2174 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-2174): Heap-based buffer overflow in the curl_easy_unescape function in lib/escape.c in cURL and libcurl 7.7 through 7.30.0 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted string ending in a "%" (percent) character.
s390 stable
sh stable
Added to existing GLSA draft
(In reply to Sergey Popov from comment #14) > Added to existing GLSA draft Should I be removing <net-misc/curl-7.31.0 yet?
Yes please.
(In reply to Chris Reffett from comment #16) > Yes please. Massive cleanup!
*** Bug 489852 has been marked as a duplicate of this bug. ***
Stable for HPPA.
And another one.
(In reply to Chris Reffett from comment #16) > Yes please. No, it wasn't stable on ia64 and autobuilds got broken. Please be more careful people, I have restored curl-7.30.0.
*** Bug 490336 has been marked as a duplicate of this bug. ***
(In reply to Rick Farina (Zero_Chaos) from comment #21) > (In reply to Chris Reffett from comment #16) > > Yes please. > > No, it wasn't stable on ia64 and autobuilds got broken. > > Please be more careful people, I have restored curl-7.30.0. You should have dropped the keywords on 7.30.0 from KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 s390 sh sparc x86 ~ppc-aix ~amd64-fbsd ~sparc-fbsd ~x86-fbsd ~x64-freebsd ~x86-freebsd ~hppa-hpux ~ia64-hpux ~x86-interix ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris" to KEYWORDS="ia64" since we only need it for that arch. I'll commit this change if there are no objectins.
(In reply to Anthony Basile from comment #23) > You should have dropped the keywords on 7.30.0 from > > KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 s390 sh sparc x86 > ~ppc-aix ~amd64-fbsd ~sparc-fbsd ~x86-fbsd ~x64-freebsd ~x86-freebsd > ~hppa-hpux ~ia64-hpux ~x86-interix ~amd64-linux ~arm-linux ~x86-linux > ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris > ~x64-solaris ~x86-solaris" > > to > > KEYWORDS="ia64" no objections, but due to visibility this makes pretty much no difference as portage is going to take the higher stable version anyway. In reality it is not common practice to remove keywords from an older ebuild as they are added stable to the newer one, even if it is a security bug.
(In reply to Rick Farina (Zero_Chaos) from comment #24) > no objections, but due to visibility this makes pretty much no difference as > portage is going to take the higher stable version anyway. In reality it is > not common practice to remove keywords from an older ebuild as they are > added stable to the newer one, even if it is a security bug. True, but another way would be masking on every arch and unmask on ia64. I think this keywording trick is better for this case.
ia64 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
Added to existing GLSA draft. Pleaser remove vulnerable versions (cleanup)
(In reply to Yury German from comment #27) > Added to existing GLSA draft. > > Pleaser remove vulnerable versions (cleanup) <net-misc/curl-7.31.0 is off the tree.
This issue was resolved and addressed in GLSA 201401-14 at http://security.gentoo.org/glsa/glsa-201401-14.xml by GLSA coordinator Sergey Popov (pinkbyte).
