Bug 471009 - (CVE-2007-6420) CVE-2007-6420 mod_proxy_balancer CSRF
CVE-2007-6420 mod_proxy_balancer CSRF
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On:
  Show dependency treegraph
Reported: 2008-11-11 06:25 EST by Mark J. Cox (Product Security)
Modified: 2016-03-04 06:19 EST (History)
4 users (show)

See Also:
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:
Last Closed: 2010-12-20 12:10:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mark J. Cox (Product Security) 2008-11-11 06:25:13 EST
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 (Product Security) 2008-11-11 06:33:45 EST
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 10:48:02 EDT
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 12:10:58 EST
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.

Note You need to log in before you can comment on or make changes to this bug.