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

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