|Summary:||<net-libs/libproxy-0.4.10 : buffer overflow vulnerability (CVE-2012-4504)|
|Product:||Gentoo Security||Reporter:||Agostino Sarubbo <ago>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Package list:||Runtime testing required:||---|
Description Agostino Sarubbo 2012-10-12 16:24:58 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-4505 An insufficient input validation flaw, leading to a heap-based buffer overflow was found in libproxy 0.3.x in the px_pac_reload() function. libproxy allocates a memory to store downloaded proxy.pac proxy auto-configuration file content using the Content-Length size from the remote server's HTTP response header. Allocation size is content length + 1. A malicious host hosting proxy.pac, or a man in the middle attacker, could use this flaw to make libproxy allocate insufficient amount of memory and subsequently overflow a heap-based buffer. http://code.google.com/p/libproxy/source/browse/tags/libproxy-0.3.1/src/lib/pac.c#165 165 self->cache = px_malloc0(content_length+1); 166 for (int recvd=0 ; recvd != content_length ; ) 167 recvd += recv(sock, self->cache + recvd, content_length - recvd, 0); This issue was confirmed with libproxy 0.3.x. Earlier 0.2.x versions seems to be affected too. It does not affect 0.4.x versions, where fixed size buffer is used. https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-4504 A buffer overflow flaw was discovered in the libproxy's url::get_pac() used to download proxy.pac proxy auto-configuration file. A malicious host hosting proxy.pac, or a man in the middle attacker, could use this flaw to trigger a stack-based buffer overflow in an application using libproxy, if proxy configuration instructed it to download proxy.pac file from a remote HTTP server. url::get_pac() uses a fixed size buffer buffer to store content of the proxy.pac file downloaded from a remote server. When filling the buffer, it uses server-supplied content length value, rather than size buffer, as a limit for the size of the input copied into the buffer. Overflow occurs when server provides sufficiently large file and does not use chunked content encoding. The buffer size is checked when using chunked encoding. http://code.google.com/p/libproxy/source/browse/trunk/libproxy/url.cpp?r=846#462 This issue was introduced upstream with the addition of the chunked encoding support, which first appears in version 0.4. http://code.google.com/p/libproxy/source/detail?r=489 http://code.google.com/p/libproxy/issues/detail?id=77
Comment 1 Alexandre Rostovtsev (RETIRED) 2012-10-16 04:45:34 UTC
> (In reply to comment #0) > https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-4505 [...] > This issue was confirmed with libproxy 0.3.x. Earlier 0.2.x versions seems > to be affected too. It does not affect 0.4.x versions, where fixed size > buffer is used. This one doesn't affect us, libproxy-0.4.6 is the earliest we have in the tree.
Comment 2 Alexandre Rostovtsev (RETIRED) 2012-10-16 08:05:01 UTC
(In reply to comment #0) > https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-4504 Thanks, fixed in libproxy-0.4.10 >*libproxy-0.4.10 (16 Oct 2012) > > 16 Oct 2012; Alexandre Rostovtsev <email@example.com> > libproxy-0.4.6-r3.ebuild, libproxy-0.4.7.ebuild, +libproxy-0.4.10.ebuild, > +files/libproxy-0.4.10-disable-pac-test.patch, > +files/libproxy-0.4.10-mozjs185.pc.patch, metadata.xml: > Version bump; fixes buffer overflow (bug #438146, CVE-2012-4504, thanks to > Agostino Sarubbo). Re-add USE=webkit since it now works correctly (bug > #412573, thanks to Lucian Muresan) and it enable by default to provide PAC > and WPAD support. Alternatively, spidermonkey could be used for PAC instead > (but might lead to firefox crashes, see bug #373397). Update license.
Comment 3 Agostino Sarubbo 2012-10-16 14:37:30 UTC
(In reply to comment #1) > This one doesn't affect us, libproxy-0.4.6 is the earliest we have in the > tree. Right! Arches, please test and mark stable: =net-libs/libproxy-0.4.10 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 sh sparc x86"
Comment 4 Anthony Basile 2012-10-17 02:08:45 UTC
stable ppc ppc64
Comment 5 Agostino Sarubbo 2012-10-17 11:07:01 UTC
Comment 6 Jeroen Roovers (RETIRED) 2012-10-17 12:58:37 UTC
Stable for HPPA.
Comment 7 Markus Meier 2012-10-17 19:07:34 UTC
Comment 8 Andreas Schürch 2012-10-19 06:36:03 UTC
Comment 9 Chris Reffett (RETIRED) 2012-10-21 02:55:59 UTC
Would it be possible to switch to stabilizing 0.4.10-r1? Just added it, it fixes a DEPEND problem (bug 438714). If not, no problem, just wanted to ask.
Comment 10 Alexandre Rostovtsev (RETIRED) 2012-10-21 03:47:42 UTC
(In reply to comment #9) > Would it be possible to switch to stabilizing 0.4.10-r1? Just added it, it > fixes a DEPEND problem (bug 438714). If not, no problem, just wanted to ask. Chris, thanks for fixing 438714. I've merged your change into the 0.4.10 ebuild and removed 0.4.10-r1; there is no need to make a revision bump when you are only adding a necessary dependency to an ebuild and that new dependency does not break any of the ebuild's keywords.
Comment 11 Alexandre Rostovtsev (RETIRED) 2012-10-21 04:11:23 UTC
(In reply to comment #10) As pointed out by Chris on IRC, adding the automoc build dependency can change the set of installed files, since the kde plugin will no longer silently fail to build/install. So the 0.4.10-r1 revision bump was indeed correct. Please reset the stabilization target to =net-libs/libproxy-0.4.10-r1 I have opened a separate bug #439122 for stabilization of 0.4.10-r1 on those arches who had already finished stabilizing 0.4.10.
Comment 12 Tobias Klausmann 2012-10-27 14:22:44 UTC
Stable on alpha. (took =dev-lang/spidermonkey-1.8.5-r1 along for the ride).
Comment 13 GLSAMaker/CVETool Bot 2012-11-11 16:19:28 UTC
CVE-2012-4504 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-4504): Stack-based buffer overflow in the url::get_pac function in url.cpp in libproxy 0.4.x before 0.4.9 allows remote servers to have an unspecified impact via a large proxy.pac file.
Comment 14 Raúl Porcel (RETIRED) 2012-11-25 18:57:11 UTC
Comment 15 Sean Amoss (RETIRED) 2012-11-26 01:37:11 UTC
Thanks, everyone. New GLSA request filed.
Comment 16 GLSAMaker/CVETool Bot 2014-04-07 19:11:21 UTC
This issue was resolved and addressed in GLSA 201404-02 at http://security.gentoo.org/glsa/glsa-201404-02.xml by GLSA coordinator Mikle Kolyada (Zlogene).