mod_nss incorrect handling of NSSVerifyClient in directory context

2013.12.05
Credit: Tomas Hoger
Risk: Medium
Local: No
Remote: Yes
CWE: CWE-264


CVSS Base Score: 4/10
Impact Subscore: 4.9/10
Exploitability Subscore: 4.9/10
Exploit range: Remote
Attack complexity: High
Authentication: No required
Confidentiality impact: Partial
Integrity impact: Partial
Availability impact: None

A mod_nss issue related to handling of NSSVerifyClient was made public yesterday. The following bug has relevant details and links: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-4566 A flaw was found in the way NSSVerifyClient was handled when used in both server / vhost context as well as directory context (specified either via <Directory> or <Location> directive). If 'NSSVerifyClient none' was set in the server / vhost context (i.e. when server is configured to not request or require client certificate authentication on the initial connection), and client certificate authentication was expected to be required for a specific directory via 'NSSVerifyClient require' setting, mod_nss failed to properly require expected certificate authentication. Remote attacker able to connect to the web server using such mod_nss configuration and without a valid client certificate could possibly use this flaw to access content of the restricted directories. Documentation of mod_nss configuration directives, including NSSVerifyClient: https://git.fedorahosted.org/cgit/mod_nss.git/plain/docs/mod_nss.html#Directives As mod_nss is derived form mod_ssl, NSSVerifyClient is meant to be functionally equivalent to mod_ssl's SSLVerifyClient: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslverifyclient

References:

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-4566
http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslverifyclient


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top