Sumit Bose discovered that FreeIPA's directory server (dirsrv) would segfault if an unauthenicated user attempted to connect to it with a missing username/dn. According to RFC 3062, connecting without specifying the username/dn is valid. Acknowledgements: This issue was discovered by Sumit Bose of Red Hat.
The root of this issue is in the 389 directory server, which FreeIPA also contains, so this affects both 389 and FreeIPA. This issue only affects FreeIPA 3.1 and 389-ds 1.3.x; earlier versions do not have the vulnerable code.
Created attachment 702805 [details] Patch for the reported issue With the attached patch 0001-Return-an-error-if-a-backend-does-not-support-transa.patch against 389-ds-base the issue is gone with an un-patched version for FreeIPA (freeipa-server-3.1.2-1.fc18). I'm not sure if with the patch above a patch from FreeIPA is needed as well. Because the only drawback for FreeIPA is that no transaction is used for the password change because an error is returned by slapi_back_transaction_begin(). But since the transaction was introduced in FreeIPA 3.1, is means we just fall back to the previous behavior.
Comment on attachment 702805 [details] Patch for the reported issue nack - LDAP_NO_SUCH_OPERATION is only supposed to be used with the LDAP Cancel operation. Where is this code called from in ipa? Should this even be an error?
I'm not sure what would be the right error code here, but I think the caller should get some feedback if transactions are not available. It looks like e.g. dblayer_plugin_begin() just returns -1 in case of an error, would this be a better return code? FreeIPA calls slapi_back_transaction_begin() in the block starting at http://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c#n244 . In the case described in comment 1 dn is NULL hence the default backend is used, which does not support transaction. In the FreeIPA code this block must be moved down a bit after the input parameters are checked.
There are at least 2 exceptional return cases from slapi_back_transaction_begin: 1) backend does not support transactions 2) a hard error (out of resources, etc.) In the case of 1, this could happen if someone is trying to use the cn=config tree for users. This is possible in 389, I don't know if ipa allows this. In that case, it might be better to return some error code e.g. SLAPI_BACK_TRANSACTION_NOT_SUPPORTED rather than a "hard" error code. ipa might want to allow the operation to proceed in that case, without a transaction.
Sorry for the delay, got distracted. I'm fine with changing the error code to SLAPI_BACK_TRANSACTION_NOT_SUPPORTED, the more specific the better. Currently FreeIPA ignores all kind of errors related to transactions and continues without them. FreeIPA does not allow to put users into cn=config, the seqfault here was triggered by a missing DN (see comment #1) which lead to the use of the default backend, which does not support transactions. While this is clearly an error on the FreeIPA side I think it should be fixed on the dirsrv side as well to make it harder in future to trigger seqfaults.
Is there a bug open against 389-ds-base?
(In reply to comment #8) > Is there a bug open against 389-ds-base? I haven't seen one. It seems like the 389 DS side changes should be created as an upstream ticket, as it's not a security issue. The security issue seems to be on the IPA side, though we can make changes in 389 DS to be less error prone for plug-in writers. If this sounds OK to Vincent and Sumit, I can file the upstream ticket for 389 DS.
That depends. It's not a security flaw on the 389 side, so this change is just to the error code being returned there? If that's the case and doesn't mention anything about IPA, I'm ok with opening up an upstream bug just to change the error code. If it's described as anything vaguely security-related, we should wait until this is fixed in IPA/FreeIPA first, or at least coordinate the fix between the two so that they go public together.
Created attachment 710779 [details] Patch for the FreeIPA side of the issue
Comment on attachment 710779 [details] Patch for the FreeIPA side of the issue Tested ldappasswd: - user setting own password using simple auth - admin changing user password using GSSAPI - setting password anonymously (failed gracefully) Also confirmed that ipa passwd works, and kinit of a reset password resets it correctly.
CRD is set for March 26th.
Statement: Not vulnerable. This issue did not affect the versions of IPA or 389-ds as shipped with Red Hat Enterprise Linux 5 or 6.
Created freeipa tracking bugs for this issue Affects: fedora-18 [bug 928387]
Created 389-ds-base tracking bugs for this issue Affects: fedora-18 [bug 928388]
Upstream commits: master: 7b45e33400355df44e75576ef7f70a39d163bf8e ipa-3-1: 193192a257b9234bdbfc4326a3463a5b5953d491
freeipa-3.1.3-4.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.