Bug 913751 (CVE-2013-0336)

Summary: CVE-2013-0336 389-ds-base: DoS when connecting with a missing username/dn
Product: [Other] Security Response Reporter: Vincent Danen <vdanen>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: dpal, mkosek, nkinder, rcritten, rmeggins, sbose, security-response-team, ssorce
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=moderate,public=20130327,reported=20130219,source=redhat,cvss2=5.0/AV:N/AC:L/Au:N/C:N/I:N/A:P,fedora-18/freeipa=affected,fedora-18/389-ds-base=affected,rhel-6/ipa=notaffected,rhel-6/389-ds-base=notaffected
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 928387, 928388    
Bug Blocks: 913752    
Attachments:
Description Flags
Patch for the reported issue
none
Patch for the FreeIPA side of the issue rcritten: review+

Description Vincent Danen 2013-02-21 18:46:20 EST
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 12:33:03 EST
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 06:31:54 EST
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 09:25:19 EST
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 12:49:04 EST
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 12:54:06 EST
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 06:08:28 EST
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 10:33:49 EST
Is there a bug open against 389-ds-base?
Comment 9 Nathan Kinder 2013-03-07 12:41:37 EST
(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 12:51:43 EDT
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 13:32:55 EDT
Created attachment 710779 [details]
Patch for the FreeIPA side of the issue
Comment 13 Rob Crittenden 2013-03-15 14:07:20 EDT
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 14:23:40 EDT
CRD is set for March 26th.
Comment 16 Vincent Danen 2013-03-23 17:28:01 EDT
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 10:39:10 EDT
Created freeipa tracking bugs for this issue

Affects: fedora-18 [bug 928387]
Comment 18 Vincent Danen 2013-03-27 10:39:17 EDT
Created 389-ds-base tracking bugs for this issue

Affects: fedora-18 [bug 928388]
Comment 19 Vincent Danen 2013-04-03 11:27:42 EDT
Upstream commits:

master: 7b45e33400355df44e75576ef7f70a39d163bf8e

ipa-3-1: 193192a257b9234bdbfc4326a3463a5b5953d491
Comment 20 Fedora Update System 2013-04-11 06:06:53 EDT
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.