htpasswd no longer working after upgrade to 14.0

DaijoubuKun · 03-16-2013, 07:55 PM

Hello everyone, I'm having issues with htpasswd now that I have upgraded my server to Slackware 14.0 (worked fine in 13.1). When I generate a few user in a .htpasswd file, I cannot authenticate as that user, however, if I use htpasswd on another distribution and copy it over, it works fine.

I want to give a bit more information just to help ensure I'm giving good information.

I wish to add a simple level of authentication to view a stats page on my server. Not only myself, but others will need access. I can copy my username and password from a previous .htpasswd file and it works fine (from when I was running an older Slackware version), but when I try to use htpasswd now, no one can authenticate.

Here is the snippit from my apache config.

Code:

<Files "awstats.pl"> 
  AuthType Basic
  AuthName "Do you have a login?"
  AuthBasicProvider file
  AuthUserFile /srv/www/mydomain.com/.passwd.awstats
  Require valid-user
</Files>

The only thing I get in my apache error log in authentication failure to "file" Password Mismatch.

I know I'm pointing to the correct file since if I copy over a previous pass generated before the upgrade or on another distribution, it works great. Has anyone else ever ran into this one? I think it maybe an issue with the Apache 2.4.4 as the other disros I have used are running 2.2 and I have tried this on 5 different Slackware 14 (some 64bit, some 32) machines and I continue to have the same issue. Any help on this would be greatly appreciated. Thank you.

UPDATE: I have tried to do this with a couple other distros now (all running apache 2.2.x). And it seems the others use CRYPT by default (which works) and Slackware uses MD5 by default (which no longer works), but CRYPT fails when I try to force it in Slackware.

ljb643 · 03-16-2013, 10:14 PM

Yes... just tried it and confirmed. Apache httpd (both the original 2.4.3 and newer 2.4.4) does not seem to work with basic authentication passwords encoded by htpasswd. It fails with crypt, MD5, and SHA methods. I don't know what is wrong, but the problem seems to be in htpasswd itself (as you found), not Apache httpd.

As a work-around, you can encode MD5 passwords (here "MyPassword") for your password file like this:

Code:

$ openssl passwd -apr1 MyPassword

Paste the result into your password file, putting "username:" in front. I tried this and it did work. But I would really like to know what is wrong with the htpasswd command, and why (per your post) it is only on Slackware 14.

MadMaverick9 · 03-17-2013, 12:38 AM

I can confirm this too.

But ... when I specify the password on the command line with "-b" it works.

When I specify "-i" or the default password prompt, it is broken.

MadMaverick9 · 03-17-2013, 01:06 AM

It's actually a bug in the upstream source:

Code:

