Thread: enabling tcpip_socket by default
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
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, Pennsylvania19073
> 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
> > 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 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.
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