The FreeIPA team is proud to announce version FreeIPA v3.1.2 This release contains Security Updates
It can be downloaded from http://www.freeipa.org/page/Downloads. == Highlights == During the past few months a number of security Issues have been found that affect FreeIPA. Three Security Advisories have been released: * CVE-2012-4546: Incorrect CRLs publishing * CVE-2012-5484: MITM Attack during Join process * CVE-2013-0199: Cross-Realm Trust key leak The FreeIPA Team would like to thank the Red Hat Security Response Team and in particular Vincent Danen for the invaluable assistance provided for the assessment and resolution of these issues. For CVE-2012-5484 we would like to thank Petr Menšík for reporting the issue. == Upgrading == Please consult each CVE announcement for related Upgrading instructions. An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note, that the referential integrity extension requires an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of hosts, SUDO or HBAC entries may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 2.2.0 is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. Feedback Please provide comments, bugs and other feedback via the freeipa-devel mailing list: http://www.redhat.com/mailman/listinfo/freeipa-devel == Detailed Changelog since 3.1.1 == Alexander Bokovoy (1): Update plugin to upload CA certificate to LDAP Ana Krivokapic (1): Raise ValidationError for incorrect subtree option. John Dennis (1): Use secure method to acquire IPA CA certificate Martin Kosek (5): permission-find no longer crashes with --targetgroup Avoid CRL migration error message Sort LDAP updates properly Upgrade process should not crash on named restart Installer should not connect to 127.0.0.1 Rob Crittenden (5): Convert uniqueMember members into DN objects. Do SSL CA verification and hostname validation. Don't initialize NSS if we don't have to, clean up unused cert refs Update anonymous access ACI to protect secret attributes. Become IPA 3.1.2 Simo Sorce (1): Upload CA cert in the directory on install ################################################################################ == CVE-2012-4546: Incorrect CRLs publishing == == Summary == It was found that the current default configuration of IPA servers did not publish correct CRLs (Certificate Revocation Lists). The default configuration specifies that every replica is to generate its own CRL, however this can result in inconsistencies in the CRL contents provided to clients from different Identity Management replicas. More specifically, if a certificate is revoked on one Identity Management replica, it will not show up on another Identity Management replica. To avoid this inconsistency, the solution is to configure CRL generation to only take place on one Identity Management server. To do so, the CRL configuration must be changed on all Identity Management servers. == Affected Versions == All 2.x and 3.x versions using multiple CA replicas == Impact == Low == Acknowledgements == The bug was found by the FreeIPA team during an internal review. == Upgrade Instructions == Upgrading to the latest 3.0 or 3.1 FreeIPA versions should be sufficient to resolve the issue. == Manual Instructions == To manually resolve the problem the CRL configuration must be changed on all Identity Management servers. One IPA master needs to be picked as the CRL generator. It does not matter which master, and the following procedure should be used: On the non-CRL generating masters: 1. Configure the clones to point to the CRL generator to get the CRL: 1a. Edit /etc/httpd/conf.d/ipa-pki-proxy.conf 1b. Add "|^/ca/ee/ca/getCRL" to the end of the first LocationMatch. After editing, the first LocationMatch entry in ipa-pki-proxy.conf should look like this: <LocationMatch "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain| ^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp| ^/ca/ee/ca/updateNumberRange|^/ca/ee/ca/getCRL"> 1c. At the end of this file add: RewriteRule ^/ipa/crl/MasterCRL.bin https://$FQDN/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC] 1d. Replace $FQDN with the hostname of the IPA master picked as the CRL generator. 1e. The httpd service will need to be restarted after making this change: # service httpd restart 2. Update the CRL generator to include certificates revoked from other masters in its CRL: 2a. Edit the CA configuration file in /var/lib/pki-ca/conf/CS.cfg: These two settings should be true by default: ca.crl.MasterCRL.enableCRLCache=true ca.crl.MasterCRL.enableCRLUpdates=true 2b. Set this directive to true (This can be appended to the end of CS.cfg): ca.listenToCloneModifications=true 2c. The CA will need to be restarted after making this change: # service pki-cad restart It may be noted that this configuration creates a single point of failure. If the CRL generator server goes down then the other IPA masters will not be able to retrieve a CRL and one will not be generated. In this case one would need to choose a new master as the CRL generator and perform the steps above. It is recommended that a DNS CNAME be created to refer to the server that provides the CRL (with a relatively short TTL). This will provide flexibility in case the CRL generator needs to be changed, and without reconfiguring any clients that need to retrieve the CRL. == Patches == A patch to resolve this issue is available through our git repository: http://git.fedorahosted.org/cgit/freeipa.git/commit/?id=392097f20673708a684da168aec302da7ccda9a6 ################################################################################ == CVE-2012-5484: MITM Attack during Join process == A weakness was found in the way an IPA client communicates with an IPA server when attempting to join an IPA domain. When an IPA client attempts to join an IPA domain an attacker could run a Man in The Middle Attack to try to intercept and hijack initial communication. A join initiated by an administrative user would grant the attacker administrative rights to the IPA server, whereas a join initiated by an unprivileged user would only grant the attacker limited privilege (typically just the ability to join the domain). The weakness is caused by the way the CA certificate is retrieved from the server. The following SSL communication may then be intercepted and subverted. Note that no credentials are exposed through this attack and it is effective only if performed during the join procedure and network traffic can be redirected or intercepted. Mere observation of the network traffic is not sufficient to grant an attacker any privilege. == Affected Versions == All 2.x and 3.x versions == Impact == Low == Acknowledgements == The FreeIPA team would like to thank Petr Menšík for reporting this issue. == Upgrade instructions == The resolution for this issue consist in allowing clients to download the CA certificate exclusively via a mutually authenticated LDAP connection or by providing the CA cert via an external method to the client. At least one IPA server in a domain need to be updated using the provided patches, so that the CA certificate is made available via LDAP. All client should be upgraded to use the updated ipa-client-install script that downloads the CA cert via an authenticated LDAP connection. == Patches == Patches to resolve this issue are available through our git repository: * http://git.fedorahosted.org/cgit/freeipa.git/commit/?id=18eea90ebb24a9c22248f0b7e18646cc6e3e3e0f * http://git.fedorahosted.org/cgit/freeipa.git/commit/?id=a40285c5a0288669b72f9d991508d4405885bffc * http://git.fedorahosted.org/cgit/freeipa.git/commit/?id=91f4af7e6af53e1c6bf17ed36cb2161863eddae4 * http://git.fedorahosted.org/cgit/freeipa.git/commit/?id=a1991aeac19c3fec1fdd0d184c6760c90c9f9fc9 * http://git.fedorahosted.org/cgit/freeipa.git/commit/?id=31e41eea6c2322689826e6065ceba82551c565aa ################################################################################ == CVE-2013-0199: Cross-Realm Trust key leak == FreeIPA 3.0 introduced a Cross-Realm Kerberos trusts with Active Directory, a feature that allows IPA administrators to create a Kerberos trust with an AD. This allows IPA users to be able to access resources in AD trusted domains and vice versa. When the Kerberos trust is created, an outgoing and incoming keys are stored in the IPA LDAP backend (in ipaNTTrustAuthIncoming and ipaNTTrustAuthOutgoing attributes). However, the IPA LDAP ACIs allow anonymous read acess to these attributes which could allow an unprivileged user to read the keys. With these keys an attacker could impersonate users and services of the opposite domain by crafting special Kerberos tickets. == Affected Versions == All 3.x versions. The vulnerability is present only if AD Trusts are enabled and a trust relationship is in place. == Impact == Medium == Acknowledgements == The bug was found by the FreeIPA team during an internal review. == Upgrade Instructions == Administrators are advise to change their ACIs to block the ipaNTTrustAuthIncoming and ipaNTTrustAuthOutgoing attributes from access from non administrative users. Once the new ACIs are in place it is recommended to change the trust password. This can be accomplished by temporary deleting and then recreating the trust agreement between the two domains using tha ipa trust CLI commands. == Patches == A patch to resolve this issue is available through our git repository: http://git.fedorahosted.org/cgit/freeipa.git/commit/?id=d5966bde802d8ef84c202a3e7c85f17b9e305a30 Applying the patch prevents further access to keys but does NOT change the trust secret. ################################################################################ _______________________________________________ Freeipa-interest mailing list Freeipa-interest@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-interest
