Date: Wed, 19 Feb 2025 06:57:52 +0100
From: Matthias Apitz <guru@unixarea.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Indrajeeth Deshmukh <bkindrajeeth@gmail.com>,
	David Rowley <dgrowleyml@gmail.com>,
	pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18817: Security Bug Report: Plaintext Password Exposure in
 Logs
Message-ID: <Z7Vy4FefAH/Vk+Lc@pureos>
Reply-To: Matthias Apitz <guru@unixarea.de>
References: <18817-771682052a364bfe@postgresql.org>
 <CAApHDvoCnaLeVO4zdCaYJFBfcuGXYz1W5L917p526nWEcs=gqg@mail.gmail.com>
 <CAAapt1i2Mf=S0FtPz8Z9RNkez=nP50AcYDVC7Dm8r=cskMn7tg@mail.gmail.com>
 <1241094.1739893072@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1241094.1739893072@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/Z7Vy4FefAH/Vk%2BLc%40pureos>
Precedence: bulk

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=18403 kB, 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