Re: [HACKERS] Spoofing as the postmaster
D'Arcy J.M. Cain [EMAIL PROTECTED] writes: On Sat, 22 Dec 2007 09:25:05 -0500 (EST) Bruce Momjian [EMAIL PROTECTED] wrote: I think at a minimum we need to add documentation that states if you don't trust the local users on the postmaster server you should: o create unix domain socket files in a non-world-writable directory o require SSL server certificates for TCP connections Ideas? It's generally a bad idea to put your database on a public server anyway but if you do you should definitely disable unix domain sockets and connect over TCP to localhost. That has been our rule for years. It's certainly a corner case. I would think that warnings, perhaps in the config file itself, would be sufficient. That seems like a terrible idea. At least while you're dealing with unix domain sockets you know there's no way a remote user could possibly interfere with or sniff your data. As soon as you're dealing with TCP it's a whole new ballgame. X famously had a problem on many OSes where you could spoof the first packet (and if you could predict sequence numbers more than that) of a connection allegedly coming from 127.0.0.1. (it helped that a message to open up connections from anywhere fit in one packet...) Modern OSes include network filters to block such spoofs but it's one more thing you're counting on. Also brought into place are things like forged RST packets, routing table attacks, and on and on. And on the performance front you're dealing with smaller mss and much higher protocol overhead. You also lose bulletproof authentication from unix credentials and are instead relying on properly configuring your network authentication. And it's much easier to accidentally be relying on insecure identd. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Spoofing as the postmaster
Bruce Momjian wrote: Bruce Momjian wrote: I think at a minimum we need to add documentation that states if you don't trust the local users on the postmaster server you should: o create unix domain socket files in a non-world-writable directory o require SSL server certificates for TCP connections I have written documentation for this item: http://momjian.us/tmp/pgsql/server-shutdown.html#SERVER-SPOOFING Comments? What you actually need on the client side is ~/.postgresql/root.crt, not ~/.postgresql/postgresql.crt as you wrote. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Spoofing as the postmaster
Bruce Momjian wrote: Brendan Jurd wrote: On Dec 23, 2007 1:25 PM, Bruce Momjian [EMAIL PROTECTED] wrote: I have written documentation for this item: http://momjian.us/tmp/pgsql/server-shutdown.html#SERVER-SPOOFING Comments? I thought the content made sense, but the location didn't. I wouldn't expect to find instructions on configuring Postgres for secure operation under a section about how to shut the server down. I realise that in order for the exploit to occur, the server must be shut down (or not yet started), but unless a user already knows about the way the exploit works, how will they know to look for info about it here? IMO by putting this guidance under Shutting Down you're going to hurt the chances of anyone stumbling across it. I doubt you'd get many users reading Shutting Down at all because in most cases, it's an easy or obvious thing to do (initscripts provided by package and pg_ctl are self-explanatory). Agreed. I moved it up to its own section: http://momjian.us/tmp/pgsql/preventing-server-spoofing.html I improved the wording slightly too. The server doesn't need a root.crt certificate really - but it does need the *server* certificate (server.key/server.crt). root.crt is only used to verify *client* certificates, which is a different thing from what you're outlining here. Out of curiosity, does any of the other databases out there solve this somehow? Or any non-databases too, really. To me this seems like a general problem for *any* kind of server processes - at least any that runs with port 1024 on Unix (and any at all on win32, since they don't check the port number there). //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Spoofing as the postmaster
Magnus Hagander wrote: Out of curiosity, does any of the other databases out there solve this somehow? Or any non-databases too, really. To me this seems like a general problem for *any* kind of server processes 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. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Spoofing as the postmaster
Peter Eisentraut wrote: Magnus Hagander wrote: Out of curiosity, does any of the other databases out there solve this somehow? Or any non-databases too, really. To me this seems like a general problem for *any* kind of server processes 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. Which would affect *all* services that accept passwords over any kind of local connections - both unix sockets and TCP localhost. I'm just saying that pretty much everybody has to be affected by this. And you can't claim it's very common to use SSL to secure localhost connections. Maybe it should be, but I hardly ever see it... 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? //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Spoofing as the postmaster
Peter Eisentraut wrote: Bruce Momjian wrote: Bruce Momjian wrote: I think at a minimum we need to add documentation that states if you don't trust the local users on the postmaster server you should: o create unix domain socket files in a non-world-writable directory o require SSL server certificates for TCP connections I have written documentation for this item: http://momjian.us/tmp/pgsql/server-shutdown.html#SERVER-SPOOFING Comments? What you actually need on the client side is ~/.postgresql/root.crt, not ~/.postgresql/postgresql.crt as you wrote. Thanks, updated: http://momjian.us/tmp/pgsql/preventing-server-spoofing.html (I mentioned the file name specificly so people like me wouldn't get confused.) :-) -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Spoofing as the postmaster
Magnus Hagander wrote: The server doesn't need a root.crt certificate really - but it does need the *server* certificate (server.key/server.crt). root.crt is only used to verify *client* certificates, which is a different thing from what you're outlining here. Updated: http://momjian.us/tmp/pgsql/preventing-server-spoofing.html Thanks. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Spoofing as the postmaster
Magnus Hagander wrote: Well, the question is not about sensitive information, is it? It's about password disclosure due to spoofing. Which would affect *all* services that accept passwords over any kind of local connections - both unix sockets and TCP localhost. I'm just saying that pretty much everybody has to be affected by this. And you can't claim it's very common to use SSL to secure localhost connections. Maybe it should be, but I hardly ever see it... Yep. I think the big issue is most people think unix domain sockets and localhost are secure, but they are not if the server is down, unless SSL is used or the socket file is in a privileged directory. 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? Yep, doing that now. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Spoofing as the postmaster
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. 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. 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. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Spoofing as the postmaster
On Sat, Dec 22, 2007 at 02:21:42PM -0500, Tom Lane wrote: No, we shouldn't, and if I had any authority over them I would make Debian stop doing that. It amounts to a unilateral distro-specific change in the protocol, and I think it makes things *less* secure, because any clients who are expecting the socket to be in /tmp will be easy pickings for a spoofer. Debian cannot hope to prevent that scenario, because there are non-libpq-based client implementations. Well, it's worked for many years and a little late to change now. It's arguably safer, since only postmasters owned by postgres can create a socket in that directory, any client attempting to connect to a server using that directory knows it's connecting to a server owned by 'postgres'. I can't think of any non-libpq clients which support Unix domain sockets? Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F Kennedy signature.asc Description: Digital signature
Re: [HACKERS] Spoofing as the postmaster
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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Spoofing as the postmaster
Martijn van Oosterhout wrote: On Sat, Dec 22, 2007 at 02:21:42PM -0500, Tom Lane wrote: No, we shouldn't, and if I had any authority over them I would make Debian stop doing that. It amounts to a unilateral distro-specific change in the protocol, and I think it makes things *less* secure, because any clients who are expecting the socket to be in /tmp will be easy pickings for a spoofer. Debian cannot hope to prevent that scenario, because there are non-libpq-based client implementations. Well, it's worked for many years and a little late to change now. It's arguably safer, since only postmasters owned by postgres can create a socket in that directory, any client attempting to connect to a server using that directory knows it's connecting to a server owned by 'postgres'. I can't think of any non-libpq clients which support Unix domain sockets? A different though on this - IIRC, you can at least on linux configure firewall rules based on the uid a talking process is running as. And if I'm not mistaken, you can fiddle something similar on Windows using the ipsec stack (not easily, though). This would make it impossible for a user to create something binding to the pg port, or at least taking on said port, unless they also manage to hack the postgres service account. And if they do that, they have full access to datafiles and certificates and everything, so you've really lost already in that case. This obviously only applies to TCP sockets and not Unix sockets. (And yes, I still consider this more of a host problem than a db problem) //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Spoofing as the postmaster
Bruce Momjian wrote: I can't start with the configuration you've given me, so I won't start at all is fairly normal behaviour for a server process, no? Yes, we have talked about this in the past and there were concerns that that the server might have some network problem that would prevent binding on all interfaces, particularly IPv6. This used to be our behaviour - IIRC we changed it along with the listen_interfaces changes in 8.0 because we so frequently see misconfigured networking. I'm wondering if it might not be reasonable to restore it as switchable, non-default behaviour. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Spoofing as the postmaster
On Sun, 23 Dec 2007 07:57:07 + Gregory Stark [EMAIL PROTECTED] wrote: D'Arcy J.M. Cain [EMAIL PROTECTED] writes: It's generally a bad idea to put your database on a public server anyway but if you do you should definitely disable unix domain sockets and connect over TCP to localhost. That has been our rule for years. That seems like a terrible idea. At least while you're dealing with unix domain sockets you know there's no way a remote user could possibly interfere with or sniff your data. As soon as you're dealing with TCP it's a whole new ballgame. Are you suggesting that you would have Unix domain sockets only? I have never seen this scenario other than dedicated db/web/etc servers that don't have public users so that's not an issue anyway. Once you are allowing untrusted users access you are probably allowing remote access as well. Two different models and two different security requirements n'est pas? Certainly the scenario where you have untrusted users on a server and require that only logged in users can access the database is possible. I have just never seen it and suspect that it is rare. Since I am suggesting that this is really a documentation and warning issue then this possibility can be examined and discussed in the documentation. X famously had a problem on many OSes where you could spoof the first packet (and if you could predict sequence numbers more than that) of a connection allegedly coming from 127.0.0.1. (it helped that a message to open up connections from anywhere fit in one packet...) Modern OSes include network filters to block such spoofs but it's one more thing you're counting on. Well, yes, I do count on the OS being reasonably modern and secure. I don't think that that is an unreasonable expectation. Also brought into place are things like forged RST packets, routing table attacks, and on and on. If this is an issue then don't allow remote access. In this case Unix domain sockets only make sense. -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Spoofing as the postmaster
Magnus Hagander [EMAIL PROTECTED] writes: Peter Eisentraut wrote: 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, Nyet. I find this in configure.in in mysql 5.0.45 (reasonably current): # The port should be constant for a LONG time MYSQL_TCP_PORT_DEFAULT=3306 MYSQL_UNIX_ADDR_DEFAULT=/tmp/mysql.sock I see that Red Hat's RPM specfile overrides that: --with-unix-socket-path=/var/lib/mysql/mysql.sock which was a decision that was taken long before I had anything to do with it. Note that neither the out-of-the-box default nor the RH-modified convention appear to support multiple servers on the same box with any degree of convenience; the server doesn't adjust the path name depending on port number. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Spoofing as the postmaster
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Peter Eisentraut wrote: 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, Nyet. I find this in configure.in in mysql 5.0.45 (reasonably current): # The port should be constant for a LONG time MYSQL_TCP_PORT_DEFAULT=3306 MYSQL_UNIX_ADDR_DEFAULT=/tmp/mysql.sock I see that Red Hat's RPM specfile overrides that: --with-unix-socket-path=/var/lib/mysql/mysql.sock which was a decision that was taken long before I had anything to do with it. Note that neither the out-of-the-box default nor the RH-modified convention appear to support multiple servers on the same box with any degree of convenience; the server doesn't adjust the path name depending on port number. I was referring to the listening on TCP connections over localhost without SSL. Port 3306 isn't protected AFAIK, and there's nothing in those lines that says it's SSL only. But then again, neither is the /tmp/mysql.sock file. Am I missing something here, or did you just post a piece of configure that *agreed* with what I said? ;-) //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Spoofing as the postmaster
Gregory Stark [EMAIL PROTECTED] writes: Bruce summarized the problem pretty well when he said that if Postgres is being run as a non-root user then one non-root user's postgres is as good as any other non-root user's postgres. Problem? What we mustn't lose sight of is that that's not a bug but a feature. It would be completely inappropriate for us as upstream to destroy that property, and my fundamental objection to what Debian has done is that they've destroyed that property at the distro level. I have no problem with the admin for a single installation putting in things that prevent there being more than one postmaster on that machine. I just say that software distribution time is not the place for such restrictions. If you're content to take the postgres user as special then you could call getsockopt(SO_PEERCRED) to verify you're really connected to a process run by postgres. But that isn't going to work if the postgres user could be named something else. In that case what is it you want to verify though? This is basically the same old mutual authentication problem that SSL was designed to solve by using certificates. I don't think we have either the need or the expertise to re-invent that wheel. 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). 2. Improve our documentation about how to set up mutual authentication under SSL (it's a bit scattered now). 3. Recommend using mutual auth even for local connections, if a server containing sensitive data is to be run on a machine that also hosts untrusted users. As somebody noted, it's probably even better policy to not have any sensitive data on a machine that hosts untrusted users, and it wouldn't hurt for the docs to point that out; but we should have a documented solution available if you have to do it. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Spoofing as the postmaster
Magnus Hagander [EMAIL PROTECTED] writes: Am I missing something here, or did you just post a piece of configure that *agreed* with what I said? ;-) Maybe I misread what you said. I thought you were claiming that mysql do this more securely than we do; which they don't. But looking back, It's certainly the default on my SQL Servers. And Sybase. AFAIK it's the default on MySQL, it seems it's not too clear which case you meant by it. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Spoofing as the postmaster
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Am I missing something here, or did you just post a piece of configure that *agreed* with what I said? ;-) Maybe I misread what you said. I thought you were claiming that mysql do this more securely than we do; which they don't. But looking back, It's certainly the default on my SQL Servers. And Sybase. AFAIK it's the default on MySQL, it seems it's not too clear which case you meant by it. My bad, then. Probably didn't quote enough :-) My point is that all these other server products have the exact same issue. And that they deal with it the exact same we do - pretty much leave it up to the guy who configure the server to realize that's just how things work. I'm just surprised that people are actually surprised by this. To me, it's just a natural fact that happens to pretty much all systems. And a good reason not to let arbitrary users run processes that can bind to something on your server. //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Spoofing as the postmaster
On Sun, Dec 23, 2007 at 02:52:28PM -0500, Tom Lane wrote: Gregory Stark [EMAIL PROTECTED] writes: Bruce summarized the problem pretty well when he said that if Postgres is being run as a non-root user then one non-root user's postgres is as good as any other non-root user's postgres. Problem? What we mustn't lose sight of is that that's not a bug but a feature. It would be completely inappropriate for us as upstream to destroy that property, and my fundamental objection to what Debian has done is that they've destroyed that property at the distro level. I have no problem with the admin for a single installation putting in things that prevent there being more than one postmaster on that machine. I just say that software distribution time is not the place for such restrictions. The default postgresql.conf in Debian contains a line like this: unix_socket_directory = '/var/run/postgresql' I don't understand what restriction you mean. What was changed is the default location of the unix domain socket. If you still want it in /tmp, you can put it there. I think there are basicly two reasons to move it: - It's insecure, as this thread shows - The FHS says the they should be placed in /var/run/, probably for the first reason. Kurt ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Spoofing as the postmaster
On Sun, Dec 23, 2007 at 02:52:28PM -0500, Tom Lane wrote: Problem? What we mustn't lose sight of is that that's not a bug but a feature. It would be completely inappropriate for us as upstream to destroy that property, and my fundamental objection to what Debian has done is that they've destroyed that property at the distro level. I'm unsure what you think is being prevented. Debian allows parallel installation and execution of four major releases of postgres with no extra effort, something the standard release doesn't do. At cluster creation time you can specify what version, what user and what location should be used and all the clients can work with this. I have no problem with the admin for a single installation putting in things that prevent there being more than one postmaster on that machine. I just say that software distribution time is not the place for such restrictions. Nothing is being prevented here. Things are being made possible that are otherwise difficult. Have a niec day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F Kennedy signature.asc Description: Digital signature
Re: [HACKERS] Spoofing as the postmaster
Kurt Roeckx [EMAIL PROTECTED] writes: On Sun, Dec 23, 2007 at 02:52:28PM -0500, Tom Lane wrote: a feature. It would be completely inappropriate for us as upstream to destroy that property, and my fundamental objection to what Debian has done is that they've destroyed that property at the distro level. The default postgresql.conf in Debian contains a line like this: unix_socket_directory = '/var/run/postgresql' I don't understand what restriction you mean. What was changed is the default location of the unix domain socket. If you still want it in /tmp, you can put it there. Not as easily as all that, because the system copy of libpq.so has the other directory hard-wired into it. Yes, you can sort of make it work if you have to, but it's inconvenient and error-prone. I think there are basicly two reasons to move it: - It's insecure, as this thread shows - The FHS says the they should be placed in /var/run/, probably for the first reason. We've had that discussion before. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Spoofing as the postmaster
On Sun, 23 Dec 2007, Magnus Hagander wrote: I'm just surprised that people are actually surprised by this. To me, it's just a natural fact that happens to pretty much all systems. And a good reason not to let arbitrary users run processes that can bind to something on your server. Not everybody works for Enterprise, where price does not matter. I cannot afford a dedicated servers for database, DNS, e-mail, antispam, firewall, file, WWW etc. Even administrative overhead would be too much for one person IT staff. I have to run all of this and much more on one machine, so I'm interested in limiting rights for a user for example running WWW, so when, god forbid, compromized, it'd limit damage. I am also not able to run sophisticated security frameworks, limiting every user rights to just what they need, as maintaining it would require a security full-timer. So I'm not very fond of this insecure by default, it's your problem to make it secure attitude. I'm the one who reported this. Regards Tometzky -- ...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 were... Winnie the Pooh ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Spoofing as the postmaster
Martijn van Oosterhout [EMAIL PROTECTED] writes: On Sun, Dec 23, 2007 at 02:52:28PM -0500, Tom Lane wrote: Problem? What we mustn't lose sight of is that that's not a bug but a feature. It would be completely inappropriate for us as upstream to destroy that property, and my fundamental objection to what Debian has done is that they've destroyed that property at the distro level. I'm unsure what you think is being prevented. Well, use of standard portable PG clients, for one thing, and use of postmasters running under different userids for another. Debian allows parallel installation and execution of four major releases of postgres with no extra effort, something the standard release doesn't do. My hat's off to them for that, but it's utterly unrelated to the topic at hand, and it's not evidence that this particular decision of theirs was well taken. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Spoofing as the postmaster
Tomasz Ostrowski [EMAIL PROTECTED] writes: So I'm not very fond of this insecure by default, it's your problem to make it secure attitude. I'm the one who reported this. IIRC, you started out your argument by also saying that we had to move the TCP socket to the reserved range, so as to prevent the equivalent problem in the TCP case. (And, given the number of clients such as JDBC that can only connect via TCP, it certainly seems there's little point in changing the socket case if we don't change the TCP case.) So let's look at the implications: 1. Postmaster must be started as root, thereby introducing security risks of its own (ie, after breaking into the DB, an attacker might be able to re-acquire root privileges). 2. Can only have one postmaster per machine (ICANN is certainly not going to give us dozens of reserved addresses). 3. Massive confusion and breakage as various people transition to the new standard at different times. 4. Potential to create, rather than remove, spoofing opportunities anyplace there is confusion about which port the postmaster is really listening on. And at the end of the day there are still any number of ways to configure your system insecurely... Fundamentally these are man-in-the-middle attacks, and the only real solution is mutual authentication. Pretending that some quick-fix change eliminates that class of problem is a recipe for building systems that are less secure, not more so. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Spoofing as the postmaster
On Sun, Dec 23, 2007 at 04:43:54PM -0500, Tom Lane wrote: snip use of postmasters running under different userids for another. This is specifically allowed and I mentioned it in the email you responded to, so I don't understand why you think it's not possible. Usage: /usr/bin/pg_createcluster [options] version cluster name Options: -u uid cluster owner and superuser (default: 'postgres') -g gid group for data files (default: primary group of owner) -d dir data directory (default: /var/lib/postgresql/version/cluster name) -s dir socket directory (default: /var/run/postgresql for clusters owned by 'postgres', /tmp for other clusters) -l dir path to desired log file (default: /var/log/postgresql/postgresql-version-cluster.log) --locale encoding set cluster locale (default: inherit from environment) --lc-collate/ctype/messages/monetary/numeric/time locale like --locale, but only set for a particular category -e encoding Default encoding (default: derived from locale) -p port port number (default: next free port starting from 5432) --start start the cluster after creating it --start-conf auto|manual|disabled Set automatic startup behaviour in start.conf (default: 'auto') Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F Kennedy signature.asc Description: Digital signature
Re: [HACKERS] Spoofing as the postmaster
Tom Lane wrote: Tomasz Ostrowski [EMAIL PROTECTED] writes: So I'm not very fond of this insecure by default, it's your problem to make it secure attitude. I'm the one who reported this. IIRC, you started out your argument by also saying that we had to move the TCP socket to the reserved range, so as to prevent the equivalent problem in the TCP case. (And, given the number of clients such as JDBC that can only connect via TCP, it certainly seems there's little point in changing the socket case if we don't change the TCP case.) It should also be noted that not all operating systems even have the concept of a reserved range of ports. Fundamentally these are man-in-the-middle attacks, and the only real solution is mutual authentication. Pretending that some quick-fix change eliminates that class of problem is a recipe for building systems that are less secure, not more so. And SSL can certainly do that. But I can agree that our SSL documentation could be much clearer on how to do things, and what's a best practice :-) Instead of just adding a section on preventing spoofing attacks, perhaps what we really need is a general chapter on how to secure your system and what's best practices. Which would also cover things like don't run everything as superuser etc (which is a much more likely problem to be seen in deployments) //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Spoofing as the postmaster
Martijn van Oosterhout [EMAIL PROTECTED] writes: On Sun, Dec 23, 2007 at 04:43:54PM -0500, Tom Lane wrote: snip use of postmasters running under different userids for another. This is specifically allowed and I mentioned it in the email you responded to, so I don't understand why you think it's not possible. -s dir socket directory (default: /var/run/postgresql for clusters owned by 'postgres', /tmp for other clusters) Egad. Is it not apparent to you what a bad idea that is? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Spoofing as the postmaster
On 12/23/07, Tomasz Ostrowski [EMAIL PROTECTED] wrote: On Sun, 23 Dec 2007, Magnus Hagander wrote: I'm just surprised that people are actually surprised by this. To me, it's just a natural fact that happens to pretty much all systems. And a good reason not to let arbitrary users run processes that can bind to something on your server. Not everybody works for Enterprise, where price does not matter. I cannot afford a dedicated servers for database, DNS, e-mail, antispam, firewall, file, WWW etc. Even administrative overhead would be too much for one person IT staff. I have to run all of this and much more on one machine, so I'm interested in limiting rights for a user for example running WWW, so when, god forbid, compromized, it'd limit damage. I am also not able to run sophisticated security frameworks, limiting every user rights to just what they need, as maintaining it would require a security full-timer. So I'm not very fond of this insecure by default, it's your problem to make it secure attitude. I'm the one who reported this. It's not that; it's the fact that if anyone can run a service on a computer, then anyone connecting to that computer won't necessarily know whose service they're connecting to, is a basic thing that should only take a moment's thought to recognize. I wouldn't knock anyone for not automatically realizing it can be a threat to security, but it's so very common it's hard to see why anyone would really be *surprised* by it. SSL and SSH both address the problem of the client wanting to verify the server, so usually being aware of either of those is enough to make someone aware of the issue in general. There is no default or automatic solution because the basic issue is one of trust, which requires an external procedure to address. (SSH generates a key on its own, but you are responsible for transferring the signature to the remote client in a secure manner so they can verify it. SSL typically has an external company generate your key after being paid to verify your identity, and presumably the remote client already trusts that company. You can also use the SSH approach with SSL.) There are various platform-specific security features that might be useful, like reserved port ranges and file permissions, but they are so specific to the scenario they're designed for that it's hard to create a generic solution that works well by default -- especially if you want to run without requiring administrative privileges in the first place. Having the adminstrator be responsible for organizing what they need is the only thing that seems to work in practice, since the requirements are so different for different environments. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Spoofing as the postmaster
On Sun, 23 Dec 2007, Tom Lane wrote: IIRC, you started out your argument by also saying that we had to move the TCP socket to the reserved range, so as to prevent the equivalent problem in the TCP case. 1. Postmaster must be started as root, thereby introducing security risks of its own (ie, after breaking into the DB, an attacker might be able to re-acquire root privileges). Not at all, as it won't run as root, it'll just start as root and then give up all root privileges. The only thing it would have after being root is just an open socket. 2. Can only have one postmaster per machine (ICANN is certainly not going to give us dozens of reserved addresses). I don't think ICANN would prevent anybody from using different port. I'm running httpd on port 81, sshd on 222 etc. It's just the default that should be made official through ICANN. 3. Massive confusion and breakage as various people transition to the new standard at different times. As with any major version. 4. Potential to create, rather than remove, spoofing opportunities anyplace there is confusion about which port the postmaster is really listening on. I agree. But because it would just not work it'll be easy to notice and correct. And when corrected it would be no more confusion. Fundamentally these are man-in-the-middle attacks, and the only real solution is mutual authentication. The problem is not many people expect man-in-the-middle attack on secure lan, localhost or local socket connection, so they'll not try to prevent it. Regards Tometzky -- ...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 were... Winnie the Pooh ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Spoofing as the postmaster
* Trevor Talbot ([EMAIL PROTECTED]) wrote: There are various platform-specific security features that might be useful, like reserved port ranges and file permissions, but they are so specific to the scenario they're designed for that it's hard to create a generic solution that works well by default -- especially if you want to run without requiring administrative privileges in the first place. Agreed. A guarentee that the process listening on a particular port is what you're expecting isn't something that upstream can give. It needs to be done through some situation-specific mechanism. There are a number of options here, of course: SSL, Kerberos, SELinux, even things like the tiger IDS. Reserved ports really aren't all that great a solution in the end anyway, to be honest. Enjoy, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Spoofing as the postmaster
Stephen Frost wrote: * Trevor Talbot ([EMAIL PROTECTED]) wrote: There are various platform-specific security features that might be useful, like reserved port ranges and file permissions, but they are so specific to the scenario they're designed for that it's hard to create a generic solution that works well by default -- especially if you want to run without requiring administrative privileges in the first place. Agreed. A guarentee that the process listening on a particular port is what you're expecting isn't something that upstream can give. It needs to be done through some situation-specific mechanism. There are a number of options here, of course: SSL, Kerberos, SELinux, even things like the tiger IDS. Reserved ports really aren't all that great a solution in the end anyway, to be honest. UNIX socket kernel credential passing was mentioned in an earlier post, but I didn't see it raised again. All of the above mechanisms still require a piece of information to validate trust. SSL requires a copy of the public certificate. UNIX socket credential passing would be much cheaper to validate - all it requires is the userid or username. I prefer UNIX sockets with kernel credential passing over TCP/IP with username/password or the more expensive SSL. I do not like storing passwords or private certificates in a place available to the web user, as other web users would then also have access. I do not have evidence, but I am under the impression that the TCP/IP stack incurs additional overhead on connect(), send(), recv(), and close() than UNIX sockets. Yes, Java doesn't work with UNIX sockets - but both Perl and PHP do. The only reason Java doesn't is because Java itself doesn't support UNIX sockets, and the Java JDBC provider is pure-Java. How expensive would it be to implement a server_user db open parameter that would perform reverse credential passing to validate? dbname=XXX port=5432 server_user=postgres. If the server can't prove it is postgres through UNIX socket credential passing, it fails. Similarly, identd may be usable in reverse? I've seen many people claim identd is insecure - but it is secure if I am the one running it, is it not? Cheers, mark -- Mark Mielke [EMAIL PROTECTED]
Re: [HACKERS] Spoofing as the postmaster
Mark Mielke [EMAIL PROTECTED] writes: UNIX socket kernel credential passing was mentioned in an earlier post, but I didn't see it raised again. I mentioned getsockopt(SO_PEERCRED) which isn't the same as credential passing. It just tells you what uid is on the other end of your unix domain socket. I think it's much more widespread and portable than credential passing which was a BSD feature which allowed you to send along your kernel credentials to another process. So you could, for example, open a file in psql then pass the file descriptor to the backend to have the backend read directly from the file. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
