Bug 54735 - htpasswd creates wrong passfile
htpasswd creates wrong passfile
Status: RESOLVED FIXED
Product: Apache httpd-2
Classification: Unclassified
Component: support
2.4.4
PC Linux
: P2 normal with 1 vote (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
: FixedInTrunk
: 54927 55086 (view as bug list)
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2013-03-20 20:24 UTC by Marco
Modified: 2014-02-17 15:18 UTC (History)
4 users (show)



Attachments
Patch for "httpd-2.4.4/support/passwd_common.c". (618 bytes, text/plain)
2013-03-31 07:09 UTC, MadMaverick9
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marco 2013-03-20 20:24:51 UTC
Found on
OS debian lenny or Ubuntu 12.04
pcre 8.32
php 5.4.13
apr 1.4.6
apr-utils 1.5.1

htpasswd -c username 
never generates a correct hashed password.
htpasswd -nb username pass > conf/htpasswd
has to be used instead.
Tested with md5 and plain password, even last one are not created correctly.
Of course autentication fails with first method and works with second one.

Feel free to contact me if you need further informations.
Comment 1 Stefan Fritsch 2013-03-20 22:20:58 UTC
(In reply to comment #0)
> htpasswd -c username 

That's not a valid command line. You mean

htpasswd -c conf/htpasswd username

? But this works for me. Can you post the contents of the created file?


> never generates a correct hashed password.
> htpasswd -nb username pass > conf/htpasswd
> has to be used instead.
> Tested with md5 and plain password, even last one are not created correctly.
> Of course autentication fails with first method and works with second one.

Plain passwords do not work under Unix (as hinted by the help text).
Comment 2 Marco 2013-03-21 04:36:57 UTC
password used is "test" 

/usr/local/apache2/conf# ../bin/htpasswd -c testpasswdfile username
New password: 
Re-type new password: 
Adding password for user username
/usr/local/apache2/conf# cat testpasswdfile           
username:$apr1$GvGApC2k$aW7v79G7y8ElbO/ZjoAOz1

/usr/local/apache2/conf# ./bin/htpasswd -cp testpasswdfile username
Warning: storing passwords as plain text might just not work on this platform.
New password: 
Re-type new password: 
Adding password for user username
/usr/local/apache2/conf# cat testpasswdfile 
username:P%m6�

/usr/local/apache2/conf# ../bin/htpasswd -bnp username test
Warning: storing passwords as plain text might just not work on this platform.
username:test


Yes sorry about the wrong commandline. What i meant about plain password was that even those plain aren't created correctly when prompted. Although it might not work as the tool says, it should anyway write a correct file.

I provide you more hashes
username:$apr1$QnVANHT3$hMtF7Eu1pFw0KAWSROiOy.   < test used as password
username:$apr1$UNe/gu.y$u.0Y03o4WbpCNTQe8n5tV0   < test used as password
username:$apr1$1gG7fHEq$/EVL3lXjfQ/fazeoiloDw1   < notworking used as password
Comment 3 Marco 2013-03-21 04:38:47 UTC
../bin/httpd -V
Server version: Apache/2.4.4 (Unix)
Server built:   Mar 20 2013 08:27:18
Server's Module Magic Number: 20120211:11
Server loaded:  APR 1.4.6, APR-UTIL 1.5.1
Compiled using: APR 1.4.6, APR-UTIL 1.5.1
Architecture:   64-bit
Server MPM:     event
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/usr/local/apache2"
 -D SUEXEC_BIN="/usr/local/apache2/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"
Comment 4 MadMaverick9 2013-03-31 07:01:20 UTC
As far as I can tell this is caused by a bug in "httpd-2.4.4/support/passwd_common.c". I created the following patch and it works again.

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) {
Comment 5 MadMaverick9 2013-03-31 07:09:47 UTC
Created attachment 30123 [details]
Patch for "httpd-2.4.4/support/passwd_common.c".

Even though this patch fixes the problem at hand, the "get_password" function in "httpd-2.4.4/support/passwd_common.c" really should not put the password into "ctx->out", but into "ctx->passwd".
Comment 6 Stefan Fritsch 2013-04-05 20:21:24 UTC
Thanks for debugging this. Trunk commit: r1465115
Comment 7 Stefan Fritsch 2013-04-05 20:22:39 UTC
BTW, it's rather fascinating that the buggy variant worked for me. It looks like the password was on the right place on the stack on my system.
Comment 8 MadMaverick9 2013-04-06 06:43:38 UTC
> BTW, it's rather fascinating that the buggy variant worked for me. It looks like the password was on the right place on the stack on my system.

I wonder if that has something to do with different versions of gcc maybe. I am using "gcc 4.7.1" on a default Slackware 14.0 install.

Would it be possible to apply this patch to the "2.4.x" branch? So that the fix would be included in a future httpd 2.4.5 release.

Thank you very much for your work.
Comment 9 Graham Leggett 2013-04-27 21:28:17 UTC
Backported to v2.4.5.
Comment 10 Eric Covener 2013-05-04 05:19:29 UTC
*** Bug 54927 has been marked as a duplicate of this bug. ***
Comment 11 Stefan Fritsch 2013-06-09 20:20:41 UTC
*** Bug 55086 has been marked as a duplicate of this bug. ***
Comment 12 Stefan Fritsch 2013-06-09 20:22:19 UTC
Reopening until 2.4.5 is actually released. Hopefully this makes it easier to find this PR.
Comment 13 Dennis Clarke 2013-06-10 03:10:11 UTC
I apologize for the dup 55086. I should have really scanned for
the existing bug reports better.

However I have the very real problem that I am running Apache 2.4.4
on Solaris and in production so this is a bit of a problem for me.

I am able, as seen in my duplicate bug report, to create and update
users in the password file while using the -b "batch" option. That
seems to work well. For now.

When should we expect, and you knew I was about to ask, the release 
of 2.4.5 ? 

Is there a neatly isolated patch as well as a manner to build just 
the htpasswd binary ?  I don't think it should be necessary to 
compile all of Apache from ground zero just to get this one binary.
At least, I sure hope not. I have a very stable 2.4.4 now and the 
performance on the Niagara class Oracle servers is just magnificent
and I really don't want to enter a thirty day testing phase and 
validation phase just to get htpasswd working as expected. Hope I
don't seem to whine here but a stable httpd 2.4.4 exists now and it 
was not trivial for me to get it into real world production for my
users.

Dennis
Comment 14 Rainer Jung 2013-06-10 04:54:05 UTC
(In reply to Dennis Clarke from comment #13)

> Is there a neatly isolated patch as well as a manner to build just 
> the htpasswd binary ?

Patch

http://people.apache.org/~rjung/patches/2.4-htpass.patch

should apply cleanly on top of a 2.4.4 source tree.

It contains revisions

svn.apache.org/r1455225
svn.apache.org/r1476089
svn.apache.org/r1467978
svn.apache.org/r1476674
svn.apache.org/r1477651
svn.apache.org/r1490564

and fixes at least PRs 53690, 54345, 54346, 54735 and 54893.

If you use your old 2.4.4 build directory and apply the patch, a "make" should simply rebuild

- htpasswd
- htdbm
- htdigest

Concerning 2.4.5 there is no fixed date yet, although there were some discussions to cut the release soon. Don't plan for it in the next days though.
Comment 15 Dennis Clarke 2013-06-10 18:40:08 UTC
I applied that patch, did a re-make and sure enough I have a few new files : 

node002$ find . -newer $SRC/2.4-htpass.patch -ls 
2279859   13 drwxr-xr-x  12 dclarke  other          52 Jun 10 17:52 .
2279897    5 drwxr-xr-x   5 dclarke  other         102 Jun 10 17:52 ./support
1139900    1 -rw-r--r--   1 dclarke  other         272 Jun 10 17:52 ./support/passwd_common.lo
1139897    1 -rw-r--r--   1 dclarke  other         262 Jun 10 17:52 ./support/htpasswd.lo
1139890    9 -rw-r--r--   1 dclarke  other       16495 Jun 10 17:48 ./support/htpasswd.c
1139888    5 -rw-r--r--   1 dclarke  other        8147 Jun 10 17:48 ./support/htdigest.c
1139905   18 -rw-r--r--   1 dclarke  other       41200 Jun 10 17:52 ./support/htdbm.o
1139899   14 -rw-r--r--   1 dclarke  other       28984 Jun 10 17:52 ./support/passwd_common.o
1139906    1 -rw-r--r--   1 dclarke  other         256 Jun 10 17:52 ./support/htdbm.lo
2283202   28 -rwxr-xr-x   1 dclarke  other       57176 Jun 10 17:52 ./support/htpasswd
2283210   29 -rwxr-xr-x   1 dclarke  other       59912 Jun 10 17:52 ./support/htdbm
1139889    3 -rw-r--r--   1 dclarke  other        2908 Jun 10 17:48 ./support/passwd_common.h
2283206   15 -rwxr-xr-x   1 dclarke  other       30040 Jun 10 17:52 ./support/htdigest
1139903    1 -rw-r--r--   1 dclarke  other         262 Jun 10 17:52 ./support/htdigest.lo
1139896   17 -rw-r--r--   1 dclarke  other       36864 Jun 10 17:52 ./support/htpasswd.o
1139902   13 -rw-r--r--   1 dclarke  other       28056 Jun 10 17:52 ./support/htdigest.o
1139886    8 -rw-r--r--   1 dclarke  other       14325 Jun 10 17:48 ./support/htdbm.c
1139887    6 -rw-r--r--   1 dclarke  other       10009 Jun 10 17:48 ./support/passwd_common.c
node002$ 
node002$ 
node002$ file ./support/htpasswd ./support/htdbm ./support/passwd_common.h ./support/htdigest 
./support/htpasswd: ELF 64-bit MSB executable SPARCV9 Version 1, UltraSPARC3 Extensions Required, dynamically linked, not stripped
./support/htdbm: ELF 64-bit MSB executable SPARCV9 Version 1, UltraSPARC3 Extensions Required, dynamically linked, not stripped
./support/passwd_common.h: ascii text
./support/htdigest: ELF 64-bit MSB executable SPARCV9 Version 1, UltraSPARC3 Extensions Required, dynamically linked, not stripped
node002$

That header file seems to live in the build tree and never needs to be installed
in the $DESTDIR/include so I will leave that behind. 

I backup the existing buggy bins : 

node002$ cp -p /usr/local/bin/htdbm /usr/local/bin/htdbm_bug54735
node002$ cp -p /usr/local/bin/htdigest /usr/local/bin/htdigest_bug54735
node002$ cp -p /usr/local/bin/htpasswd /usr/local/bin/htpasswd_bug54735

drop in the new bins : 

node002-sparc-SunOS5.10 # cp -p ./support/htpasswd /usr/local/bin/htpasswd
node002-sparc-SunOS5.10 # cp -p ./support/htdbm /usr/local/bin/htdbm
node002-sparc-SunOS5.10 # cp -p ./support/htdigest /usr/local/bin/htdigest


node002-sparc-SunOS5.10 # chown root:root /usr/local/bin/htpasswd /usr/local/bin/htdbm /usr/local/bin/htdigest

node002-sparc-SunOS5.10 # ls -lap /usr/local/bin/htpasswd /usr/local/bin/htdbm /usr/local/bin/htdigest
-rwxr-xr-x   1 root     root       59912 Jun 10 17:52 /usr/local/bin/htdbm
-rwxr-xr-x   1 root     root       30040 Jun 10 17:52 /usr/local/bin/htdigest
-rwxr-xr-x   1 root     root       57176 Jun 10 17:52 /usr/local/bin/htpasswd

quick and dirty test : 

node002-sparc-SunOS5.10 # /usr/local/bin/htpasswd /usr/local/www/conf/.htpasswd bug54735test
New password: 
Re-type new password: 
Adding password for user bug54735test
node002-sparc-SunOS5.10 # grep bug54735test .htpasswd
bug54735test:$apr1$mBhdHE3M$AmZp9nuLI9DC7D.H7OO.51

first test works like a charm : 

node002-sparc-SunOS5.10 # grep bug54735test /usr/local/www/var/logs/ssl_request_log
xxx.xxx.52.207 - bug54735test [10/Jun/2013:18:10:02 +0000] "GET /foo.php HTTP/1.1" 200 75883 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130515 Firefox/17.0 Iceweasel/17.0.6"

looks to be a good patch, however I will keep our internal bug report open until 2.4.5 releases, 
for now I would say that there is no need for a triage or validation phase because the core 
services have not been touched and thus this is a great little patch. Already rolled those
bins out to a collection of servers.

I give thanks and praise to those involved and am a very happy user!

Dennis