BUG #18379: LDAP bind password exposed

PG Bug reporting form <noreply@postgresql.org> writes:

Whenever a login attempt is made using LDAP authentication, the entire
configuration line from the pg_hba.conf file is being logged in the
PostgreSQL log files. This includes the LDAP bind password (ldapbindpasswd),
which is being recorded in plaintext. This practice poses a serious security
risk, as it exposes sensitive credentials in log files that might be
accessed by unauthorized individuals.

We do not consider this a bug. There are very many ways that
sensitive information could appear in the postmaster log file.
There's no way to block them all, not least because some items
are ones that the server could not know are sensitive (consider
for instance credit card details, or medical information in a
database under HIPAA rules). You *must* make arrangements to
secure the postmaster log equally carefully as the database itself.

Having said that, you might consider moving away from LDAP
authentication. It's not considered best practice anymore,
notably because it requires the server to see the user's
unencrypted password, and then turn around and pass that on
to the LDAP server. GSSAPI/SSPI (a/k/a Kerberos, or Active
Directory in the Microsoft universe) provide substantially
better centralized authentication technology that's more
secure in quite a few ways.

regards, tom lane

On Wed, 2024-03-06 at 13:51 +0000, PG Bug reporting form wrote:

PostgreSQL version: 15.3

I am writing to seek your assistance regarding a security concern we have
encountered with our PostgreSQL database setup. We are currently utilizing
LDAP authentication as specified in our pg_hba.conf file. However, upon
reviewing the PostgreSQL logs, we have observed an issue that is causing us
significant concern.

Whenever a login attempt is made using LDAP authentication, the entire
configuration line from the pg_hba.conf file is being logged in the
PostgreSQL log files. This includes the LDAP bind password (ldapbindpasswd),
which is being recorded in plaintext. This practice poses a serious security
risk, as it exposes sensitive credentials in log files that might be
accessed by unauthorized individuals.

There is no way to prevent that short of stopping to log errors.

But I am afraid that that won't be your only problem if you let unauthorized
individuals read your log files. Any statement that causes an error and
contains sensitive information will become a problem, and if you set
"log_statement = 'ddl'", anybody who changes their password without
encrypting it on the client side will find the password in the log.

Log files should be treated as sensitive data.

Yours,
Laurenz Albe

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

PG Bug reporting form <noreply@postgresql.org> writes:

Whenever a login attempt is made using LDAP authentication, the entire
configuration line from the pg_hba.conf file is being logged in the
PostgreSQL log files. This includes the LDAP bind password (ldapbindpasswd),
which is being recorded in plaintext. This practice poses a serious security
risk, as it exposes sensitive credentials in log files that might be
accessed by unauthorized individuals.

We do not consider this a bug. There are very many ways that
sensitive information could appear in the postmaster log file.
There's no way to block them all, not least because some items
are ones that the server could not know are sensitive (consider
for instance credit card details, or medical information in a
database under HIPAA rules). You *must* make arrangements to
secure the postmaster log equally carefully as the database itself.

While I agree that users should take steps to secure their log files,
I'd argue that it's best practice to avoid dumping sensitive data into
log files, which it seems like it would be in this case. I'm not
suggesting that this is bug-worthy or that we should go to excessive
lengths to try and prevent every such case, but if someone showed up
with a reasonable patch to replace the sensitive information in a pg_hba
line with ****, I would be on the side of supporting that.

Having said that, you might consider moving away from LDAP
authentication. It's not considered best practice anymore,
notably because it requires the server to see the user's
unencrypted password, and then turn around and pass that on
to the LDAP server. GSSAPI/SSPI (a/k/a Kerberos, or Active
Directory in the Microsoft universe) provide substantially
better centralized authentication technology that's more
secure in quite a few ways.

Fully agree with this. The best approach to dealing with this is to
move away from PG's 'ldap' auth type.

Thanks!

Stephen

Stephen Frost <sfrost@snowman.net> writes:

While I agree that users should take steps to secure their log files,
I'd argue that it's best practice to avoid dumping sensitive data into
log files, which it seems like it would be in this case. I'm not
suggesting that this is bug-worthy or that we should go to excessive
lengths to try and prevent every such case, but if someone showed up
with a reasonable patch to replace the sensitive information in a pg_hba
line with ****, I would be on the side of supporting that.

