curl versions between 7.10.5 and 7.19.7 inclusive contains security flaw than can cause buffer overflow in an application. The application must download compressed data, must request in-library decompression and must rely on compile-time constant CURL_MAX_WRITE_SIZE.
Upstream provides patch and new unaffected version 7.20.0.
Steps to Reproduce:
Please provide an updated ebuild.
Created attachment 224071 [details, diff]
Security patch released by upstream
This FILESDIR file fixes bug in <=curl-7.19*
Created attachment 224073 [details, diff]
Fix for 7.19*
Updated ebuild for curl-7.19*. Requires files/libcurl-contentencoding.patch.
~net-misc/curl-7.20.0 has been put into portage meanwhile. These ebuilds are not affected.
Is it ok to go stable?
(In reply to comment #5)
> Is it ok to go stable?
If it's question to me, then I'll say I have no problem (net-misc/curl-7.20.0-r1 (idn ipv6 ssl) on x86).
According libcurl mailing list, there are some issues on win32, Darwin, VMS and OS400. However no Linux or functionality issues specific for this release.
(In reply to comment #6)
> (In reply to comment #5)
> > Is it ok to go stable?
> If it's question to me, then I'll say I have no problem
It was targeted at the maintainers of the curl package. So unless you are one, no. Thanks for your input anyway.
dragonheart, is it ok to go stable?
Sorry folks been really busy. Thanks Petr for looking up the background info.
Based on what I've seen and trust in the upstream developer I'm happy for 7.20.0-r1 to go stable.
Also happy for backported patches to be added.
content_encoding.c in libcurl 7.10.5 through 7.19.7, when zlib is
enabled, does not properly restrict the amount of callback data sent
to an application that requests automatic decompression, which might
allow remote attackers to cause a denial of service (application
crash) or have unspecified other impact by sending crafted compressed
data to an application that relies on the intended data-length limit.
Remaining arches, please stabilize ASAP.
Thanks, folks. GLSA request filed.
This issue was resolved and addressed in
GLSA 201203-02 at http://security.gentoo.org/glsa/glsa-201203-02.xml
by GLSA coordinator Sean Amoss (ackle).