Bug 471009 (CVE-2007-6420)

Summary: CVE-2007-6420 mod_proxy_balancer CSRF
Product: [Other] Security Response Reporter: Mark J. Cox <mjc>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: jorton, pahan, redhat, vdanen
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6420
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
A cross-site request forgery issue was found in the mod_proxy_balancer module. A remote attacker could cause a denial of service if mod_proxy_balancer is enabled and an authenticated user is targeted. (CVE-2007-6420)
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-20 17:10:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mark J. Cox 2008-11-11 11:25:13 UTC
Common Vulnerabilities and Exposures assigned an identifier CVE-2007-6420 to the following vulnerability:

Cross-site request forgery (CSRF) vulnerability in the balancer-manager in mod_proxy_balancer for Apache HTTP Server 2.2.x allows remote attackers to gain privileges via unspecified vectors.

Comment 2 Mark J. Cox 2008-11-11 11:33:45 UTC
mod_proxy_balancer is shipped in Red Hat Enterprise Linux 5 and Red Hat Application Stack v2.  

We do not plan on correcting this issue in Red Hat Enterprise Linux 5 as it poses a very low security risk:  The balancer manager is not enabled by default, the user targeted by the CSRF would need to be authenticated, and the consequences of an exploit would be limited to a web server denial of service.

We plan on updating to a new upstream version of Apache shipped in Application Stack v2, which will cause this issue to be addressed.

Comment 3 Hrunting Johnson 2010-09-17 14:48:02 UTC
The problem with not fixing this problem (and many others that Redhat deems too low a priority to fix) is that the PCI standards committee has deemed the vulnerability to be severe enough to affect PCI-DSS standards compliance.  As a vendor that takes credit cards, we can't achieve PCI compliance running Redhat enterprise software.  It's especially troubling that there is a patch available, so Redhat's work has been done for them.

Can you please reconsider this decision (I understand it's about two years too late) and others you make like this?  It's tough being told that your vendor-supplied security fixes aren't good enough to patch a common vulnerability assessment standard.

Comment 4 Vincent Danen 2010-12-20 17:10:58 UTC
Hi there.  This isn't something we intend to fix in a security erratum due to the rationale noted by Mark above.  However, you can open a ticket with GSS and request that it gets corrected in the next quarterly update.  That could very well solve the issue for you.

Note that is has been fixed in Stacks v2 already, via https://rhn.redhat.com/errata/RHSA-2008-0966.html.