Skip site navigation (1) Skip section navigation (2)

Re: Spoofing as the postmaster

From: Tomasz Ostrowski <tometzky(at)batory(dot)org(dot)pl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Marko Kreen <markokr(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: Spoofing as the postmaster
Date: 2007-12-27 10:09:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sun, 23 Dec 2007, Tom Lane wrote:

> ISTM we have these action items:
> 1. Improve the code so that SSL authentication can be used across a
> Unix-socket connection (we can disable encryption though).

I've just realised that there's a problem with SSL with disabled
encryption on a unix socket / localhost connections for cpu-saving.
Any local user using this attack would be able to eavesdrop
everything comming through a socket.

If an attacker just acts as a tunnel, highjacking a unix-socket and
talking to a server using any other interface (or the other way
around), then he would not be able to modify information flow, but he
would be able to read and save everything going to and from a server.
It is again not obvious as normally local connections are not
susceptible to eavesdropping. And could go unnoticed for a long time
as everything would just work normally.

So I think no cpu-saving by turning off encryption should be done.

And this would all not help for a denial-of-service attack.

...although Eating Honey was a very good thing to do, there was a
moment just before you began to eat it which was better than when you
                                                      Winnie the Pooh

In response to


pgsql-hackers by date

Next:From: Andreas 'ads' ScherbaumDate: 2007-12-27 12:09:26
Subject: Re: Binary data type with other output method
Previous:From: Andrew DunstanDate: 2007-12-27 01:20:59
Subject: Re: Binary data type with other output method

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group