RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1372597 - Incorrect CA ACL evaluation of SAN DNS names in certificate request
Summary: Incorrect CA ACL evaluation of SAN DNS names in certificate request
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: Kaleem
URL:
Whiteboard:
Depends On:
Blocks: CVE-2016-5414
TreeView+ depends on / blocked
 
Reported: 2016-09-02 07:57 UTC by Martin Babinsky
Modified: 2016-11-04 06:02 UTC (History)
6 users (show)

Fixed In Version: ipa-4.4.0-10.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-04 06:02:42 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
verification steps with console output (7.08 KB, text/plain)
2016-09-21 13:52 UTC, Kaleem
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2404 0 normal SHIPPED_LIVE ipa bug fix and enhancement update 2016-11-03 13:56:18 UTC

Description Martin Babinsky 2016-09-02 07:57:07 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/freeipa/ticket/6291

`ipa cert-request` is supposed to check that the DNS names included in the SubjectAltName extension of CSR are authorized to be used with the certificate profile used with the CSR.

A regression introduced in c2af032c0333f7e210c54369159d1d9f5e3fec74 effectively bypassed this check, allowing the host principal to succesfully submit CSR with SAN DNS names of any host enrolled in FreeIPA domain.

Comment 1 Martin Babinsky 2016-09-02 08:02:16 UTC
Fixed upstream
master:

https://fedorahosted.org/freeipa/changeset/c2af032c0333f7e210c54369159d1d9f5e3fec74/

Comment 6 Martin Babinsky 2016-09-09 11:21:25 UTC
I have managed to slap together a rudimentary test case. It would be nice if Fraser could review and approve it, since the issue is pretty complex and quite hard for me to grasp. I hope I got it right:

1.)
Set up:

two host entries: host1.ipa.test, host2.ipa.test
two service entries: srv/host1.ipa.test, srv/host2.ipa.test

Request and store keytab for host1

2.) allow host1 to manage service2:

ipa service-add-host srv/host2.ipa.test --hosts host1.ipa.test

3.) generate CSR for host1.ipa.test having both hosts as the subjectAltName DNS fields

# cat openssl.conf 
[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name

[ req_distinguished_name ]
commonName = host1.ipa.test

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = host1.ipa.test
DNS.2 = host2.ipa.test

# openssl req -out test_csr.csr -new -newkey rsa:2048 -nodes -keyout test.key -config openssl.conf

4.) set up testing sub-CA and CAACL, add the sub-CA and caIPAserviceCert to CAACL

# ipa ca-add test_ca --subject 'CN=Test CA,O=IPA.TEST' --desc 'Test CA'
# ipa caacl-add test_caacl
# ipa caacl-add-ca test_caacl --cas test_ca
# ipa caacl-add-profile test_caacl --certprofiles caIPAserviceCert

5.) add host1.ipa.test to CAACL

# ipa caacl-add-host test_caacl --hosts host1.ipa.test

6.) add only service1 to CA ACL

# ipa caacl-add-service test_caacl --services srv/host1.ipa.test

7.) kinit as host1 and try to request certificate using test sub-CA. This should fail w/ ACIError as the `srv/host2.ipa.test` inferred from subjectAltNames is not part of CAACL
# kinit -kt /host/keytab host/host1.ipa.test
# ipa cert-request test_csr.csr --principal srv/`hostname` --ca test_ca

8.) kinit as admin and add srv/host2.ipa.test to the CA ACL
# kinit admin
# ipa caacl-add-service test_caacl --services srv/host2.ipa.test

9.) repeat step 7.), now it should succeed because srv/host2.ipa.test inferred from subjectAltNames is listed in the CA ACL.

Comment 7 Fraser Tweedale 2016-09-12 05:11:18 UTC
I believe the test case can be as simple as:

1. Request a cert for a host or service with a SAN dnsName extension request
   of an unrelated host (it need not even refer to an existing entity).  CN
   should match an existing host/service, which is used as the --principal
   option in cert-request.

2. Request the cert.  The request should be refused.

I will confirm that this simpler scenario does indeed trigger the bug.

Comment 8 Fraser Tweedale 2016-09-12 06:18:58 UTC
OK, my previous comment was not right, but the test case can be simpler
than Martin's example: it can be done just with host principals and not
involve service principals.


1.)
Set up:

two host entries: host1.ipa.test, host2.ipa.test

Request and store keytab for host1

2.) allow host1 to manage host2:

ipa host-add-managedby host2.ipa.test --hosts host1.ipa.test

3.) generate CSR with CN=host1.ipa.test having both hosts as the subjectAltName DNS fields

# cat openssl.conf 
[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name

[ req_distinguished_name ]
commonName = host1.ipa.test

[ v3_req ]
subjectAltName = @alt_names

[alt_names]
DNS.1 = host1.ipa.test
DNS.2 = host2.ipa.test

# openssl req -out test_csr.csr -new -newkey rsa:2048 -nodes -keyout test.key -config openssl.conf

4.) set up testing sub-CA and CAACL, add the sub-CA and caIPAserviceCert to CAACL

# ipa ca-add test_ca --subject 'CN=Test CA,O=IPA.TEST' --desc 'Test CA'
# ipa caacl-add test_caacl
# ipa caacl-add-ca test_caacl --cas test_ca
# ipa caacl-add-profile test_caacl --certprofiles caIPAserviceCert

5.) add host1.ipa.test to CAACL

# ipa caacl-add-host test_caacl --hosts host1.ipa.test

6.) kinit as host1 and try to request certificate using test sub-CA. This should fail w/ ACIError as the `host/host2.ipa.test` inferred from subjectAltNames is not part of CAACL

# kinit -kt /host/keytab host/host1.ipa.test
# ipa cert-request test_csr.csr --principal host/host1.ipa.test --ca test_ca

7.) kinit as admin and add host2.ipa.test to the CA ACL

# kinit admin
# ipa caacl-add-host test_caacl --hosts host2.ipa.test

8.) repeat step 6.), now it should succeed because host2.ipa.test inferred
from subjectAltNames is listed in the CA ACL.

-----

Commentary: the creation of a sub-CA in steps above is not crucial to the
issue - instead it is a way to get around the default `hosts_services_caIPAserviceCert' CA ACL which allows all hosts and services
for profile `caIPAserviceCert' on default CA 'ipa'.  One could equivalently
disable the `hosts_services_caIPAserviceCert' CA ACL and create a new CA
ACL similar to steps above, but referring to existing 'ipa' CA (or all CAs)
instead of newly-created 'test_ca'.


Hope that helps; let me know if you have further questions!

Comment 9 Kaleem 2016-09-21 13:50:56 UTC
Verified.

IPA Version:
============
[root@dhcp207-129 ~]# rpm -q ipa-server pki-ca
ipa-server-4.4.0-12.el7.x86_64
pki-ca-10.3.3-10.el7.noarch
[root@dhcp207-129 ~]# 

Please find the attached file for verification steps with console output.

Comment 10 Kaleem 2016-09-21 13:52:30 UTC
Created attachment 1203305 [details]
verification steps with console output

Comment 12 errata-xmlrpc 2016-11-04 06:02:42 UTC
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.

https://rhn.redhat.com/errata/RHBA-2016-2404.html


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