gpsql - information leak in pgsql backend logging #459
Assignees
Labels
Comments
ghost
assigned 
Habbie
pushed a commit
that referenced
this issue
Apr 26, 2013
…ixes #459, reported by Stefan Kaltenbrunner. git-svn-id: svn://svn.powerdns.com/pdns/trunk/pdns@2609 d19b8d6e-7fed-0310-83ef-9ca221ded41b
Habbie
pushed a commit
that referenced
this issue
Apr 26, 2013
…ixes #459, reported by Stefan Kaltenbrunner. (r2609) git-svn-id: svn://svn.powerdns.com/pdns/branches/pdns-3.1-maint@2654 d19b8d6e-7fed-0310-83ef-9ca221ded41b
|
Author: peter |
mind04
pushed a commit
to mind04/pdns
that referenced
this issue
Apr 26, 2013
…ixes PowerDNS#459, reported by Stefan Kaltenbrunner. git-svn-id: svn://svn.powerdns.com/pdns/trunk/pdns@2609 d19b8d6e-7fed-0310-83ef-9ca221ded41b
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The current gpgsql implementation (others might be affected as well though I have not checked them) leaks the password of a database connection in plaintext into the system logs if an error occurs during the connection establishment:
gpgsql Connection failed: Unable to connect to database, connect string: dbname=pdns_database user=pdns_user host=127.0.0.1 port=5432 password=L3AkTh3Da1a: could not connect to server: Connection refused ^IIs the server running on host "127.0.0.1" and accepting ^ITCP/IP connections on port 5432?
this seems to be cause by caused by modules/gpgsqlbackend/spgsql.cc simply dumping the fully connection string (d_connectstr) into the logfile on errors. It would seems it would be a good idea to provide a censored (ie maybe do a password=) string in those error messages and/or only do full password logging with debug-level logging enabled...
The text was updated successfully, but these errors were encountered: