Bug 913751 (CVE-2013-0336) - CVE-2013-0336 389-ds-base: DoS when connecting with a missing username/dn
Summary: CVE-2013-0336 389-ds-base: DoS when connecting with a missing username/dn
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2013-0336
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 928387 928388
Blocks: 913752
TreeView+ depends on / blocked
 
Reported: 2013-02-21 23:46 UTC by Vincent Danen
Modified: 2023-05-11 22:03 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-10 11:00:08 UTC
Embargoed:


Attachments (Terms of Use)
Patch for the reported issue (1.38 KB, patch)
2013-02-26 11:31 UTC, Sumit Bose
no flags Details | Diff
Patch for the FreeIPA side of the issue (2.39 KB, patch)
2013-03-15 17:32 UTC, Sumit Bose
rcritten: review+
Details | Diff

Description Vincent Danen 2013-02-21 23:46:20 UTC
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.

Comment 2 Vincent Danen 2013-02-22 17:33:03 UTC
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.

Comment 3 Sumit Bose 2013-02-26 11:31:54 UTC
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 4 Rich Megginson 2013-02-26 14:25:19 UTC
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?

Comment 5 Sumit Bose 2013-02-26 17:49:04 UTC
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.

Comment 6 Rich Megginson 2013-02-26 17:54:06 UTC
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.

Comment 7 Sumit Bose 2013-03-07 11:08:28 UTC
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.

Comment 8 Rich Megginson 2013-03-07 15:33:49 UTC
Is there a bug open against 389-ds-base?

Comment 9 Nathan Kinder 2013-03-07 17:41:37 UTC
(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.

Comment 10 Vincent Danen 2013-03-13 16:51:43 UTC
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.

Comment 12 Sumit Bose 2013-03-15 17:32:55 UTC
Created attachment 710779 [details]
Patch for the FreeIPA side of the issue

Comment 13 Rob Crittenden 2013-03-15 18:07:20 UTC
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.

Comment 14 Vincent Danen 2013-03-18 18:23:40 UTC
CRD is set for March 26th.

Comment 16 Vincent Danen 2013-03-23 21:28:01 UTC
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.

Comment 17 Vincent Danen 2013-03-27 14:39:10 UTC
Created freeipa tracking bugs for this issue

Affects: fedora-18 [bug 928387]

Comment 18 Vincent Danen 2013-03-27 14:39:17 UTC
Created 389-ds-base tracking bugs for this issue

Affects: fedora-18 [bug 928388]

Comment 19 Vincent Danen 2013-04-03 15:27:42 UTC
Upstream commits:

master: 7b45e33400355df44e75576ef7f70a39d163bf8e

ipa-3-1: 193192a257b9234bdbfc4326a3463a5b5953d491

Comment 20 Fedora Update System 2013-04-11 10:06:53 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.