Thread: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs

The following bug has been logged on the website:

Bug reference:      18817
Logged by:          Indrajeet Deshmukh
Email address:      bkindrajeeth@gmail.com
PostgreSQL version: 15.0
Operating system:   Linux
Description:

Namaste Team,

During the integration of PostgreSQL Database v15 logs into a SIEM
solution,I observed that user passwords are logged in plaintext when a user
is created using the database command. This poses a serious security risk as
credentials could be exposed to unauthorized users who have access to the
logs.

Vendor: PostgreSQL
Product: PostgreSQL Database
Version: 15
Severity: High
Issue Type: Security Vulnerability

Steps to Reproduce:
Open the PostgreSQL Database CLI or execute the command via a script.
Run the following command to create a new user: 

CREATE USER indrajeet WITH PASSWORD 'indrajeet'

Check the database logs (/var/lib/pgsql/data/log). Below is the JSON log
generated when I used indrajeet as user name and indrajeet as password.

{"timestamp":"2025-02-18 08:11:38.557

UTC","user":"postgres","dbname":"postgres","pid":6069,"remote_host":"ip-100-66-2-217.ec2.internal","remote_port":53964,"session_id":"67b44074.17b5","line_num":4,"ps":"idle","session_start":"2025-02-18
08:10:28
UTC","vxid":"4/29","txid":0,"error_severity":"LOG","message":"statement:
CREATE USER indrajeet WITH PASSWORD
'indrajeet';","application_name":"psql","backend_type":"client
backend","query_id":0}

Expected Behavior: The password should be masked or excluded from logs to
prevent exposure.

Security Impact:
Confidentiality Violation: Anyone with access to logs can view user
passwords.
Risk of Credential Theft: Attackers or unauthorized users can leverage
exposed credentials for privilege escalation or lateral movement.
Compliance Issues: This may violate security policies and regulations (e.g.,
GDPR, PCI-DSS, ISO 27001).

Please do let me know if you need additional details from my side.

Thanks,
Indrajeet Deshmukh

On Tue, 18 Feb 2025 at 22:51, PG Bug reporting form
<noreply@postgresql.org> wrote:
> During the integration of PostgreSQL Database v15 logs into a SIEM
> solution,I observed that user passwords are logged in plaintext when a user
> is created using the database command. This poses a serious security risk as
> credentials could be exposed to unauthorized users who have access to the
> logs.

> Steps to Reproduce:

> CREATE USER indrajeet WITH PASSWORD 'indrajeet'

There's some relevant discussion about this in [1], in particular, see [2].

David

[1]
https://www.postgresql.org/message-id/flat/CALNJ-vRQB81F9Q9V%2BoDPsCTF-%2B0o_xR3%3D7_GAZfyg2sEaEfQJA%40mail.gmail.com#1f62ceb364243164a3d3a41530db055f
[2] https://www.postgresql.org/message-id/1250706.1658622457%40sss.pgh.pa.us

The following bug has been logged on the website:

Bug reference:      18817
Logged by:          Indrajeet Deshmukh
Email address:      bkindrajeeth@gmail.com
PostgreSQL version: 15.0
Operating system:   Linux
Description:       

Namaste Team,

During the integration of PostgreSQL Database v15 logs into a SIEM
solution,I observed that user passwords are logged in plaintext when a user
is created using the database command. This poses a serious security risk as
credentials could be exposed to unauthorized users who have access to the
logs.

Vendor: PostgreSQL
Product: PostgreSQL Database
Version: 15
Severity: High
Issue Type: Security Vulnerability

Steps to Reproduce:
Open the PostgreSQL Database CLI or execute the command via a script.
Run the following command to create a new user:

CREATE USER indrajeet WITH PASSWORD 'indrajeet'

Indrajeeth Deshmukh <bkindrajeeth@gmail.com> writes:
> Thanks for sharing the details. It looks like a valid issue and has not
> been resolved yet. Currently, the solution is keeping the file remains
> secure, but when it comes to SIEM monitoring, it will be a major concern.
> Any thoughts on this?

The real bottom-line answer to that is that passwords are just the
tip of the iceberg.  The server log is likely to contain other
critical information depending on your application; consider credit
card numbers, HIPAA-protected medical details, etc.  The server
has no way at all to know which fields might be sensitive in that
way.  Even if we had some notion of which fields to hide, in cases
like statements with syntax errors, we couldn't reliably identify
which parts of a query string are sensitive.

The only solution is to treat the server log files with the same
amount of care as you give to the database files themselves.
Or send them to /dev/null, but that's unlikely to be very workable
in practice.

Independently of that, best practice is to never send cleartext
passwords to the server in the first place.  psql has support
for setting a password without that, and I think libpq does too.

            regards, tom lane

El día martes, febrero 18, 2025 a las 10:37:52 -0500, Tom Lane escribió:

> Indrajeeth Deshmukh <bkindrajeeth@gmail.com> writes:
> > Thanks for sharing the details. It looks like a valid issue and has not
> > been resolved yet. Currently, the solution is keeping the file remains
> > secure, but when it comes to SIEM monitoring, it will be a major concern.
> > Any thoughts on this?
> 
> The real bottom-line answer to that is that passwords are just the
> tip of the iceberg.  The server log is likely to contain other
> critical information depending on your application; consider credit
> card numbers, HIPAA-protected medical details, etc.  The server
> has no way at all to know which fields might be sensitive in that
> way.  Even if we had some notion of which fields to hide, in cases
> like statements with syntax errors, we couldn't reliably identify
> which parts of a query string are sensitive.
> 
> The only solution is to treat the server log files with the same
> amount of care as you give to the database files themselves.
> Or send them to /dev/null, but that's unlikely to be very workable
> in practice.
> 
> Independently of that, best practice is to never send cleartext
> passwords to the server in the first place.  psql has support
> for setting a password without that, and I think libpq does too.

What do I have to configure in the PostgreSQL server to get this
reproduced? I tried:

$ psql -Usisis testdb
psql (15.1, server 16.5)
WARNING: psql major version 15, server major version 16.
         Some psql features might not work.
Type "help" for help.

testdb=# CREATE USER bla WITH PASSWORD 'bla';
CREATE ROLE
testdb=#

and have nothing in the log:

$ tail /data/postgresql165/log/postgresql-2025-02-19_000000.log
...

2025-02-19 06:15:23.582 CET [1947] LOG:  checkpoint complete: wrote 1421 buffers (8.7%); 0 WAL file(s) added, 1
removed,0 recycled; write=142.168 s, sync=0.003 s, total=142.186 s; sync files=57, longest=0.002 s, average=0.001 s;
distance=18403kB, estimate=18403 kB; lsn=5/72470898, redo lsn=5/7246F048
 

I even set 

log_statement = 'all'

and restarted the server - nothing.

The purpose of my question is to inform our 50++ PostgreSQL customers
what they must avoid...

Thanks

    matthias

-- 
Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Matthias Apitz <guru@unixarea.de> writes:
> What do I have to configure in the PostgreSQL server to get this
> reproduced? I tried:

[ scratches head... ]  Seems like you must be looking in the wrong
log file.  It works for me:

$ psql postgres
psql (18devel)
Type "help" for help.

postgres=# set log_statement = 'all';
SET
postgres=# CREATE USER bla WITH PASSWORD 'bla';
CREATE ROLE
postgres=# \q
$ tail .../postmaster.log
...
2025-02-19 01:19:18.638 EST [1949443] LOG:  statement: CREATE USER bla WITH PASSWORD 'bla';

If you're not running with log_statement = all, the most likely
scenario is a syntax error:

$ psql postgres
psql (18devel)
Type "help" for help.

postgres=# CREATE USER bla WITH PASWORD 'bla';
ERROR:  unrecognized role option "pasword"
LINE 1: CREATE USER bla WITH PASWORD 'bla';
                             ^
postgres=# \q
$ tail .../postmaster.log
...
2025-02-19 01:25:39.227 EST [1950440] ERROR:  unrecognized role option "pasword" at character 22
2025-02-19 01:25:39.227 EST [1950440] STATEMENT:  CREATE USER bla WITH PASWORD 'bla';

Of course, this command didn't do anything; but a person reading the
log would have a pretty strong clue what password you were about to
assign.  (And contrarily, Postgres itself would have no clue that
'bla' might be something that needs hiding.)

            regards, tom lane

_______________________________________
From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Wednesday, February 19, 2025 07:30
To: Matthias Apitz <guru@unixarea.de>
Cc: Indrajeeth Deshmukh <bkindrajeeth@gmail.com>; David Rowley <dgrowleyml@gmail.com>; pgsql-bugs@lists.postgresql.org
<pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in Logs
 
Matthias Apitz <guru@unixarea.de> writes:
> What do I have to configure in the PostgreSQL server to get this
> reproduced? I tried:

export PGDATA=/var/tmp/xx; rm -rf $PGDATA; export PGPORT=8888; initdb; echo "logging_collector=on" >>
$PGDATA/postgresql.auto.conf;echo "log_statement=ddl" >> $PGDATA/postgresql.auto.conf; pg_ctl start; psql <<< "create
useru with password 'u'"; cat $PGDATA/log/*; pg_ctl stop 

Regards
Daniel

On Wed, 2025-02-19 at 06:57 +0100, Matthias Apitz wrote:
> What do I have to configure in the PostgreSQL server to get this
> reproduced? I tried:
>
> $ psql -Usisis testdb
> psql (15.1, server 16.5)
> WARNING: psql major version 15, server major version 16.
>          Some psql features might not work.
> Type "help" for help.
>
> testdb=# CREATE USER bla WITH PASSWORD 'bla';
> CREATE ROLE
> testdb=#
>
> and have nothing in the log:
>
> $ tail /data/postgresql165/log/postgresql-2025-02-19_000000.log
> ...
>
> 2025-02-19 06:15:23.582 CET [1947] LOG:  checkpoint complete: wrote 1421 buffers (8.7%); 0 WAL file(s) added, 1
removed,0 recycled; write=142.168 s, sync=0.003 s, total=142.186 s; sync files=57, longest=0.002 s, average=0.001 s;
distance=18403kB, estimate=18403 kB; lsn=5/72470898, redo lsn=5/7246F048 
>
> I even set
>
> log_statement = 'all'
>
> and restarted the server - nothing.

Setting "log_statement" to "all", "mod" or "ddl" would do the trick.
You must have made some basic mistake.

Look at "pg_settings" what your current setting for "log_statement" is
and where it is coming from.

> The purpose of my question is to inform our 50++ PostgreSQL customers
> what they must avoid...

I'd call that an unfair bias against your younger customers.

Yours,
Laurenz Albe

--

*E-Mail Disclaimer*
Der Inhalt dieser E-Mail ist ausschliesslich fuer den
bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat
dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte,
dass jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder
Weitergabe des Inhalts dieser E-Mail unzulaessig ist. Wir bitten Sie, sich
in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen.

*CONFIDENTIALITY NOTICE & DISCLAIMER
*This message and any attachment are
confidential and may be privileged or otherwise protected from disclosure
and solely for the use of the person(s) or entity to whom it is intended.
If you have received this message in error and are not the intended
recipient, please notify the sender immediately and delete this message and
any attachment from your system. If you are not the intended recipient, be
advised that any use of this message is prohibited and may be unlawful, and
you must not copy this message or attachment or disclose the contents to
any other person.

Am 19.02.2025 09:58, schrieb Laurenz Albe:
>> The purpose of my question is to inform our 50++ PostgreSQL customers
>> what they must avoid...
> 
> I'd call that an unfair bias against your younger customers.

With 50++ the number of the customer installations was meant, not the 
age.

      matthias