diff -ur httpd-2.4.4-orig/support/passwd_common.c httpd-2.4.4/support/passwd_common.c
--- httpd-2.4.4-orig/support/passwd_common.c    2012-12-11 17:37:25.000000000 +0700
+++ httpd-2.4.4/support/passwd_common.c 2013-03-17 13:33:58.429462196 +0700
@@ -146,7 +146,6 @@
 int mkhash(struct passwd_ctx *ctx)
 {
     char *pw;
-    char pwin[MAX_STRING_LEN];
     char salt[16];
     apr_status_t rv;
     int ret = 0;
@@ -165,7 +164,7 @@
     else {
         if ((ret = get_password(ctx)) != 0)
             return ret;
-        pw = pwin;
+        pw = strdup(ctx->out);
     }
 
     switch (ctx->alg) {

When I made the above modification, it works. I could not find a bug in httpd's bugzilla. Hopefully somebody can confirm the bug and review my fix.

Update 4: this fixes it, but it's not right. The "get_password" function really should not put the password into "ctx->out", but into "ctx->passwd".

ponce · 03-17-2013, 01:45 AM

htpasswd has been refactored recently, can be something slipped/must be fixed: maybe it's better to file a bug upstream for this.

https://svn.apache.org/viewvc?view=r...vision=1420084

https://issues.apache.org/bugzilla/

DaijoubuKun · 03-17-2013, 02:01 AM

The first 2 replies, I can confirm as working.

Quote:

openssl passwd -apr1 MyPassword

and

Quote:

But ... when I specify the password on the command line with "-b" it works.

I have been trying some of the other distributions I have, but none of them are running Apache 2.4 yet, even in their experimental releases. So I haven't been able to test if this is a Slackware specific thing or not. However, after reviewing the Slackware build script in the source, I don't believe it is. Looks like we need to get this bug into Apache's tracker.

In the mean while, I have a single line script here that will allow anyone to create a new password without having to type it directly into the console. It's not elegant, but it works.

Code:

read -p "Username: " username; read -p "Password: " -s temppass; htpasswd -b .htpasswd $username $temppass

Add -c after -b if you are creating a new file.

MadMaverick9 · 03-17-2013, 07:39 AM

Using "-b" is dangerous, because users can do a "ps" and see other user's passwords. So on a server where many users can login this is not a good idea.

Code:

/tmp/sb-httpd/httpd-2.4.4-orig/support/ > grep -i pwin passwd_common.* htpasswd.*
passwd_common.c:    char pwin[MAX_STRING_LEN];
passwd_common.c:        pw = pwin;

This is a little more than a slip. No value is ever assigned to "pwin".

I also checked the Apache HTTPD mailing lists (http://mail-archives.apache.org/mod_mbox/httpd-users/) and I could not find any mention of this bug. I searched for "htpasswd" in the subject lines.

ponce · 03-17-2013, 08:12 AM

maybe this is related

https://issues.apache.org/bugzilla/s...g.cgi?id=40243

if useful, the revisions involved for the changes to support/htpasswd.c and support/htdbm.c are

https://svn.apache.org/viewvc?view=r...vision=1420084
https://svn.apache.org/viewvc?view=r...vision=1420925
https://svn.apache.org/viewvc?view=r...vision=1455225

DaijoubuKun · 03-17-2013, 11:18 AM

Quote:

Originally Posted by MadMaverick9

Using "-b" is dangerous, because users can do a "ps" and see other user's passwords. So on a server where many users can login this is not a good idea.

This is true, however, the other users better have incredible timing unless it takes the server a long time to generate a pass. It takes mine under one second, so any others who are logged in are not likely to see anything. The other benefit to that one-liner is the variables are only used until the end of execution then removed from memory. So there is not way to pull the variables or view your history to find the password.

ljb643 · 03-17-2013, 01:32 PM

Quote:

Originally Posted by MadMaverick9

...

Code:

/tmp/sb-httpd/httpd-2.4.4-orig/support/ > grep -i pwin passwd_common.* htpasswd.*
passwd_common.c:    char pwin[MAX_STRING_LEN];
passwd_common.c:        pw = pwin;

This is a little more than a slip. No value is ever assigned to "pwin".

It's OK - it is a pointer assignment. pw (the pointer) is assigned to point to the start of the pwin array.

There is a bug somewhere in here, but that isn't it.

The most likely culprit is that patch that was applied to 2.4.4 (found above by ponce) to add the -i option. I have a feeling htpasswd is now encrypting something other than the actual password, or perhaps the password with extra junk or truncated. It's kind of disturbing that something like that made it into a release and broke the most basic usage.

ljb643 · 03-17-2013, 02:17 PM

Quote:

Originally Posted by ljb643

It's OK - it is a pointer assignment. pw (the pointer) is assigned to point to the start of the pwin array.

Oops, sorry, my mistake. Seen in context of the code in passwd_common.c I can see that you are correct. It looks to me like it is hashing a bunch of random garbage (pw), because the password went somewhere else.

MadMaverick9 · 03-31-2013, 02:14 AM

https://issues.apache.org/bugzilla/s...g.cgi?id=54735

Gnisho · 05-10-2013, 10:20 PM

Just ran afoul of this bug today. It's fixed upstream.

http://svn.apache.org/viewvc?view=re...vision=1465115

MadMaverick9 · 05-11-2013, 12:21 AM

http://svn.apache.org/viewvc?view=re...vision=1476674

It was applied to the 2.4.x branch. So the next release of httpd, 2.4.5, will include the fix.