I dunno, I think it would mostly serve to set false expectations.
We've repeatedly rejected requests to scrub the log of passwords
found in CREATE/ALTER USER commands, for example. I think some
of the same issues that led to that conclusion would apply here,
notably that a syntax error could lead to failing to recognize
at all that some substring is a password. (A visibly erroneous
pg_hba line would not get quoted in the specific context the OP
complains of, but I'm pretty sure we'd print it while logging
the configuration reload failure.)

regards, tom lane

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

Stephen Frost <sfrost@snowman.net> writes:

While I agree that users should take steps to secure their log files,
I'd argue that it's best practice to avoid dumping sensitive data into
log files, which it seems like it would be in this case. I'm not
suggesting that this is bug-worthy or that we should go to excessive
lengths to try and prevent every such case, but if someone showed up
with a reasonable patch to replace the sensitive information in a pg_hba
line with ****, I would be on the side of supporting that.

I dunno, I think it would mostly serve to set false expectations.

I appreciate that concern. I don't think it will though.

We've repeatedly rejected requests to scrub the log of passwords
found in CREATE/ALTER USER commands, for example. I think some
of the same issues that led to that conclusion would apply here,
notably that a syntax error could lead to failing to recognize
at all that some substring is a password. (A visibly erroneous
pg_hba line would not get quoted in the specific context the OP
complains of, but I'm pretty sure we'd print it while logging
the configuration reload failure.)

While this may not be popular, I'd be in support of doing away with
support for cleartext passwords being accepted through CREATE/ALTER USER
commands, therefore eliminating this issue entirely. As discussed on
this very thread, passing passwords in the clear from the client to the
server, in any context, goes against best practices, which is why PG's
ldap auth method is discouraged as it does exactly that.

Doing this would, ideally at least, result in a lot more use of libpq's
PQchangePassword() and \password in psql, which would further reduce the
chances of a syntax error ending up dumping sensitive data into the log
(the server's SCRAM password authenticator would still be considered
sensitive and worthy of hiding, imv, but I wouldn't push as hard on that
as it's clearly less of a risk than the user's cleartext password).

Sure, mistakes could still happen and we couldn't do anything about it
(a user might *try* to pass in a cleartext password via ALTER USER *and*
have a syntax mistake), but now we're really looking at low probability
issues.

Thanks!

Stephen

On Thu, Mar 7, 2024 at 1:34 AM Stephen Frost <sfrost@snowman.net> wrote:

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

Stephen Frost <sfrost@snowman.net> writes:

While I agree that users should take steps to secure their log files,
I'd argue that it's best practice to avoid dumping sensitive data into
log files, which it seems like it would be in this case. I'm not
suggesting that this is bug-worthy or that we should go to excessive
lengths to try and prevent every such case, but if someone showed up
with a reasonable patch to replace the sensitive information in a

pg_hba

line with ****, I would be on the side of supporting that.

I dunno, I think it would mostly serve to set false expectations.

I appreciate that concern. I don't think it will though.

We've repeatedly rejected requests to scrub the log of passwords
found in CREATE/ALTER USER commands, for example. I think some
of the same issues that led to that conclusion would apply here,
notably that a syntax error could lead to failing to recognize
at all that some substring is a password. (A visibly erroneous
pg_hba line would not get quoted in the specific context the OP
complains of, but I'm pretty sure we'd print it while logging
the configuration reload failure.)

While this may not be popular, I'd be in support of doing away with
support for cleartext passwords being accepted through CREATE/ALTER USER
commands, therefore eliminating this issue entirely. As discussed on
this very thread, passing passwords in the clear from the client to the
server, in any context, goes against best practices, which is why PG's
ldap auth method is discouraged as it does exactly that.

Doing this would, ideally at least, result in a lot more use of libpq's
PQchangePassword() and \password in psql, which would further reduce the
chances of a syntax error ending up dumping sensitive data into the log
(the server's SCRAM password authenticator would still be considered
sensitive and worthy of hiding, imv, but I wouldn't push as hard on that
as it's clearly less of a risk than the user's cleartext password).

Sure, mistakes could still happen and we couldn't do anything about it
(a user might *try* to pass in a cleartext password via ALTER USER *and*
have a syntax mistake), but now we're really looking at low probability
issues.

All the philosophical stuff aside, I think this could be avoided by the
deployment of an ldap_password_hook, which is designed to allow mangling of
the bindpasswd before it's passed to the ldap server. There's a trivial
example in src/test/modules/ldap_password_func

It's available in release 16, so the OP would need to upgrade.

cheers

andrew