Summary: | <www-servers/nginx-1.0.10: heap overflow in ngx_resolver_copy() (CVE-2011-4315) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dev-zero, hollow |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://trac.nginx.org/nginx/changeset/4268/nginx | ||
Whiteboard: | B1 [glsa] | ||
Package list: | Runtime testing required: | --- |
Description
Agostino Sarubbo
2011-11-02 13:07:17 UTC
A heap overflow was found, I don't have further details, but please provide an updated ebuild, it's a remotely exploitable bug. re-adding hollow 1.0.10/1.1.8 in cvs now (In reply to comment #4) > 1.0.10/1.1.8 in cvs now Thanks hollow. Arches, please test and mark stable: =www-servers/nginx-1.0.10 Target keywords : "amd64 x86" Fine for me on both arches. amd64 ok; compilation, startup, and nginix -t tests all good forgot to make note that USE="passenger" returned Passenger support has been removed from the nginx ebuild to * get rid of file collisions, its broken build system and * incompatibilities between passenger 2 and 3. * * Please switch to passenger-3 standalone or use the * unicorn gem which provides a sane nginx-like architecture * out of the box. switched to passenger-3 and all went fine as stated above. x86 stable + 22 Nov 2011; Tony Vroon <chainsaw@gentoo.org> nginx-1.0.10.ebuild: + Marked stable on AMD64 based on arch testing by Agostino "ago" Sarubbo & + Michael "n0idx80" Harrison in security bug #389319. Security, that's stable keywording complete for all arches. Thanks, everyone. Added to existing GLSA request. CVE-2011-4315 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-4315): Heap-based buffer overflow in compression-pointer processing in core/ngx_resolver.c in nginx before 1.0.10 allows remote resolvers to cause a denial of service (daemon crash) or possibly have unspecified other impact via a long response. This issue was resolved and addressed in GLSA 201203-22 at http://security.gentoo.org/glsa/glsa-201203-22.xml by GLSA coordinator Sean Amoss (ackle). |