Peter Eisentraut wrote:
> Magnus Hagander wrote:
>>> Most kinds of server processes where you'd send sensitive information do
>>> support SSL. Most of these server processes don't run over Unix-domain
>>> sockets, though.
>> Well, the question is not about sensitive information, is it? It's about
>> password disclosure due to spoofing.
>
> I included passwords as sensitive information.
Well, it's a different kind of vulnerability than getting at sensitive
informations. Passwords can be open for a replay attack, for example,
even if the transport itself is protected.
>> Which would affect *all* services
>> that accept passwords over any kind of local connections - both unix
>> sockets and TCP localhost.
>
> These services either use a protected port or a protected directory, or they
> support SSL or something similar (SSH), or they are deprecated, as many
> traditional Unix services are. If you find a service that is not covered by
> this, then yes, you have a problem.
It's certainly the default on my SQL Servers. And Sybase. AFAIK it's the
default on MySQL, but it's been a while since I installed one. And I'm
told it's the default on Oracle, but don't have an install around so I
can verify it.
Now, most of these *support* SSL. But I've never come across a
recommendation to use it for localhost connections.
>> The best way to avoid it is of course not to give untrusted users access
>> to launch arbitrary processes on your server. Something about that
>> should perhaps be added to that new docs section?
>
> That is pretty impractical. PostgreSQL is designed to run on multiuser
> operating systems, so it should do it correctly. Such suggestions do not
> raise confidence.
Well, I'd still recommend people not to allow arbitrary users access to
my db servers. Quite regardless of what OS or database it's running. Not
necessarily for this reason, but following such a requirement mitigates
this problem as well, as a pure side-effect.
//Magnus