Is there any security risk if we enable tcpip_socket by default? We
restrict connection from localhost only by default so I think enabling
tcpip_socket adds no security risk. Please correct me if I am wrong.
--
Tatsuo Ishii

Mon, 17 May 2004 13:24:34 +0900 (JST)
Tatsuo Ishii <t-ishii@sra.co.jp>
enabling tcpip_socket by default
Tatsuo Ishii wrote:
> Is there any security risk if we enable tcpip_socket by default? We
> restrict connection from localhost only by default so I think enabling
> tcpip_socket adds no security risk. Please correct me if I am wrong.

Right, and 7.5 will ship with tcp and localhost enabled.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 17 May 2004 00:34:06 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: enabling tcpip_socket by default
> Tatsuo Ishii wrote:
> > Is there any security risk if we enable tcpip_socket by default? We
> > restrict connection from localhost only by default so I think enabling
> > tcpip_socket adds no security risk. Please correct me if I am wrong.
> 
> Right, and 7.5 will ship with tcp and localhost enabled.

That's good news. Thanks.
--
Tatsuo Ishii

Mon, 17 May 2004 13:43:15 +0900 (JST)
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: enabling tcpip_socket by default
> Tatsuo Ishii wrote:
>> Is there any security risk if we enable tcpip_socket by default? We
>> restrict connection from localhost only by default so I think enabling
>> tcpip_socket adds no security risk. Please correct me if I am wrong.

Bruce Momjian wrote:
> Right, and 7.5 will ship with tcp and localhost enabled.

If the default will be to listen on all interfaces, not just 127.0.0.1,
then this IS a security risk. And if that's not the plan, what good does
this change do? Any "real" use of tcp would still require a 
configuration
change anyway.

Listening on public network interfaces by default would multiply by
orders of magnitude the number of machines vulnerable to potential
future remote exploits.

I gather that the pre-authentication code paths are pretty well known,
and that the chances of such an attack are slim. Nevertheless I cannot
help but note that it is exactly this default setting that caused
Microsoft SQL Server to lose a big, big chunk of its reputation, and
gain notoriety as a launchpad for Windows worms.

mk


Mon, 17 May 2004 10:29:26 +0300
Marko Karppinen <marko@karppinen.fi>
Re: enabling tcpip_socket by default
On Mon, 17 May 2004 05:29 pm, Marko Karppinen wrote:
> If the default will be to listen on all interfaces, not just 127.0.0.1,
> then this IS a security risk. And if that's not the plan, what good does
> this change do? Any "real" use of tcp would still require a 
> configuration
> change anyway.

 From what I have read today, localhost is the only one planned to be "on" by 
default.

Listening on a TCP/IP socket on localhost will allow JDBC connections to work 
out of the box (this exact problem tripped me up, and I'm sure this is the 
case for other users). 

I suspect other cross-platform APIs (PHP for example) need TCP/IP sockets to 
connect too. 

Regards, Philip.

Mon, 17 May 2004 17:40:06 +1000
Philip Yarra <philip@utiba.com>
Re: enabling tcpip_socket by default
> > Tatsuo Ishii wrote:
> >> Is there any security risk if we enable tcpip_socket by default? We
> >> restrict connection from localhost only by default so I think enabling
> >> tcpip_socket adds no security risk. Please correct me if I am wrong.
> 
> Bruce Momjian wrote:
> > Right, and 7.5 will ship with tcp and localhost enabled.
> 
> If the default will be to listen on all interfaces, not just 127.0.0.1,
> then this IS a security risk. And if that's not the plan, what good does
> this change do? Any "real" use of tcp would still require a 
> configuration
> change anyway.

Consider a program using JDBC on localhost. It can only reach to
PostgreSQL via TCP/IP.
--
Tatsuo Ishii

Mon, 17 May 2004 16:40:25 +0900 (JST)
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: enabling tcpip_socket by default
On 17. touko 2004, at 10:40, Tatsuo Ishii wrote:
> Consider a program using JDBC on localhost. It can only reach to
> PostgreSQL via TCP/IP.

Ah! Of course. That makes sense, and listening on 127.0.0.1 never
hurt anyone (except, of course, the tinfoil hat crowd nmapping
localhost in a frenzy...)

mk


Mon, 17 May 2004 10:48:14 +0300
Marko Karppinen <marko@karppinen.fi>
Re: enabling tcpip_socket by default
Marko Karppinen wrote:
> If the default will be to listen on all interfaces, not just
> 127.0.0.1, then this IS a security risk. And if that's not the plan,
> what good does this change do? Any "real" use of tcp would still
> require a
> configuration
> change anyway.

