oss-sec mailing list archives
Re: CVE Request: mini-httpd (<= v1.30) is affected by a response discrepancy information exposure (CWE-204)
From: Solar Designer <solar () openwall com>
Date: Wed, 12 Dec 2018 17:32:43 +0100
On Wed, Dec 12, 2018 at 04:27:02PM +0100, Salva Peir?? wrote:
The mini-httpd daemon (version <= v1.30) shipped in Debian/Ubuntu from [1] is affected by a response discrepancy information exposure (CWE-204) that enables an attacker to remotely enumerate valid htpasswd usernames (RFC 7617). A more detailed advisory can be found at: https://speirofr.appspot.com/files/advisory/SPADV-2018-01.md https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916190
The advisory SPADV-2018-01.md is in fact significantly more detailed than what you posted, so I've attached it to this message for archival.
Is there a CVE for this? If not, could one be assigned, please?
oss-security is no longer a place to request CVE IDs. See: https://oss-security.openwall.org/wiki/mailing-lists/oss-security#cve-requests "Previously, one could request CVE IDs for issues in Open Source software from oss-security. This is no longer the case. Instead, please start by posting about the (to be made) public issue to oss-security (without a CVE ID), request a CVE ID from MITRE directly, and finally "reply" to your own posting when you also have the CVE ID to add. With the described approach you would only approach MITRE after the issue is already public, but if you choose to do things differently and contact MITRE about an issue that is not yet public, then please do not disclose to them more than the absolute minimum needed for them to assign a CVE ID." You've already posted in here (great!) so all that's left is for you to request a CVE ID from MITRE and to post that CVE ID here as a "reply". However, I question the vulnerability finding or at least its completeness, so you might want to hold off on requesting a CVE ID for it. Please see below:
+++ b/mini_httpd.c @@ -2404,7 +2404,8 @@ auth_check( char* dirname ) /* Yes. */ (void) fclose( fp ); /* So is the password right? */ - if ( strcmp( crypt( authpass, cryp ), cryp ) == 0 ) + char *cryptpass = crypt( authpass, cryp ); + if ((cryptpass != NULL) && (strcmp(cryptpass, cryp ) == 0) )
While it's important to check the return from crypt(3) for non-NULL before using the string(*), if this were the issue triggering the vulnerability you describe that fix would be incomplete. (*) A general issue that was discussed in here some years ago, with opinions varying on whether crypt(3) should follow current POSIX and return NULL or retain historical behavior of never returning NULL not to upset programs written before the POSIX change. In the end, many libc's went with the NULL returns on error. Programs need to be fixed to support NULL returns from crypt(3) anyhow. In the advisory, you wrote:
When the basic authentication string "user:pass" is composed only of the user part without the password part, ie. "user:", then the authpass at mini_httpd.c:2372 becomes the empty string "". When the empty string is passed to the crypt(3) this returns the NULL string. The NULL string is later dereferenced by the strcmp(3) call at mini_httpd.c:2407 causing an invalid memory access that triggers the SIGSEGV, and kills the forked process.
This isn't a complete explanation. crypt(3) isn't supposed to return NULL when authpass is the empty string "". Empty string is a valid password, and should result in a valid password hash string, as long as the salt or setting string provided in the second argument to crypt(3) is valid. I can see how you'd trigger a NULL return from crypt(3) by having an empty or otherwise invalid password hash string in the .htpasswd file. So you'd be able to distinguish usernames corresponding to those lines with invalid hashes from usernames corresponding to lines with valid hashes. A crash on an invalid .htpasswd line is indeed a robustness bug, but I'm not sure it constitutes a vulnerability. This is different from being able to distinguish existing vs. non-existent usernames. (Besides, when fixing an issue of the kind you thought this one was, we should also remember that timing leaks will remain either way. I don't suggest to leave worse-than-timing leaks intact, but rather not to provide wrong expectations and a false sense of security once we do. And a next step may be to reduce timing leaks by performing dummy password hashing for non-existent usernames, again being careful to point out that smaller timing leaks will remain.) If the behavior is in fact exactly as you observed it, then maybe your system's libc or libcrypt is vulnerable in that it's incapable of processing an empty password. I almost wonder if someone thought it'd be OK to implement e.g. some security standardization compliance by having crypt(3) fail to process an empty password and return NULL. If so, that would be an interesting case for us to discuss. Please investigate this further. Thanks, Alexander
Attachment:
SPADV-2018-01.md
Description:
Current thread:
- CVE Request: mini-httpd (<= v1.30) is affected by a response discrepancy information exposure (CWE-204) Salva Peiró (Dec 12)
- Re: CVE Request: mini-httpd (<= v1.30) is affected by a response discrepancy information exposure (CWE-204) Solar Designer (Dec 12)
- Re: CVE Request: mini-httpd (<= v1.30) is affected by a response discrepancy information exposure (CWE-204) Salvatore Bonaccorso (Dec 12)