[Freeipa-devel] Announcing FreeIPA 3.1.2
Simo Sorce
simo at redhat.com
Wed Jan 23 22:16:12 UTC 2013
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.
################################################################################
More information about the Freeipa-devel
mailing list