Some interfaces, most notably JDBC, require the use of TCP/IP but will 
often be perfectly happy with a locally bound socket only.


Mon, 17 May 2004 09:50:56 +0200
Peter Eisentraut <peter_e@gmx.net>
Re: enabling tcpip_socket by default
Marko Karppinen said:
>> Tatsuo Ishii wrote:
>>> Is there any security risk if we enable tcpip_socket by default? We
>>> restrict connection from localhost only by default so I think
>>> enabling tcpip_socket adds no security risk. Please correct me if I
>>> am wrong.
>
> Bruce Momjian wrote:
>> Right, and 7.5 will ship with tcp and localhost enabled.
>
> If the default will be to listen on all interfaces, not just 127.0.0.1,
> then this IS a security risk. And if that's not the plan, what good
> does this change do? Any "real" use of tcp would still require a
> configuration
> change anyway.

This is demonstrably not true.

>
> Listening on public network interfaces by default would multiply by
> orders of magnitude the number of machines vulnerable to potential
> future remote exploits.
>
> I gather that the pre-authentication code paths are pretty well known,
> and that the chances of such an attack are slim. Nevertheless I cannot
> help but note that it is exactly this default setting that caused
> Microsoft SQL Server to lose a big, big chunk of its reputation, and
> gain notoriety as a launchpad for Windows worms.
>

Why are we having a discussion about a change that went in 2 months ago
and was fully debated back then?

Of course we did not enable listening on any all addresses by default.
Maybe you think we are not security conscious?

The change was done because
 - Windows does not have Unix sockets, and can only talk via TCP
 - Some interfaces (notably JDBC) also require it
 - It is probably the number one thing that trips up new pg users.

We listen by default on "localhost" (note, not "127.0.0.1").

Read the dev version of the docs for details.

cheers

andrew



Mon, 17 May 2004 07:29:29 -0400 (EDT)
"Andrew Dunstan" <andrew@dunslane.net>
Re: enabling tcpip_socket by default
Marko Karppinen <marko@karppinen.fi> writes:

> On 17. touko 2004, at 10:40, Tatsuo Ishii wrote:
> > Consider a program using JDBC on localhost. It can only reach to
> > PostgreSQL via TCP/IP.

Huh? Why on earth would that be true? Is this a limitation of our JDBC
drivers?

> Ah! Of course. That makes sense, and listening on 127.0.0.1 never
> hurt anyone (except, of course, the tinfoil hat crowd nmapping
> localhost in a frenzy...)

Actually on many systems it was very possible to send packets to a machine
with a source address of 127.0.0.1 even over external networks or through
routers. Making an attack out of this on a TCP service would be difficult, but
it has been done.

Good OS distributions install network filters by default to refuse such
packets, but lots of OSes still don't do this.

-- 
greg


17 May 2004 17:09:35 -0400
Greg Stark <gsstark@mit.edu>
Re: enabling tcpip_socket by default
Greg Stark <gsstark@mit.edu> writes:

> Marko Karppinen <marko@karppinen.fi> writes:
>
>> On 17. touko 2004, at 10:40, Tatsuo Ishii wrote:
>> > Consider a program using JDBC on localhost. It can only reach to
>> > PostgreSQL via TCP/IP.
>
> Huh? Why on earth would that be true? Is this a limitation of our JDBC
> drivers?

Java doesn't support Unix domain sockets.  If you want to use JDBC,
you have to use TCP sockets.

-Doug

Mon, 17 May 2004 17:39:11 -0400
Doug McNaught <doug@mcnaught.org>
Re: enabling tcpip_socket by default

Doug McNaught <doug@mcnaught.org> writes:

> Greg Stark <gsstark@mit.edu> writes:
> 
> > Marko Karppinen <marko@karppinen.fi> writes:
> >
> >> On 17. touko 2004, at 10:40, Tatsuo Ishii wrote:
> >> > Consider a program using JDBC on localhost. It can only reach to
> >> > PostgreSQL via TCP/IP.
> >
> > Huh? Why on earth would that be true? Is this a limitation of our JDBC
> > drivers?
> 
> Java doesn't support Unix domain sockets.  If you want to use JDBC,
> you have to use TCP sockets.

