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)
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.
Thanks Vincent. So, what is the recommended solution? Release an errata? Release note this behavior?
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.
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?
We would like to push out an update to our release notes by the middle of next week. Will that be a problem?
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.
Vincent - Ulf has already submitted a patch. We will most likely use the patch from Ulf in our code when we release the fix.
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?
(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.
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 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?
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.
Has HP released the fix to this yet?
This fix was released by HP on September 15.
Giving this the CVE name CVE-2010-4174
This is documented here: http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Release_Notes/Release_Notes-Bugs_Addressed-Known_Issues.html Statement: 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.
Created 389-ds tracking bugs for this issue Affects: fedora-all [bug 654054]
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)
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.
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
Upstream patch: http://git.fedorahosted.org/cgit/389/ds.git/commit/?id=d38ae06 Judging by that, this was corrected in 389-ds 1.2.7.1: http://git.fedorahosted.org/cgit/389/ds.git/log/?h=389-ds-base-1.2.7
(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 1.2.7.1: > > 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.
Fantastic, thanks for the clarification.