Thread: BUG #17593: min key size 112 bits from FIPS SP800-131 requirement for HMAC-SHA raises exception in SCRAM-SHA-256
BUG #17593: min key size 112 bits from FIPS SP800-131 requirement for HMAC-SHA raises exception in SCRAM-SHA-256
From
PG Bug reporting form
Date:
The following bug has been logged on the website: Bug reference: 17593 Logged by: Scott Zelenka Email address: szelenka@gmail.com PostgreSQL version: 14.5 Operating system: Ubuntu 20.04 Description: Running postgres with: postgres -D /home/postgres/pgdata/pgroot/data \ --password_encryption=scram-sha-256 \ --ssl=on \ --ssl_cert_file='/run/certs/server.crt' \ --ssl_key_file='/run/certs/server.key' Will raise an error when attempting to create a ROLE with a SCRAM-SHA-256 password: CREATE ROLE "test-enc-pw" LOGIN ENCRYPTED PASSWORD 'SCRAM-SHA-256$4096:RlI0UDRNeEFSRUp0Y29kWA==$knE29fNkMKTvocaIou0vfZ+J+lwp4hawGKrXPVDOA08=:ZMQb8JU1qRdMv0wjFUBuD/E2G+YJhHV+KBSVzDC6ifA='; Running on Postgres 125 BETA 3 gives more context into the error: ERROR: could not compute server key: invalid key length The "invalid key length" is returned from the FIPS Validated OpenSSL library Postgres is linked to. Where it is enforcing FIPS SP800-131 requirement for HMAC-SHA, minimum key size is 112 bits when used for security purposes. This appears to be triggered during the NULL password check during CREATE ROLE: https://github.com/postgres/postgres/blob/REL_15_BETA3/src/backend/commands/user.c#L373 Attaching a debugger, we can see that in normal code execution path, the plain_crypt_verify method should return STATUS_ERROR (because the password is not actually empty) then continue on it’s way to perform the actual encryption. But because we specify SCRAM-SHA we trigger scram_verify_plain_password: https://github.com/postgres/postgres/blob/REL_15_BETA3/src/backend/libpq/crypt.c#L236-L239 Which causes it to error out, rather than returning a STATUS_ERROR like the working path(s). There seems to be a conflict with how the NULL password is checked for, and enforcement of FIPS SP800-131 by a FIPS Validated OpenSSL library.
Re: BUG #17593: min key size 112 bits from FIPS SP800-131 requirement for HMAC-SHA raises exception in SCRAM-SHA-256
From
Scott Zelenka
Date:
This patch seems to mitigate the issue. Not sure if this is the best approach, or if there's another place we should watch out for empty passwords when dealing with SCRAM-SHA-256 and FIPS.
diff -Nruw postgresql/src/backend/libpq/auth-scram.c postgresql.new/src/backend/libpq/auth-scram.c
--- postgresql/src/backend/libpq/auth-scram.c 2022-08-08 20:44:29.000000000 +0000
+++ postgresql.new/src/backend/libpq/auth-scram.c 2022-08-26 00:10:57.812215180 +0000
@@ -522,6 +522,13 @@
return false;
}
+ if (strlen(password) == 0)
+ {
+ ereport(LOG,
+ (errmsg("invalid SCRAM password for user \"%s\"", username)));
+ return false;
+ }
+
/* Normalize the password */
rc = pg_saslprep(password, &prep_password);
if (rc == SASLPREP_SUCCESS)
On Thu, Aug 25, 2022 at 1:27 PM PG Bug reporting form <noreply@postgresql.org> wrote:
The following bug has been logged on the website:
Bug reference: 17593
Logged by: Scott Zelenka
Email address: szelenka@gmail.com
PostgreSQL version: 14.5
Operating system: Ubuntu 20.04
Description:
Running postgres with:
postgres -D /home/postgres/pgdata/pgroot/data \
--password_encryption=scram-sha-256 \
--ssl=on \
--ssl_cert_file='/run/certs/server.crt' \
--ssl_key_file='/run/certs/server.key'
Will raise an error when attempting to create a ROLE with a SCRAM-SHA-256
password:
CREATE ROLE "test-enc-pw" LOGIN ENCRYPTED PASSWORD
'SCRAM-SHA-256$4096:RlI0UDRNeEFSRUp0Y29kWA==$knE29fNkMKTvocaIou0vfZ+J+lwp4hawGKrXPVDOA08=:ZMQb8JU1qRdMv0wjFUBuD/E2G+YJhHV+KBSVzDC6ifA=';
Running on Postgres 125 BETA 3 gives more context into the error:
ERROR: could not compute server key: invalid key length
The "invalid key length" is returned from the FIPS Validated OpenSSL library
Postgres is linked to. Where it is enforcing FIPS SP800-131 requirement for
HMAC-SHA, minimum key size is 112 bits when used for security purposes.
This appears to be triggered during the NULL password check during CREATE
ROLE:
https://github.com/postgres/postgres/blob/REL_15_BETA3/src/backend/commands/user.c#L373
Attaching a debugger, we can see that in normal code execution path, the
plain_crypt_verify method should return STATUS_ERROR (because the password
is not actually empty) then continue on it’s way to perform the actual
encryption. But because we specify SCRAM-SHA we trigger
scram_verify_plain_password:
https://github.com/postgres/postgres/blob/REL_15_BETA3/src/backend/libpq/crypt.c#L236-L239
Which causes it to error out, rather than returning a STATUS_ERROR like the
working path(s).
There seems to be a conflict with how the NULL password is checked for, and
enforcement of FIPS SP800-131 by a FIPS Validated OpenSSL library.