That doesn't follow. That just means you can't implement a unix domain socket
driver using only Java. Is there some reason the driver has to be pure a Java
driver?

I had always assumed the JDBC driver isn't currently pure java and is just an
API wrapper around libpq. Writing and maintaining a pure java driver would be
much more work and be much slower for no practical gain.

-- 
greg


17 May 2004 17:53:39 -0400
Greg Stark <gsstark@mit.edu>
Re: enabling tcpip_socket by default
Greg Stark wrote:

>  
>
>>Ah! Of course. That makes sense, and listening on 127.0.0.1 never
>>hurt anyone (except, of course, the tinfoil hat crowd nmapping
>>localhost in a frenzy...)
>>    
>>
>
>Actually on many systems it was very possible to send packets to a machine
>with a source address of 127.0.0.1 even over external networks or through
>routers. Making an attack out of this on a TCP service would be difficult, but
>it has been done.
>
>Good OS distributions install network filters by default to refuse such
>packets, but lots of OSes still don't do this.
>
>  
>


But what we listen to relates to the destination address of the packets, 
not the source address ...

cheers

andrew

Mon, 17 May 2004 18:00:48 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: enabling tcpip_socket by default
Greg Stark <gsstark@mit.edu> writes:

> Doug McNaught <doug@mcnaught.org> writes:
>
>> Java doesn't support Unix domain sockets.  If you want to use JDBC,
>> you have to use TCP sockets.
>
> That doesn't follow. That just means you can't implement a unix domain socket
> driver using only Java. Is there some reason the driver has to be pure a Java
> driver?

Well, no.  But then you get into the horror that is JNI, and the need
to maintain that glue layer (there's a substantial impedance mismatch
between libpq and the JDBC API) on all platforms.

> I had always assumed the JDBC driver isn't currently pure java and is just an
> API wrapper around libpq. Writing and maintaining a pure java driver would be
> much more work and be much slower for no practical gain.

The JDBC driver is and always has been pure Java, and I'm damn glad.
If your app is all Java, all you have to do is add the driver jar to
the classpath and you're done--no libpq, no .so version mismatches,
etc.  AFAIK (I'm not one of the developers) there are no plans to
write a JNI layer just for Unix sockets.

And I doubt very much that it's that much slower in most cases,
especially with modern JIT compilers.  You'll take a bit of a hit from
the TCP overhead, but in practice for most apps it won't be an issue.

-Doug

Mon, 17 May 2004 18:01:34 -0400
Doug McNaught <doug@mcnaught.org>
Re: enabling tcpip_socket by default
On Mon, May 17, 2004 at 18:00:48 -0400,
  Andrew Dunstan <andrew@dunslane.net> wrote:
> 
> But what we listen to relates to the destination address of the packets, 
> not the source address ...

There still is some small risk. If you OS doesn't reject packets destined
for 127.*.*.* that don't come from the loopback interface, it is possible
for someone on your local network to at least do a blind spoofing attack,
possibly they might also be able to get replies back as well.

Mon, 17 May 2004 21:33:00 -0500
Bruno Wolff III <bruno@wolff.to>
Re: enabling tcpip_socket by default
Bruno Wolff III said:
> On Mon, May 17, 2004 at 18:00:48 -0400,
>  Andrew Dunstan <andrew@dunslane.net> wrote:
>>
>> But what we listen to relates to the destination address of the
>> packets,  not the source address ...
>
> There still is some small risk. If you OS doesn't reject packets
> destined for 127.*.*.* that don't come from the loopback interface, it
> is possible for someone on your local network to at least do a blind
> spoofing attack, possibly they might also be able to get replies back
> as well.


For some value of "small" approaching 0 :-) .

The default configuration will only allow localhost-localhost connections
(via the combination of the default listening_addresses value and the
default pg_hba.conf settings). So to spoof it successfully you would have
to be able to get the host to accept a nonlocal packet addressed to
localhost AND get it to route the reply addressed to localhost to your
nonlocal machine.

If you have such an insecure OS you should
- throw it in the bin and get another with a sane network stack, and
- in the meantime set listening_addresses to "" to turn of TCP altogether.

But then PostgreSQL is likely to be the least of your problems, I suspect.

Bear in mind that behaviour has not changed at all really, only *which*
behaviour is the default.

cheers

andrew






Mon, 17 May 2004 23:02:12 -0400 (EDT)
"Andrew Dunstan" <andrew@dunslane.net>
Re: enabling tcpip_socket by default