Re: Spoofing as the postmaster - Mailing list pgsql-hackers

The problem with forcing authentication is that an auth-unaware client 
connecting to a legitimate postmaster would have its connections 
refused. That same client would have its connections accepted by an 
impostor postmaster. Thus, there is no way to stop impostor postmasters 
from carrying out these attacks on auth-unaware clients.

The proper solution, as I see it, would be to have an authentication 
system in the postmaster that was not enforced. If the client requests 
authentication, postmaster will provide it, if not, then postmaster will 
connect normally without it. This would not result in *any* change in 
the default behavior of postmaster, and as far as users who don't want 
to use it are concerned, they don't even need to bother to turn it off 
(assuming that having it turned on does not consume extra resources and 
I don't think having an unused authentication mechanism sitting in the 
postmaster connection establishment routine would).

This does not appear to result in greater security, however it does. It 
allows DBAs who suspect that they are likely going to be the target of 
these attacks to deploy authentication procedures in their client 
packages. This could be a modification to their applications, or 
whatever steps are necessary to mandate authenticated connections within 
their organization.

There is no point forcing some auth mechanism within postmaster, as 
attackers would simply catch users using software that did not require 
the server to auth before sending passwords. For this reason it is not 
postmaster's responsibility to check that unknown clients do not connect 
to impostors, it is postmaster's responsibility however to authenticate 
itself, if the client asks for it. So the onus (rightfully in my 
opinion) falls upon network administrators / DBAs to ensure that all of 
their users are using auth-enabled client packages which will not allow 
connections to be established with a postmaster until authentication has 
passed, and disallow the use of other client software to connect to 
postmaster.

In my view, this puts the security responsibility where it rightfully 
belongs *and* maintains a non-breaking of client packages in the wild. 
Making a server or anything that *requires* auth and disallows 
non-authed clients is pointless, as there is nothing stopping attackers 
from setting up an auth-disabled impostor and waiting for someone to 
just connect using psql or some other vanilla connection method. The 
onus really ought to be with the administrators who give their users the 
software they use to connect to ensure that the software they use 
adheres to the relevant security policy, in the same way that its their 
responsibility to ensure that the client software does not contain 
keyloggers and other such trashware.

In the web world, it is the client's responsibility to ensure that they 
check the SSL cert and don't do their banking at 
www.bankofamerica.hax0r.ru and there is nothing that the real banking 
site can do to stop them using their malware infested PC to connect to 
the phishing site. They can only provide a site that provides 
authentication. This is analogous to postmaster: It is only the 
responsibility of postmaster to provide the option of authentication, it 
is the client's responsibility to know if they should use it, and if so, 
to ensure they do so properly.

Regards,
- MrNaz.com