Comment 4 for bug 1698758

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Ok, got a better hang of it. crypt(3) can indeed be used like that, but the code needs to check for it returning NULL in the case of errors:
diff --git a/mod_auth_pgsql.c b/mod_auth_pgsql.c
index 0a16e05..4f80917 100644
--- a/mod_auth_pgsql.c
+++ b/mod_auth_pgsql.c
@@ -868,6 +868,12 @@ static authn_status check_password(request_rec *r, const char *user,
                        break;
                case AUTH_PG_HASH_TYPE_CRYPT:
                        sent_pw = (char *) crypt(sent_pw, real_pw);
+ if (!sent_pw) {
+ apr_snprintf(pg_errstr, MAX_STRING_LEN,
+ "PG user %s: password mismatch", user);
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, "[mod_auth_pgsql.c] - ERROR - %s", pg_errstr);
+ return AUTH_DENIED;
+ }
                        break;
                case AUTH_PG_HASH_TYPE_BASE64:
                        sent_pw = auth_pg_base64(sent_pw);

What happened is that the hash format you used, "{SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=", is not the type of input crypt(3) expects for the salt argument, hence the NULL return value (and the crash since that wasn't checked for).

The salt argument (the second argument) should either be:
- 2 characters for standard DES from the range [a-zA-Z0-9./]. Note how "{" or "}" are not there
- $id$salt$encrypted, where id means:
              ID | Method
              ────────────────────────────────────────────────────────
              1 | MD5
              2a | Blowfish (not in mainline glibc; added in some
                  | Linux distributions)
              5 | SHA-256 (since glibc 2.7)
              6 | SHA-512 (since glibc 2.7)

So the above patch fixes the crash, but you should use a different type of hash format. {SHA} is not supported. It is supported by apache's apr_password_validate(), but that is not used in this code.