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

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

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

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.

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

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

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.

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

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

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

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

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

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

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.

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