Bug 886369 (CVE-2012-5631)

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.