A few months ago a security concern was sent to core. We have discussed
it but see little we can do to address it in the code so I am posting to
hackers in case there is something we didn't think of or if
documentation additions are necessary.
Most users understand that if they are connecting to the postmaster over
an insecure network that it is possible for a middle-man to intercept
passwords, queries, and results. SSL certificates are designed to avoid
this problem.
The new attack vector reported involves a local user on the same machine
as the postmaster. When the postmaster is running it has bound port
5432 and created the unix-domain socket file in /tmp. The new attack
involves cases where the postmaster is stopped.
The attacker can bind to TCP port 5432 or create a socket file in /tmp
and get passwords and queries. PGDATA is secure so results cannot be
returned while the postmaster is down. They can also prevent the real
server from starting.
It is possible for the attacker to use one of the interfaces (tcp or
unix domain) and wait for the postmaster to start. The postmaster will
fail to start on the interface in use but will start on the other
interface and the attacker could route queries to the active postmaster
interface.
So, what solutions exist? We could require the use of port numbers less
than 1024 which typically require root and then become a non-root user,
but that requires root to start the server. We could put the unix
domain socket file in a secure directory (but where?) but the client has
to know that location.
An interesting idea would be for the unix domain client to check that
the ownership of the socket file is the same as PGDATA, but clients
typically don't know PGDATA, nor do they know who should be running the
postmaster.
I suppose we could create a poor-man's SSL for unix domain sockets that
just checks the ownership of the socket file, but users can already do
that by specifying the socket file in a directory that only has write
permission for the postmaster user.
Could we create some kind of lock mode that keeps these interfaces
locked when the postmaster is down?
Conclusion
----------
The fundamental problem is that because we don't require root, any user's
postmaster or pretend postmaster is as legitimate as anyone else's. SSL
certificates add legitimacy checks for TCP, but not for unix domain sockets.
This is not a Postgres-specific problem. It is probably shared by any
server that doesn't need root permissions, but our handling of passwords
makes it a larger problem.
I think at a minimum we need to add documentation that states if you
don't trust the local users on the postmaster server you should:
o create unix domain socket files in a non-world-writable
directory
o require SSL server certificates for TCP connections
Ideas?
Remember, as long as your postmaster is running you are safe. It is
only postmaster downtime that has this risk.
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
