Bug 625950 (CVE-2010-3282) - CVE-2010-3282 RHDS/389: information disclosure in audit logs
Summary: CVE-2010-3282 RHDS/389: information disclosure in audit logs
Alias: CVE-2010-3282
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact:
Depends On: 654054 654057 1169242
Blocks: 389_1.2.7 631124 639035
TreeView+ depends on / blocked
Reported: 2010-08-20 22:13 UTC by Vincent Danen
Modified: 2021-10-19 09:13 UTC (History)
9 users (show)

Fixed In Version: 389-ds
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 631124 654057 (view as bug list)
Last Closed: 2021-10-19 09:13:19 UTC

Attachments (Terms of Use)
patch proposal (4.08 KB, patch)
2010-08-24 01:09 UTC, Ulf Weltman
no flags Details | Diff
updated patch proposal (3.99 KB, patch)
2010-08-28 00:01 UTC, Ulf Weltman
rmeggins: review+
Details | Diff
Revised patch (3.97 KB, patch)
2010-11-22 20:02 UTC, Nathan Kinder
rmeggins: review+
Details | Diff

Description Vincent Danen 2010-08-20 22:13:37 UTC
When audit logging is enabled on Red Hat Directory Server and 389 Directory Server, changes to cn=config:nsslapd-rootpw result in the password value being logged in cleartext.  The audit log records an entry similar to the following:

dn: cn=config
changetype: modify
replace: nsslapd-rootpw
nsslapd-rootpw: secret

User passwords, however, are not logged verbatim but in hashed form.

Although the directory server administrator can configure the path and permissions of the audit log, by default it is mode 0600, owned by the directory server user, and is located in the directory server log directory (/var/log/dirsrv/slapd-[hostname]), which is mode 0770 and owned by the directory server user ("nobody", by default)

Comment 2 Vincent Danen 2010-08-20 22:33:27 UTC
I'm not overly familiar with Red Hat Directory Server or 389 DS, but I did install 389 in Fedora to look at this.  I'm not (yet) sure how to enable audit logging, but on preliminary inspection, I see the following configuration:

# grep audit dse.ldif
nsslapd-auditlog: /var/log/dirsrv/slapd-odvfc13/audit
nsslapd-auditlog-mode: 600
nsslapd-auditlog-maxlogsize: 100
nsslapd-auditlog-logrotationtime: 1
nsslapd-auditlog-logrotationtimeunit: day

Looking at default permissions, then:

# ls -al /var/log/dirsrv/
total 12
drwxr-xr-x   3 root   root   4096 Aug 20 16:03 .
drwxr-xr-x. 16 root   root   4096 Aug 20 16:20 ..
drwxrwx---   2 nobody nobody 4096 Aug 20 16:03 slapd-odvfc13
# ls -al /var/log/dirsrv/slapd-odvfc13/audit
-rw------- 1 nobody root 0 Aug 20 16:03 /var/log/dirsrv/slapd-odvfc13/audit

The permissions here are secure.  Only user 'nobody' or 'root' have access to the logging directory, or the audit log file, as per default.

I admit that I'm not a big fan of using the 'nobody' user for services, because too many services have historically shared the same userid, so I would prefer to see in the future perhaps a dedicated user for the directory server.  Having said that, I see the exposure of this as being quite low and the 'nobody' account is unavailable for switching to due the shell being set to /sbin/nologin.

Realistically, this leaves only the root user being able to access the audit log.  And if you have root privileges, chances are you have more interesting things to do.  That's why I gave this AC:H, however perhaps it should also be Au:S since you would have to change context to another user (such as root or the user the directory server runs as).

Due to the above, we would rate this as a low impact issue.

Comment 3 Rich Megginson 2010-08-21 02:03:21 UTC
Thanks Vincent.  So, what is the recommended solution?  Release an errata?  Release note this behavior?

Comment 4 Vincent Danen 2010-08-23 14:51:29 UTC
This doesn't really fit the criteria to release an ASYNC erratum, because of the low impact.  We can and certainly should fix it along with a future update to RHDS, and it should probably be fixed in 389.

