In IPA version 3.0 session cookies were introduced as a performance enhancement, this avoided doing a full Kerberos authentication on every HTTP transaction between client web browser and the IPA server. When the IPA server generated a session cookie to be returned with the HTTP response it included security constraints which a browser uses to assure the session credentials are only returned to the generating server over a secure connection. This protected session credentials from beingbeing leaked to a rouge server or being intercepted. In IPA version 3.0 the session cookie optimization was added to the IPA command line client (/usr/bin/ipa) which uses XMLRPC to connect to the IPA server and perform the same operations available in the browser based web UI of IPA. Unfortunately the command line client failed to observe the same rules for cookie security that browsers implement. Specifically it failed to check it was sending the session id in the cookie to the same URL the session id was received on a secure transport connection. If the ipa command line client could be tricked into connecting to a rouge server it would send the session credentials inside a cookie to the rouge server. For the duration of the session (default 20 minutes) the session credentials could be used to impersonate an IPA user, including one with administrator privileges. The possible ways an attacker could fool the ipa client into connecting to a rouge server include: * Gaining root privileges and modifying the default configuration in /etc/ipa. * Modifying the per user ipa configuration under ~/.ipa * DNS poisoning of the SRV records in DNS. Because communication between the IPA CLI client and the IPA server always occurs with SSL the IPA CLI client will refuse to connection to a IPA server whose certificate is not signed by the IPA certificate authority. This limits the attack surface to servers in the IPA realm greatly reducing the scope of the exposure and making the attack difficult. Although other HTTP clients could craft HTTP protocol and send the session cookie credentials it would first have to have access to the stored session cookie which is protected in the user's session kernel keyring. If the keyring is compromised a rouge server is unnecessary, the credentials would have been exposed irregardless. Thus we believe the actual attack surface is fairly small but needs to be closed irregardless. The patch to the components tightens up cookie security with some additional protections that are mostly redundant with the original scheme targeted for browser use.
Upstream bug report: https://fedorahosted.org/freeipa/ticket/3022 Code fix: http://git.fedorahosted.org/cgit/freeipa.git/commit/?id=9269e5d6ddc85716d2b03c7763cf4b8e1ca67cad
This issue is fixed in FreeIPA 3.0.2 and FreeIPA 3.1.0. Current Fedora releases have 2.x, which is unaffected. Current Red Hat Enterprise Linux 5 and 6 have 2.x, which is unaffected (this flaw was introduced in 3.0). Fedora 18 will have 3.1.0, which contains the fix. Statement: Not vulnerable. This issue did not affect the versions of ipa-client and ipa as shipped with Red Hat Enterprise Linux 5 or 6.