Bug 702437
| Summary: | may be possible to spoof mod_nss FakeBasicAuth | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | jared jennings <jjennings> | ||||||||
| Component: | mod_nss | Assignee: | Rob Crittenden <rcritten> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Chandrasekar Kannan <ckannan> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 6.0 | CC: | benl, dpal, jgalipea, kchamart | ||||||||
| Target Milestone: | rc | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | mod_nss-1.0.8-13.el6 | Doc Type: | Bug Fix | ||||||||
| Doc Text: |
Prior to this update, client certificates were only retrieved during the initial SSL handshake if the NSSVerifyClient option was set to "require" or "optional". Also, the FakeBasicAuth option only retrieved Common Name rather than the entire certificate subject. Consequently, it was possible to spoof an identity using that option. This bug has been fixed, the FakeBasicAuth option is now prefixed with "/" and is thus compatible with OpenSSL, and certificates are now retrieved on all subsequent requests beyond the first one.
|
Story Points: | --- | ||||||||
| Clone Of: | |||||||||||
| : | 749402 (view as bug list) | Environment: | |||||||||
| Last Closed: | 2011-12-06 16:37:29 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: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 749402, 797335, 1017197 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
jared jennings
2011-05-05 16:40:08 UTC
I've changed nss_engine_kernel.c around line 629 to use CERT_NameToAscii instead of CERT_GetCommonName, and to put a slash on the beginning of the string first. This makes the spoof check useful again, and ensures that the whole DN is used in authorization, so certificates having the same common name but different issuers will not produce wrong authorization results. Since RHEL 6.1 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. Your suggestion in #c2 seems fine to me. sslconn->client_dn is only used for FakeBasicAuth so we can do what we wish with it. Created attachment 498352 [details]
Use full subject for FakeBasicAuth, always retrieve the client cert
The first fix is to retrieve the full certificate subject instead of just the CN for FakeBasicAuth and prefix it with / to be compatible with OpenSSL.
The second always attempts to retrieve the client certificate in nss_hook_ReadReq().
Created attachment 498379 [details]
Revised patch, only get cert in nss_hook_ReadReq()
Thank you, sir: this patch fixes both of the problems I've had with mod_nss. Committed upstream a6c3370491ae1d3bc552e8de9353c82f73e510e3
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Prior to this update, client certificates were only retrieved during the initial SSL handshake if the NSSVerifyClient option was set to "require" or "optional". Also, the FakeBasicAuth option only retrieved Common Name rather than the entire certificate subject. Consequently, it was possible to spoof an identity using that option. This bug has been fixed, the FakeBasicAuth option is now prefixed with "/" and is thus compatible with OpenSSL, and certificates are now retrieved on all subsequent requests beyond the first one.
Created attachment 532763 [details]
nss.conf used to test mod_nss
VERIFIED. Version Info. ======================================= [root@dhcp201-108 conf.d]# rpm -q mod_nss mod_nss-1.0.8-13.el6.x86_64 [root@dhcp201-108 conf.d]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.2 Beta (Santiago) [root@dhcp201-108 conf.d]# ======================================= Procedure: 1/ Have a Certificate Authority instance handy. I used a Certificate System CA instance located on MachineA 2/ On MachineB : # yum install mod_nss 3/ On MachineB, Add nss-test.conf to /etc/httpd/conf.d/ (attached in comment #11) 3.1/ Also ensure to include the nss-test.conf in httpd.conf ======================================= [root@dhcp201-108 conf.d]# grep "Include conf" /etc/httpd/conf/httpd.conf #Include conf.d/*.conf Include conf.d/nss-test.conf [root@dhcp201-108 conf.d]# ======================================= 4/ Add the CAs (from MachineA) 'Signing Cert' and 'Server Cert' into /etc/httpd/alias on MachineB (where mod_nss is configured) ======================================= [root@dhcp201-108 alias]# certutil -L -d /etc/httpd/alias/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI cacert CTu,Cu,Cu Server-Cert u,u,u Server-Cert cert-pki-ca-aug24-qeb u,u,u caSigningCert cert-pki-ca-aug24-qeb CT,C,C alpha u,pu,u [root@dhcp201-108 alias]# ======================================= 5/ Ensure to include the nss-test.conf [root@dhcp201-108 conf]# grep "Include conf" httpd.conf #Include conf.d/*.conf Include conf.d/nss-test.conf [root@dhcp201-108 conf]# 6/ Create a test html file in /var/www/html ======================================= [root@dhcp201-108 html]# mkdir securearea ; cd securearea [root@dhcp201-108 securearea]# cat index.html <html> <head> <title>mod_nss secure area</title> </head> <body> <h1>Red Hat Enterprise Linux</h1> +mod_nss secure area </body> </html> [root@dhcp201-108 securearea]# ======================================= 7/ Restart httpd on MachineB (where mod_nss is configured) ======================================= [root@dhcp201-108 alias]# service httpd restart Stopping httpd: [ OK ] Starting httpd: [ OK ] [root@dhcp201-108 alias]# ======================================= 8/ Issue a user certificate from the CA and import it into the browser. 9/ Now from the browser, try to access the 'securearea' url http://MachineB:7443/securearea Authentication for client certificate should be prompted, and httpd 'access_log' should have the entries Reload the above url a few times, now, every reload the should reflect the auth in the access_log Thanks Rob. for detail. Successful httpd access_log entries: ####################################### ==> /var/log/httpd/access_log <== 10.16.76.34 - - [10/Nov/2011:03:51:31 -0500] "GET /securearea/ HTTP/1.1" 200 146 "-" "Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110927 Red Hat/3.6-2.el5_7 Firefox/3.6.23" 10.16.76.34 - - [10/Nov/2011:03:51:47 -0500] "GET /securearea/ HTTP/1.1" 200 146 "-" "Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110927 Red Hat/3.6-2.el5_7 Firefox/3.6.23" 10.16.76.34 - - [10/Nov/2011:03:52:05 -0500] "GET /securearea/ HTTP/1.1" 200 146 "-" "Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110927 Red Hat/3.6-2.el5_7 Firefox/3.6.23" ####################################### Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1656.html |