We should probably note that there is a small risk of information disclosure, but that risk is really small (you would need to expose this file in some way by manually changing permissions, and you also need to change that root user's password, _and_ have audit logging enabled).  Certainly it should be documented that there is a slight risk there.

Comment 5 Ulf Weltman 2010-08-23 18:24:18 UTC
Vincent, HP will be required to release a patch ASAP for our customers.  On your side, if I read you correctly, you are suggesting a fix in the next regularly scheduled release and an asynchronous release notes update in the mean time.  If that is the case, can you embargo the release notes update until I can get the patch ready?

Comment 6 Rich Megginson 2010-08-23 21:27:10 UTC
We would like to push out an update to our release notes by the middle of next week.  Will that be a problem?

Comment 7 Vincent Danen 2010-08-23 21:38:21 UTC
Rich, do we have the patch that we would be using to fix the issue to provide to HP?  The fix should be consistent so that when we do issue RHDS updates, there are no unexpected changes or regressions from what HP is providing.  I also don't think there is a rush on our end to update the release notes.  If HP will be patching this right away for their customers, we shouldn't have a problem delaying any documentation/release note updates until that is done (and making sure the upstream 389 code is not updated until then either).

Ulf, Rich would be your contact point for release note updates.  SRT doesn't handle that sort of thing.  And yes, I think for something like this, and with it's low severity, it will either be issued in the next RHDS scheduled release _or_ in an ASYNC update if there are other more significant issues in the same component we would be fixing.

Comment 8 Rich Megginson 2010-08-23 21:57:29 UTC
Vincent - Ulf has already submitted a patch.  We will most likely use the patch from Ulf in our code when we release the fix.

Comment 9 Ulf Weltman 2010-08-23 22:05:26 UTC
Thanks Rich and Vincent.  The earliest I could release is September 15, our release train is not very flexible unfortunately.

Rich, you gave an initial nod to the fix method but I have made some minor updates since then.  Do I attach the new diff to this BZ or another?

Comment 10 Rich Megginson 2010-08-23 22:55:58 UTC
(In reply to comment #9)
> Thanks Rich and Vincent.  The earliest I could release is September 15, our
> release train is not very flexible unfortunately.

Ok, that's fine.

> Rich, you gave an initial nod to the fix method but I have made some minor
> updates since then.  Do I attach the new diff to this BZ or another?

Yes - just attach the patches to this BZ.

Comment 11 Ulf Weltman 2010-08-24 01:09:15 UTC
Created attachment 440540 [details]
patch proposal

This adds hashing of nsslapd-rootpw in op_shared_modify.  It's not needed in op_shared_add since this attribute resides in cn=config which is never added, only modified.

The hashing is done after the pre-op plugins are called, just in case there is a pre-op plugin that needs the clear value.  Post-op plugins will find the hashed value but a determined plugin author could pass the clear value from a pre-op to a post-op plugin.  The userPassword hashing gets around this by squirreling away an unhashed value as unhashed#user#password for Winsync purposes, but it seems overkill for nsslapd-rootpw.

The existing hashing code in config_set_rootpw could be removed but it does no harm since it detects pre-hashed passwords and does not re-hash them.  Do you prefer that code is removed?

Comment 12 Rich Megginson 2010-08-25 23:03:17 UTC
Comment on attachment 440540 [details]
patch proposal

Looks good.

The formatting is a bit dodgy - looks like the original function uses tabs.

Where is mod->mod_bvalues[j]->bv_val allocated?  Is it safe to free it here?

Comment 13 Ulf Weltman 2010-08-28 00:01:19 UTC
Created attachment 441632 [details]
updated patch proposal

Oops, fixed the formatting.  Also moved the "if (strcasecmp (mod->mod_type, CONFIG_ROOTPW_ATTRIBUTE) != 0) continue;" up to the outer loop.

Regarding freeing mod->mod_bvalues[j]->bv_val, it's allocated by do_modify when it decodes the incoming BER.  It think it should be OK to free and replace, encoding of userPassword values happen in a similar way also in op_shared_modify.

Comment 16 Deon Ballard 2010-11-12 21:04:27 UTC
Has HP released the fix to this yet?

Comment 17 Ulf Weltman 2010-11-12 21:29:35 UTC
This fix was released by HP on September 15.

Comment 21 Vincent Danen 2010-11-16 18:03:57 UTC
Giving this the CVE name CVE-2010-4174

Comment 22 Vincent Danen 2010-11-16 18:05:58 UTC
This is documented here:



The Red Hat Security Response Team has rated this issue as having low security impact, a future update to Red Hat Directory Server may address this flaw.

Comment 24 Vincent Danen 2010-11-16 18:14:23 UTC
Created 389-ds tracking bugs for this issue

Affects: fedora-all [bug 654054]

Comment 25 Vincent Danen 2010-11-16 22:29:58 UTC
Actually, HP had previously assigned CVE-2010-3282 to this issue, so we're going to use their CVE name and reject CVE-2010-4174.

For reference:

http://www11.itrc.hp.com/service/cki/docDisplay.do?docId=emr_na-c02522633 (requires a login)

Comment 26 Nathan Kinder 2010-11-22 20:02:54 UTC
Created attachment 462126 [details]
Revised patch

This is essentially the same as Ulf's patch, but I added a function prototype for the new static hashing function.

Comment 27 Nathan Kinder 2010-11-22 21:57:11 UTC
Pushed to master.  Thanks to Rich for his review and to Ulf for his patch!

Counting objects: 11, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 1.56 KiB, done.
Total 6 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   23e2856..d38ae06  master -> master

Comment 32 Vincent Danen 2012-10-05 20:42:56 UTC
Upstream patch:


Judging by that, this was corrected in 389-ds


Comment 33 Rich Megginson 2012-10-05 21:48:00 UTC
(In reply to comment #32)
> Upstream patch:
> http://git.fedorahosted.org/cgit/389/ds.git/commit/?id=d38ae06
> Judging by that, this was corrected in 389-ds
> http://git.fedorahosted.org/cgit/389/ds.git/log/?h=389-ds-base-1.2.7

Correct.  Note that there are no 1.2.7 releases in circulation anymore, unless someone is still running Fedora 10.  All supported releases of 389-ds-base are using 1.2.10 or later, which all have this fix.

Comment 34 Vincent Danen 2012-10-11 15:53:01 UTC
Fantastic, thanks for the clarification.

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