A weakness was found in the way an IPA client would communicate with an IPA server when attempting to join an IPA domain. When an IPA client attempted to join an IPA domain, and if an attacker were able to spoof the DNS name of the IPA server, the client would connect to the attacker's fake server. The attacker would be able to intercept the credentials from the client, and issue commands to the server using these credentials, with their privilege. 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). This issue affects both the manual method (using the ipa-join or ipa-client-install commands [1]) as well as the OTP (One-Time Password, used with Kickstart [2]) method to join an IPA domain. However, the amount of privilege an attacker could receive with an OTP join is limited because the client IPA system connects to the server as an unprivileged user (all this user can do is join the domain, nothing more) IMPORTANT NOTE: This was only effective during the intial client join to the realm, because the client did not yet have the CA certificate of the server. Once an IPA client has joined the realm and has the IPA server's CA certificate, all further communication is secure and a man-in-the-middle attack will not succeed. This provided a potential attacker with a very small window of opportunity. To work-around this flaw, using the OTP method using the Kickstart is advised, or, if necessary, using the manual method but ensuring that an unprivileged account is used. [1] https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Installing_the_IPA_Client_on_Linux.html [2] https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/kickstart.html Acknowledgements: Red Hat would like to thank Petr Menšík for reporting this issue.
Created attachment 657525 [details] 1/4
Created attachment 657526 [details] 2/4
Created attachment 657527 [details] 3/4
Created attachment 657528 [details] 4/4
To work around/mitigate this problem, use an unprivileged user to join to the IPA domain, or use OTP (which can also be used at the commandline, not just during kickstart).
External References: http://www.freeipa.org/page/CVE-2012-5484
Created freeipa tracking bugs for this issue Affects: fedora-all [bug 903390]
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2013:0188 https://rhn.redhat.com/errata/RHSA-2013-0188.html
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2013:0189 https://rhn.redhat.com/errata/RHSA-2013-0189.html
freeipa-3.1.2-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 842873 has been marked as a duplicate of this bug. ***