Re: [HACKERS] Spoofing as the postmaster
On Sat, Dec 22, 2007 at 09:25:05AM -0500, Bruce Momjian wrote: So, what solutions exist? We could require the use of port numbers less than 1024 which typically require root and then become a non-root user, but that requires root to start the server. We could put the unix I don't know about *requiring* this, but it would certainly be a nice option to have. Right now there's absolutely no way that you could get Postgres to use a port 1024. -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 pgp5kYYo0x2d8.pgp Description: PGP signature
Re: [HACKERS] Spoofing as the postmaster
Greg Smith wrote: On Sat, 29 Dec 2007, Joshua D. Drake wrote: http://code.google.com/p/sepgsql/ ??? Getting that to work required some obtrusive changes to the source code, which they've only done to 8.2.4. Even that doesn't seem to be production-quality and it's not clear how that will make its way into newer versions yet. Sorry for my late responding. I don't argue your opinion about its quality issue. We indeed need more feedbacks and improvements from widespread viewpoints. The current status of SE-PostgreSQL is a bit incorrect. The latest one is sepostgresql-8.2.5-1.66.fc9, based on 8.2.5. See, http://download.fedora.redhat.com/pub/fedora/linux/development/ Currently, we are paying efforts to port SE-PostgreSQL features into 8.3.x based PostgreSQL. (It is based on 8.3beta based PostgreSQL in correct.) The job here is to work on the SELinux policies for PostgreSQL. You can't just re-use whatever work has gone into the SE-PostgreSQL ones, because those presume you're using their modified server instead of the regular one. Yes, SE-PostgreSQL requires to stop the regular one when it works. We cannot use both of them at the same time. However, the default security policy is designed as if it works like regular one without any special SELinux configuration. If you can find out any bug or unclear behavior, I want you to report it. I started collecting notes and writing a PostgreSQL/SELinux how-to aimed at RHEL 5.0+ but I'm not doing work in that area anymore. I'm interested in this effort. Could you tell me the URL? Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Spoofing as the postmaster
Joshua D. Drake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 29 Dec 2007 14:40:29 -0500 (EST) Greg Smith [EMAIL PROTECTED] wrote: On Sat, 29 Dec 2007, Joshua D. Drake wrote: http://code.google.com/p/sepgsql/ ??? Getting that to work required some obtrusive changes to the source code, which they've only done to 8.2.4. Even that doesn't seem to be production-quality and it's not clear how that will make its way into newer versions yet. they've has the potential to be we... As I recall the individual made a reasonable effort to introduce the work that he was doing to the community. http://archives.postgresql.org/pgsql-hackers/2007-03/msg00271.php http://archives.postgresql.org/pgsql-hackers/2007-04/msg00664.php If my memory is correct, the alpha implementation was announced after the feature freeze date of 8.3. # Sorry for my lacking of understanding for PostgreSQL development processes. Therefore, Tom suggested this kind of discussion should be restarted after the release of 8.3. I also agreed it. But unless there's somebody else with a burning need to work on this area I doubt that will happen--there's nothing about SELinux that anybody does just for fun. Ya think? :P I recognize that this SE PGSQL has the potential to be a portability nightmare (as it only works on linux) but it certainly has potential to give us a leg up on a lot of work. Yes, it works only on Linux. I added --enable-selinux build option into the configure script. It prevent to enable SE-PostgreSQL feature on any other plathomes. Anyway, not saying its good code but I did read the docs and it sure looks cool. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Spoofing as the postmaster
Greg Smith wrote: On Sat, 29 Dec 2007, Joshua D. Drake wrote: they've has the potential to be we... As I recall the individual made a reasonable effort to introduce the work that he was doing to the community. After a bit of hindsight research, I think SE-PostgreSQL suffered from two timing problems combined with a cultural misperception. The first timing issue was that those messages went out just as the 8.3 feature freeze was going on. I know I looked at their stuff for a bit at that point, remembered I had patches to work on, and that was it at that point. Yes, it was lack of my understanding of PostgreSQL development process. The second problem is that just after the first message to the list came out, RedHat released RHEL 5.0, which did a major reworking of SELinux that everyone could for production systems immediately. I know all my SELinux time at that point immediately switched to working through the major improvements RHEL5 made rather than thinking about their project. The most of SELinux features on RHEL5.0 are based on Fedora core 6. It does not contain any SE-PostgreSQL support. We have to wait for next major release of RHEL to apply SE-PostgreSQL features on production system. If you can try out it on non-production system, Fedora 8 is the most recommendable environment. The cultural problem is that their deliverable was a series of RPM packages (for Fedora 7, ack). They also have a nice set of user documentation. But you can't send a message to this hackers list asking for feedback and hand that over as your reference. People here want code. When I wander through the threads that died, I think this message shows the mismatch best: http://archives.postgresql.org/pgsql-hackers/2007-04/msg00722.php Hmm... I'll send it as a patch to discuss this feature. Please wait for we can port it into the latest postgresql tree. (Maybe, it is nonsense to discuss 8.2.x based patches.) When Tom throws out an objection that a part of the design looks sketchy, the only good way to respond is to throw the code out and let him take a look. I never saw the SE-PostgreSQL group even showing diffs of what they did; making it easy to get a fat context diff (with a bit more context than usual) would have done wonders for their project. You're not going to get help from this community if people have to install a source RPM and do their own diff just to figure out what was changed from the base. Thanks for your indications. -- OSS Platform Development Division, NEC KaiGai Kohei [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Spoofing as the postmaster
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Agreed. Requiring client root certificate checking is heavy-handed. There seems to be some confusion here. I didn't think anyone was proposing that we force every installation to require client root certificate checking. What was under discussion (I thought) was providing the ability for a DBA to *choose* to require it. Ok, at least someone is partly lost in this discussion, and I'm getting a sneaky suspicion it's me :-) We already *do* allow the DBA to choose this, no? If you put the root certificate on the client, it *will* verify the server cert, and it *will* refuse to connect to a server that can't present a trusted root cert. Hang on, maybe I get what you're referring to now - we don't check the Common Name field on the certificate, so *any* trusted certificate would be ok. Incorrect common name generally results in a warning in a browser, for example, but we accept it fine. We do store it in conn-peer_cn, so the client can check it if they need to. But we don't enforce. Or are you saying that the *server* should require that the client has done verification, by a config string? If so, I just don't see how that's possible in any meaningful way. Of course I am not sure anyone knows how to get that information from SSL. Yeah, if OpenSSL doesn't support testing for this then the discussion is moot... AFAIK, our current OpenSSL code supports verifying both client and server certificates. If we want to, as Bruce suggested, emit a log message when the client hasn't provided a certificate, we can certainly do so. But I thought this thread was about impersonating the server, not the client... Emitting such a log message in cases where the system isn't configured to use client certificates at all would cause a whole lot of unnecessary logging for all cases that don't use client certificates. And if you *do* use client certificates, it's not going to get emitted because you can't even *connect* without having it. Now, if/when we actually support authenticating with client certificates (as I said, I hope to work on this), the equation is different because then you can set it per hba using authentication method. But just enabling such a thing globally is a very blunt instrument... //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Spoofing as the postmaster
Mark Mielke wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Agreed. Requiring client root certificate checking is heavy-handed. There seems to be some confusion here. I didn't think anyone was proposing that we force every installation to require client root certificate checking. What was under discussion (I thought) was providing the ability for a DBA to *choose* to require it. Of course I am not sure anyone knows how to get that information from SSL. Yeah, if OpenSSL doesn't support testing for this then the discussion is moot.. I believe SSL is only capable of letting you know whether authentication for each end point was 1) not requested, 2) optional requested, or 3) required. Note that even if the authentication is required, there is no way to know how authentication was performed. For example, did it check the signature chain, requiring it to map to a public root certificate lists used by most web browsers? If so, did it check the contents of the certificate, or is only checking that it exists? Did it check a local key store that has a copy of the public key certificate? Or did it just log the certificate subject? That is exactly my point. The server can never know if the client has actually verified anything. It can provide the client with the *means* to verify things, but it can't enforce it. A naive implementation would have a flag in the protocol that says enforce client to validate server certs. The MITM attacker could then just remove this flag in the stream before it arrives at the client, and it's gone. And the kind of attack we would be trying to protect from here is exactly the one that can trivially remove such a check. It would just be a no-op with administrative overhead, really. The bottom line is that the server cannot be responsible for client security. Only the client can. OpenSSH, for instance, presents the user with the finger print of the certificate and asks you: $ ssh 192.168.0.1 The authenticity of host '192.168.0.1 (192.168.0.1)' can't be established. RSA key fingerprint is 3e:a7:0f:04:60:7e:8e:64:52:bf:81:92:a9:05:c7:36. Are you sure you want to continue connecting (yes/no)? While this certainly gives you the opportunity to challenge it, I don't know of any person who actually checks this finger print. Luckily, it stores it to ~/.ssh/known_hosts, and so the real issue is if it suddenly changes, you get a warning. Still, I've seen the warning before, and realized that oh yes, that machine was upgraded, so it probably has a new public key. I have never personally checked the finger print against a known source. Authentication is only as strong as the person or process confirming it. In the case of trying to force a client to authenticate the server, this requires the client to know who the server is. As most clients will not know who the server is, I see clients implementing an OpenSSH-style authentication model (shown above), or providing their own no-op authentication routine to OpenSSL. I don't think it is worth it, and I don't think it would work. Yeah, it *is* decent protection against it suddenly changing. But as you say, that requires the original fingerprint to be stored at the client. Just like if you store the root or server cert on a libpq client, it will refuse to connect if the server suddenly presents an untrusted certificate. (So in that way we're actually *more* secure than OpenSSH, since we don't give you a prompt to ignore an untrusted root cert - we just refuse to connect. Unless you manually disable the check by removing the file.) //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Spoofing as the postmaster
On Sat, Dec 29, 2007 at 12:40:24PM +0100, Magnus Hagander wrote: We already *do* allow the DBA to choose this, no? If you put the root certificate on the client, it *will* verify the server cert, and it *will* refuse to connect to a server that can't present a trusted root cert. I think Tom's point is that we don't allow this for connections over a Unix Domain socket. And thus we should remove the asymmetry so the verification can work for them also. Personally I quite liked the idea of having a serveruser=foo which is checked by getting the peer credentials. Very low cost, quick setup solution. 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
Martijn van Oosterhout wrote: On Sat, Dec 29, 2007 at 12:40:24PM +0100, Magnus Hagander wrote: We already *do* allow the DBA to choose this, no? If you put the root certificate on the client, it *will* verify the server cert, and it *will* refuse to connect to a server that can't present a trusted root cert. I think Tom's point is that we don't allow this for connections over a Unix Domain socket. And thus we should remove the asymmetry so the verification can work for them also. If that's where we still are, then I'm all for that provided it doesn't add a whole lot of complexity, as I think I said before. I thought we were now talking general SSL connections. That could be where I lost the thread :-) Personally I quite liked the idea of having a serveruser=foo which is checked by getting the peer credentials. Very low cost, quick setup solution. It would still only tell you the user and not the postmaster ;-) But yes, it does help in the unix domain case (but not TCP-over-localhost). Either that, or a function that returns the peer credentials if available - like we have for SSL today. Then the client could do some more advanced checking if necessary - like allowing multiple different accounts if wanted. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Spoofing as the postmaster
Mark Mielke wrote: Magnus Hagander wrote: Mark Mielke wrote: I have done this for my own application before. Although the client and server use standard TLS 1.0 to speak to each other with a required authentication of RSA 1024-bit and a required encryption of AES 128-bit, it still requires that passwords sent from the client to the server are RSA encrypted using the server public certificate, making it impossible for anybody except for the legitimate server to see the password. One benefit of this is that the password itself can be '\0'd out as soon as we have RSA encrypted it, and things like a core dump of the client have a lower chance of including the password in plain text. Why are you even using a password in this case, and not just key-based auth? Wouldn't that be even easier and more secure? Users of this product don't have keys - they have passwords. The username/password is for per-user authentication. The username defines the access level. Many users will use the same client. The client does have its own private RSA key and public certificate, however, this grants entry to the system. Password login is still required by the users of the client. And you have one private key *per client*? That's an interesting approach - and actually how pg will work if you enable client cert checking :-) It's probably about as far as you can get as long as you use passwords. If you want something that's really secure, you just have to give up using passwords. Solutions like one-time passwords from a token or certificates on a smartcard are what people use then :-) At what point does prudence become paranoia? I don't know. In my case, I felt 128-bit encryption was insufficient for protecting the passwords in my application. 256-bit encryption would have been sufficient, but that cannot yet be safely exported from the US to the countries I required. How do you protect the certificate store on the client? Or the binary that ends up prompting for the password on the client The certificate on the client grants access to the system. It does not grant access to the resources on the system. Two-level authentication with mandatory server authentication. You see similar things in physical security instances. A security badge lets you in the door - but you still need to login to the computer once you get in. As for protecting the binary that prompts for a password on the client - I didn't bother with this, although Java does allow for signed jar files that would allow the user to be assured that the client is legitimate. Only as long as you can trust the JRE... And the OS... (yeah, reaching, but still goes to prove the point that the system *cannot* be secure if people can chance your client code/machine. It can be secure from a server or network POV, but not froma client one) There are always loops though, just because the client is legitimate doesn't mean that the keyboard is, and so on. You end up putting in enough effort to mitigate the risk. The risk always exists, but through clever, cryptographic, or obfuscatory measures, the risk can be greatly reduced. Right. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Spoofing as the postmaster
On Sat, 29 Dec 2007 12:45:26 +0100 Magnus Hagander [EMAIL PROTECTED] wrote: That is exactly my point. The server can never know if the client has actually verified anything. It can provide the client with the *means* to verify things, but it can't enforce it. I know this is probably obvious to most people in this discussion and I don't mean to impugn Magnus just because I am latching onto his message to make this point but I suspect that this discussion would go a lot smoother if it branches into two completely different discussions about two completely different issues; - 1: How does the client assure that the postmaster is legit - 2: How does the postmaster assure that the client is legit Does anyone think that there is one answer to both? -- 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 wrote: Mark Mielke wrote: Why are you even using a password in this case, and not just key-based auth? Wouldn't that be even easier and more secure? Users of this product don't have keys - they have passwords. The username/password is for per-user authentication. The username defines the access level. Many users will use the same client. The client does have its own private RSA key and public certificate, however, this grants entry to the system. Password login is still required by the users of the client. And you have one private key *per client*? That's an interesting approach - and actually how pg will work if you enable client cert checking :-) Yep. It's probably about as far as you can get as long as you use passwords. If you want something that's really secure, you just have to give up using passwords. Solutions like one-time passwords from a token or certificates on a smartcard are what people use then :-) Yes. Pseudo-random number generator on an LCD display that changes every 60 seconds, or one of those government satellite-based systems. :-) Even still, it's often two forms of authentication. With the SecureID cards, the number proves you have the physical card on your possession, and the password proves you have access to the person's brain (or piece of paper that they stupidly wrote their password on :-) ). Most of these systems are not necessarily effective against kidnapping the person and threatening to kill them. However, they are very effective against random hackers on the Internet who are doing trial and error or some other approach. By denying entry BEFORE the password is provided, they are unable to guess passwords and get lucky. The certificate on the client grants access to the system. It does not grant access to the resources on the system. Two-level authentication with mandatory server authentication. You see similar things in physical security instances. A security badge lets you in the door - but you still need to login to the computer once you get in. As for protecting the binary that prompts for a password on the client - I didn't bother with this, although Java does allow for signed jar files that would allow the user to be assured that the client is legitimate. Only as long as you can trust the JRE... And the OS... (yeah, reaching, but still goes to prove the point that the system *cannot* be secure if people can chance your client code/machine. It can be secure from a server or network POV, but not froma client one) Correct. I believe this is why I didn't bother. I saw value to using better than 128-bit AES for the password (as per US export control regulations), but not for the data (the data was primarily a list of privileged write requests), and I saw value to making the password unreadable as soon as possible (the client might be long running, but it turns the password into RSA encrypted data soon after you hit ENTER, and reuses this for the length of the session if the password is required again). I didn't see value to protecting the client. There are always loops though, just because the client is legitimate doesn't mean that the keyboard is, and so on. You end up putting in enough effort to mitigate the risk. The risk always exists, but through clever, cryptographic, or obfuscatory measures, the risk can be greatly reduced. Right If it was an easy problem, somebody would have solved it once and for all, and the CIA would be out of business... :-) Cheers, mark -- Mark Mielke [EMAIL PROTECTED]
Re: [HACKERS] Spoofing as the postmaster
D'Arcy J.M. Cain wrote: - 1: How does the client assure that the postmaster is legit - 2: How does the postmaster assure that the client is legit And neither answers the original problem: 3. How can the sysadmin prevent a malicious local user from hijacking the sockets if the postmaster isn't running? Prevention is much more valuable than ex post detection, IMNSHO. Probably the first answer is not to run postgres on a machine with untrusted users, but that's not always possible. Maybe we can't find a simple cross-platform answer, but that doesn't mean we should not look at platform-specific answers, at least for documentation. 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 Sat, 29 Dec 2007 10:38:13 -0500 Andrew Dunstan [EMAIL PROTECTED] wrote: D'Arcy J.M. Cain wrote: - 1: How does the client assure that the postmaster is legit - 2: How does the postmaster assure that the client is legit And neither answers the original problem: Which seems to have been lost in the noise. 3. How can the sysadmin prevent a malicious local user from hijacking the sockets if the postmaster isn't running? A better way of stating it for sure. Prevention is much more valuable than ex post detection, IMNSHO. Probably the first answer is not to run postgres on a machine with untrusted users, but that's not always possible. Maybe we can't find a simple cross-platform answer, but that doesn't mean we should not look at platform-specific answers, at least for documentation. Yes, that's what I said at the start of this discussion. If you don't trust the users with actual access to the box, the rest of this is pretty much academic. -- 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
* D'Arcy J.M. Cain ([EMAIL PROTECTED]) wrote: Probably the first answer is not to run postgres on a machine with untrusted users, but that's not always possible. Maybe we can't find a simple cross-platform answer, but that doesn't mean we should not look at platform-specific answers, at least for documentation. Yes, that's what I said at the start of this discussion. If you don't trust the users with actual access to the box, the rest of this is pretty much academic. Academic from an upstream standpoint, but there are platform-specific / setup-specific things you can do (SELinux, vserver/jails, Kerberos, SSL, etc...). Documenting it is good, but I think it should really be to the extent of saying look, 5432 is unprivledged, here are some ways to deal with that and you should probably put the PG unix socket in a secured directory (though Debian and I suspect many other distributions do this part for you). Enjoy, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Spoofing as the postmaster
Andrew Dunstan wrote: D'Arcy J.M. Cain wrote: - 1: How does the client assure that the postmaster is legit - 2: How does the postmaster assure that the client is legit And neither answers the original problem: 3. How can the sysadmin prevent a malicious local user from hijacking the sockets if the postmaster isn't running? Prevention is much more valuable than ex post detection, IMNSHO. Probably the first answer is not to run postgres on a machine with untrusted users, but that's not always possible. Maybe we can't find a simple cross-platform answer, but that doesn't mean we should not look at platform-specific answers, at least for documentation. I thought this answer was already provided: Put the socket in a directory that is only writable by the database owner. The socket is created as part of the bind() process. I think this covers 90%+ of it, and is already in use by distributions. The only thing better this team could do would be to formalize it? The serveruser= db open parameter might be enough to lock it up tight if there is still a race condition on bind(). It's effectively a very cheap authentication mechanism that does not require expensive cryptographic operations. There is probably value to making SSL consistent for TCP/UNIX sockets as Tom suggests. Removing the inconsistency as it were, and allowing for SSL authentication and encryption for UNIX sockets the same as for TCP sockets. If it was as simple as removing an if statement that would be even cooler... :-) What has come out for me is that this isn't UNIX socket specific at all (although there may be UNIX socket specific options available). The standard PostgreSQL port is above 1024, and anybody could bind()/listen()/accept() on it, assuming it is not running. This is where your first answer of running PostgreSQL on a machine with trusted users comes in as a sensible recommendation, even if only some people are willing to accept this recommendation. :-) Cheers, mark -- Mark Mielke [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Spoofing as the postmaster
Magnus Hagander wrote: Martijn van Oosterhout wrote: On Sat, Dec 29, 2007 at 12:40:24PM +0100, Magnus Hagander wrote: We already *do* allow the DBA to choose this, no? If you put the root certificate on the client, it *will* verify the server cert, and it *will* refuse to connect to a server that can't present a trusted root cert. I think Tom's point is that we don't allow this for connections over a Unix Domain socket. And thus we should remove the asymmetry so the verification can work for them also. If that's where we still are, then I'm all for that provided it doesn't add a whole lot of complexity, as I think I said before. I thought we were now talking general SSL connections. That could be where I lost the thread :-) I think the user-visible impact of that addition would be to add 'localssl' in pg_hba.conf. It would be nice if we had made SSL control separate from the connection type, and perhaps we will explore that in 8.4. (None of this is 8.3, I believe.) -- 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 6: explain analyze is your friend
Re: [HACKERS] Spoofing as the postmaster
Mark Mielke wrote: Andrew Dunstan wrote: D'Arcy J.M. Cain wrote: - 1: How does the client assure that the postmaster is legit - 2: How does the postmaster assure that the client is legit And neither answers the original problem: 3. How can the sysadmin prevent a malicious local user from hijacking the sockets if the postmaster isn't running? Prevention is much more valuable than ex post detection, IMNSHO. Probably the first answer is not to run postgres on a machine with untrusted users, but that's not always possible. Maybe we can't find a simple cross-platform answer, but that doesn't mean we should not look at platform-specific answers, at least for documentation. I thought this answer was already provided: Put the socket in a directory that is only writable by the database owner. The socket is created as part of the bind() process. I think this covers 90%+ of it, and is already in use by distributions. The only thing better this team could do would be to formalize it? The serveruser= db open parameter might be enough to lock it up tight if there is still a race condition on bind(). It's effectively a very cheap authentication mechanism that does not require expensive cryptographic operations. It's in use by some distributions, hardly all, or even a majority. AFAIK it's only in Debian + descendants. Anyway, I think it could arguably make matters worse, not better, by guaranteeing that the postmaster can start up even if the TCP socket has been hijacked . That's why I suggested it might be useful to have a switch that says don't start if any interface fails to bind (which was the old pre-8.0 behaviour). It might well be useful for us to look at drafting an SELinux policy, even if it's not universal. After all, this situation is precisely the sort of thing that SELinux is about, ISTM. cheers andrew ---(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
Andrew Dunstan [EMAIL PROTECTED] writes: It might well be useful for us to look at drafting an SELinux policy, There already is one. However, I'm not sure that it's ever been reviewed by anyone who's Postgres-savvy (I certainly haven't looked at it:-(). It would be useful for that to happen. Another thing is that we could stand to have some documentation on how to adjust the policy for local needs --- in particular, supporting tablespaces that're outside /var/lib/pgsql. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Spoofing as the postmaster
Mark Mielke [EMAIL PROTECTED] writes: What has come out for me is that this isn't UNIX socket specific at all (although there may be UNIX socket specific options available). The standard PostgreSQL port is above 1024, and anybody could bind()/listen()/accept() on it, assuming it is not running. Right. The real bottom line is that a socket in /tmp is exactly as secure as a localhost TCP port. There is no value in debating moving the default socket location unless you are prepared to also relocate the default port to below 1024 (and even that helps only on Unix-y platforms). I remain of the opinion that what we should do about this is support SSL usage over sockets and document the issues. 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
On Sat, 29 Dec 2007, Joshua D. Drake wrote: http://code.google.com/p/sepgsql/ ??? Getting that to work required some obtrusive changes to the source code, which they've only done to 8.2.4. Even that doesn't seem to be production-quality and it's not clear how that will make its way into newer versions yet. The job here is to work on the SELinux policies for PostgreSQL. You can't just re-use whatever work has gone into the SE-PostgreSQL ones, because those presume you're using their modified server instead of the regular one. I started collecting notes and writing a PostgreSQL/SELinux how-to aimed at RHEL 5.0+ but I'm not doing work in that area anymore. On reflection I might just release what I did so far to the developer's wiki and see if anybody else fills in the missing pieces. But unless there's somebody else with a burning need to work on this area I doubt that will happen--there's nothing about SELinux that anybody does just for fun. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 29 Dec 2007 14:40:29 -0500 (EST) Greg Smith [EMAIL PROTECTED] wrote: On Sat, 29 Dec 2007, Joshua D. Drake wrote: http://code.google.com/p/sepgsql/ ??? Getting that to work required some obtrusive changes to the source code, which they've only done to 8.2.4. Even that doesn't seem to be production-quality and it's not clear how that will make its way into newer versions yet. they've has the potential to be we... As I recall the individual made a reasonable effort to introduce the work that he was doing to the community. http://archives.postgresql.org/pgsql-hackers/2007-03/msg00271.php http://archives.postgresql.org/pgsql-hackers/2007-04/msg00664.php The job here is to work on the SELinux policies for PostgreSQL. You can't just re-use whatever work has gone into the SE-PostgreSQL ones, because those presume you're using their modified server instead of the regular one. Fair enough. I was just trying to offer a source to start with. But unless there's somebody else with a burning need to work on this area I doubt that will happen--there's nothing about SELinux that anybody does just for fun. Ya think? :P I recognize that this SE PGSQL has the potential to be a portability nightmare (as it only works on linux) but it certainly has potential to give us a leg up on a lot of work. Anyway, not saying its good code but I did read the docs and it sure looks cool. Sincerely, Joshua D. Drake - -- The PostgreSQL Company: Since 1997, http://www.commandprompt.com/ Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate SELECT 'Training', 'Consulting' FROM vendor WHERE name = 'CMD' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHdqriATb/zqfZUUQRAk73AJ9/Gy2+5mjxBsbEZHyCycp/HgwR0wCfYHPw TaLkLocBWGpgP0Z7T+IaaWA= =0Zwj -END PGP SIGNATURE- ---(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
On Sat, 29 Dec 2007, Joshua D. Drake wrote: they've has the potential to be we... As I recall the individual made a reasonable effort to introduce the work that he was doing to the community. After a bit of hindsight research, I think SE-PostgreSQL suffered from two timing problems combined with a cultural misperception. The first timing issue was that those messages went out just as the 8.3 feature freeze was going on. I know I looked at their stuff for a bit at that point, remembered I had patches to work on, and that was it at that point. The second problem is that just after the first message to the list came out, RedHat released RHEL 5.0, which did a major reworking of SELinux that everyone could for production systems immediately. I know all my SELinux time at that point immediately switched to working through the major improvements RHEL5 made rather than thinking about their project. The cultural problem is that their deliverable was a series of RPM packages (for Fedora 7, ack). They also have a nice set of user documentation. But you can't send a message to this hackers list asking for feedback and hand that over as your reference. People here want code. When I wander through the threads that died, I think this message shows the mismatch best: http://archives.postgresql.org/pgsql-hackers/2007-04/msg00722.php When Tom throws out an objection that a part of the design looks sketchy, the only good way to respond is to throw the code out and let him take a look. I never saw the SE-PostgreSQL group even showing diffs of what they did; making it easy to get a fat context diff (with a bit more context than usual) would have done wonders for their project. You're not going to get help from this community if people have to install a source RPM and do their own diff just to figure out what was changed from the base. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(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: 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 ... Added to TODO: * Allow SSL authentication/encryption over unix domain sockets -- 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
On Thu, 27 Dec 2007, Stephen Frost wrote: Debian also has SELinux, if one wishes to configure it. I suspect other Debian-derived distributions also have it as a result. It can certainly be a pain to configure but it's far from impossible That's a good summary. As of Debian Etch (April of this year) the base distribution now include enough SELinux compatible userland packages for the fundamental utilities (ssh, svsvinit, pam, cron, some others) that you don't have to run around hacking a set of patches anymore just to get the base system working. There is also a Hardened Gentoo with SELinux. The most notable distribution where SELinux support is seriously dead is SuSE. RHEL/Fedora are the only distributions where SELinux is taken seriously enough that most packages/daemons are patched and have policies setup in a useful state out of the box. But with some work you can customize a reasonable setup on some other distributions. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Spoofing as the postmaster
The problem with forcing authentication is that an auth-unaware client connecting to a legitimate postmaster would have its connections refused. That same client would have its connections accepted by an impostor postmaster. Thus, there is no way to stop impostor postmasters from carrying out these attacks on auth-unaware clients. The proper solution, as I see it, would be to have an authentication system in the postmaster that was not enforced. If the client requests authentication, postmaster will provide it, if not, then postmaster will connect normally without it. This would not result in *any* change in the default behavior of postmaster, and as far as users who don't want to use it are concerned, they don't even need to bother to turn it off (assuming that having it turned on does not consume extra resources and I don't think having an unused authentication mechanism sitting in the postmaster connection establishment routine would). This does not appear to result in greater security, however it does. It allows DBAs who suspect that they are likely going to be the target of these attacks to deploy authentication procedures in their client packages. This could be a modification to their applications, or whatever steps are necessary to mandate authenticated connections within their organization. There is no point forcing some auth mechanism within postmaster, as attackers would simply catch users using software that did not require the server to auth before sending passwords. For this reason it is not postmaster's responsibility to check that unknown clients do not connect to impostors, it is postmaster's responsibility however to authenticate itself, if the client asks for it. So the onus (rightfully in my opinion) falls upon network administrators / DBAs to ensure that all of their users are using auth-enabled client packages which will not allow connections to be established with a postmaster until authentication has passed, and disallow the use of other client software to connect to postmaster. In my view, this puts the security responsibility where it rightfully belongs *and* maintains a non-breaking of client packages in the wild. Making a server or anything that *requires* auth and disallows non-authed clients is pointless, as there is nothing stopping attackers from setting up an auth-disabled impostor and waiting for someone to just connect using psql or some other vanilla connection method. The onus really ought to be with the administrators who give their users the software they use to connect to ensure that the software they use adheres to the relevant security policy, in the same way that its their responsibility to ensure that the client software does not contain keyloggers and other such trashware. In the web world, it is the client's responsibility to ensure that they check the SSL cert and don't do their banking at www.bankofamerica.hax0r.ru and there is nothing that the real banking site can do to stop them using their malware infested PC to connect to the phishing site. They can only provide a site that provides authentication. This is analogous to postmaster: It is only the responsibility of postmaster to provide the option of authentication, it is the client's responsibility to know if they should use it, and if so, to ensure they do so properly. Regards, - MrNaz.com ---(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 Sat, Dec 29, 2007 at 02:09:23AM +1100, Naz Gassiep wrote: In the web world, it is the client's responsibility to ensure that they check the SSL cert and don't do their banking at www.bankofamerica.hax0r.ru and there is nothing that the real banking site can do to stop them using their malware infested PC to connect to the phishing site. The above security model is exactly how we got into the mess we're in: relying entirely on the good sense of a wide community of users is how compromises happen. Strong authentication authenticates both ways. For instance, the web world you describe is not the only one. Banks who take security seriously have multiple levels of authentication, have trained their users how to do this, and regularly provide scan tools to clients in an attempt (IMO possibly doomed) to reduce the chances of input-device sniffing. A ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Spoofing as the postmaster
On 12/28/07, Andrew Sullivan [EMAIL PROTECTED] wrote: On Sat, Dec 29, 2007 at 02:09:23AM +1100, Naz Gassiep wrote: In the web world, it is the client's responsibility to ensure that they check the SSL cert and don't do their banking at www.bankofamerica.hax0r.ru and there is nothing that the real banking site can do to stop them using their malware infested PC to connect to the phishing site. The above security model is exactly how we got into the mess we're in: relying entirely on the good sense of a wide community of users is how compromises happen. Strong authentication authenticates both ways. For instance, the web world you describe is not the only one. Banks who take security seriously have multiple levels of authentication, have trained their users how to do this, and regularly provide scan tools to clients in an attempt (IMO possibly doomed) to reduce the chances of input-device sniffing. I don't follow. What are banks doing on the web now to force clients to authenticate them, and how is it any different from the model of training users to check the SSL certificate? There's a fundamental problem that you can't make someone else do authentication if they don't want to, and that's exactly the situation clients are in. I don't see how this can possibly be fixed anywhere other than the client. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Spoofing as the postmaster
Trevor Talbot [EMAIL PROTECTED] writes: There's a fundamental problem that you can't make someone else do authentication if they don't want to, and that's exactly the situation clients are in. I don't see how this can possibly be fixed anywhere other than the client. The point of requiring authentication from the server side is that it will get people to configure their client code properly. Then if a MITM attack is subsequently attempted, the client code will detect it. It's true that this doesn't offer much defense in the case where a new user is getting set up and a MITM attack is already active. But a user who blindly trusts a server that he's never connected to before is open to all sorts of attacks, starting for instance with mistyping the host name. The fact that this approach doesn't (by itself) solve that problem doesn't make it useless. Also, getting people in the habit of setting up for mutual authentication does have value in that scenario too; it makes the new user perhaps a bit more likely to distrust a server that isn't presenting the right certificate. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Spoofing as the postmaster
On 12/28/07, Tom Lane [EMAIL PROTECTED] wrote: Trevor Talbot [EMAIL PROTECTED] writes: There's a fundamental problem that you can't make someone else do authentication if they don't want to, and that's exactly the situation clients are in. I don't see how this can possibly be fixed anywhere other than the client. The point of requiring authentication from the server side is that it will get people to configure their client code properly. Then if a MITM attack is subsequently attempted, the client code will detect it. But this is essentially just an education/training issue; the security model itself is unchanged. Bank web sites are only going to accept clients via SSL, but if a client does not try to authenticate the site, whether it connects via SSL or not is rather irrelevant. I have no problem with the idea of encouraging clients to authenticate the server, but this configuration doesn't help with defaults. It's just available as a tool for site administrators to use. Also, getting people in the habit of setting up for mutual authentication does have value in that scenario too; it makes the new user perhaps a bit more likely to distrust a server that isn't presenting the right certificate. I see Naz's argument as addressing this goal. The problem with forcing authentication is that it's an all-or-nothing proposition: either the server and all the clients do it, or none of them do. That's fine when you control all the pieces and are willing to put in the work to configure them all, but not effective for encouraging default behavior. Instead, give the server credentials by default, but let clients choose whether to request them. That makes deployment easier in that all you have to do is configure clients as needed to get authentication of the server. Easier deployment means it's more likely to be used. IOW, put up both http and https out of the box. You might even want to have newer clients default to caching credentials on the first connect. That still doesn't change the security model, but should be more effective at getting clients to do something useful by default. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Spoofing as the postmaster
On Fri, Dec 28, 2007 at 07:48:22AM -0800, Trevor Talbot wrote: I don't follow. What are banks doing on the web now to force clients to authenticate them, and how is it any different from the model of training users to check the SSL certificate? Some banks (mostly Swiss and German, from what I've seen) are requiring two-token authentication, and that second token is really the way that the client authenticates the server: when you install your banking application, you're really installing the keys you need to authenticate the server and for the server to authenticate you. There's a fundamental problem that you can't make someone else do authentication if they don't want to, and that's exactly the situation clients are in. Right, but you can train users to expect authentication of the server. One way to do that is to require them to use an intrusive enough system that they end up learning what to look for in a phish attack. That said, I tend to agree with you: if we had dnssec everywhere today, it's totally unclear to me what client applications would do in the event they got a bogus resolution. A ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Spoofing as the postmaster
Andrew Sullivan wrote: On Fri, Dec 28, 2007 at 07:48:22AM -0800, Trevor Talbot wrote: I don't follow. What are banks doing on the web now to force clients to authenticate them, and how is it any different from the model of training users to check the SSL certificate? Some banks (mostly Swiss and German, from what I've seen) are requiring two-token authentication, and that second token is really the way that the client authenticates the server: when you install your banking application, you're really installing the keys you need to authenticate the server and for the server to authenticate you. I have done this for my own application before. Although the client and server use standard TLS 1.0 to speak to each other with a required authentication of RSA 1024-bit and a required encryption of AES 128-bit, it still requires that passwords sent from the client to the server are RSA encrypted using the server public certificate, making it impossible for anybody except for the legitimate server to see the password. One benefit of this is that the password itself can be '\0'd out as soon as we have RSA encrypted it, and things like a core dump of the client have a lower chance of including the password in plain text. In my case, the reason I did it is because I was trying to navigate around the US export control regulations that prevent greater than 1024 bit assymetric or 128 bit symmetric from leaving the US. I was able to use the standard Java SSL and crypto libraries to achieve greater than 128 bit symmetric encryption by combining the two. Now, my implementation isn't perfect with regard to Andrew's comments, as I encrypt using the server's public certificate after authenticating it. Technically, however, I could actually have two server certificates - one to use for authentication, and one to use for encryption. I believe this is becoming common in some circles, and you will find that gpg uses DSA keys for authentication, and signs the RSA keys used for encryption with the DSA key. The DSA key can be more bits, or have a longer life time. At what point does prudence become paranoia? I don't know. In my case, I felt 128-bit encryption was insufficient for protecting the passwords in my application. 256-bit encryption would have been sufficient, but that cannot yet be safely exported from the US to the countries I required. Cheers, mark -- Mark Mielke [EMAIL PROTECTED]
Re: [HACKERS] Spoofing as the postmaster
Andrew Sullivan wrote: On Fri, Dec 28, 2007 at 07:48:22AM -0800, Trevor Talbot wrote: I don't follow. What are banks doing on the web now to force clients to authenticate them, and how is it any different from the model of training users to check the SSL certificate? Some banks (mostly Swiss and German, from what I've seen) are requiring two-token authentication, and that second token is really the way that the client authenticates the server: when you install your banking application, you're really installing the keys you need to authenticate the server and for the server to authenticate you. Most actually secure banks would be using standalone tokens, and not something that runs on your local machine and can easily be compromised. There needs to be air between the token and the computer. The exact difference in security is always debatable, but air gap tokens is what's been used for most banks here for many years - in many cases since they first started doing internet banking 10+ years ago. But. That's for authenticating the *client*. Authenticating the server in the end requires you to trust the security of the client machine, and requiring special applications for that just makes it worse :-( And in the end, the only thing they really do is implement the browser the way it should've been implemented in the first place. The bottom line is still that the security against that has to happen on the client side. We could make it so that we *require* the root certificate to be present on the client and make the check, and simply refuse to connect without it. But my guess is that it'll just increase the bar for SSL adoption at all, whilst most people will find some insecure way to get the root key over there anyway. Unless we want to start shipping our own batch of trusted roots, and only support paid-for certificates or something... There's a fundamental problem that you can't make someone else do authentication if they don't want to, and that's exactly the situation clients are in. Right, but you can train users to expect authentication of the server. One way to do that is to require them to use an intrusive enough system that they end up learning what to look for in a phish attack. That said, I tend to agree with you: if we had dnssec everywhere today, it's totally unclear to me what client applications would do in the event they got a bogus resolution. Well, we all know how well the big warning boxes in the web browsers work... You can't really trust the user to make such a decision, in the end. You can get to a point, but not all the way by far. But what you can do is that as an administrator, you can require these checks. If you only allow connections from machines that are trusted, and you make sure those are configured to require verification of the server cert, then you're safe. //Magnus ---(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
Mark Mielke wrote: Andrew Sullivan wrote: On Fri, Dec 28, 2007 at 07:48:22AM -0800, Trevor Talbot wrote: I don't follow. What are banks doing on the web now to force clients to authenticate them, and how is it any different from the model of training users to check the SSL certificate? Some banks (mostly Swiss and German, from what I've seen) are requiring two-token authentication, and that second token is really the way that the client authenticates the server: when you install your banking application, you're really installing the keys you need to authenticate the server and for the server to authenticate you. I have done this for my own application before. Although the client and server use standard TLS 1.0 to speak to each other with a required authentication of RSA 1024-bit and a required encryption of AES 128-bit, it still requires that passwords sent from the client to the server are RSA encrypted using the server public certificate, making it impossible for anybody except for the legitimate server to see the password. One benefit of this is that the password itself can be '\0'd out as soon as we have RSA encrypted it, and things like a core dump of the client have a lower chance of including the password in plain text. Why are you even using a password in this case, and not just key-based auth? Wouldn't that be even easier and more secure? At what point does prudence become paranoia? I don't know. In my case, I felt 128-bit encryption was insufficient for protecting the passwords in my application. 256-bit encryption would have been sufficient, but that cannot yet be safely exported from the US to the countries I required. How do you protect the certificate store on the client? Or the binary that ends up prompting for the password on the client? //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Spoofing as the postmaster
Magnus Hagander wrote: Mark Mielke wrote: I have done this for my own application before. Although the client and server use standard TLS 1.0 to speak to each other with a required authentication of RSA 1024-bit and a required encryption of AES 128-bit, it still requires that passwords sent from the client to the server are RSA encrypted using the server public certificate, making it impossible for anybody except for the legitimate server to see the password. One benefit of this is that the password itself can be '\0'd out as soon as we have RSA encrypted it, and things like a core dump of the client have a lower chance of including the password in plain text. Why are you even using a password in this case, and not just key-based auth? Wouldn't that be even easier and more secure? Users of this product don't have keys - they have passwords. The username/password is for per-user authentication. The username defines the access level. Many users will use the same client. The client does have its own private RSA key and public certificate, however, this grants entry to the system. Password login is still required by the users of the client. At what point does prudence become paranoia? I don't know. In my case, I felt 128-bit encryption was insufficient for protecting the passwords in my application. 256-bit encryption would have been sufficient, but that cannot yet be safely exported from the US to the countries I required. How do you protect the certificate store on the client? Or the binary that ends up prompting for the password on the client The certificate on the client grants access to the system. It does not grant access to the resources on the system. Two-level authentication with mandatory server authentication. You see similar things in physical security instances. A security badge lets you in the door - but you still need to login to the computer once you get in. As for protecting the binary that prompts for a password on the client - I didn't bother with this, although Java does allow for signed jar files that would allow the user to be assured that the client is legitimate. There are always loops though, just because the client is legitimate doesn't mean that the keyboard is, and so on. You end up putting in enough effort to mitigate the risk. The risk always exists, but through clever, cryptographic, or obfuscatory measures, the risk can be greatly reduced. Cheers, mark -- Mark Mielke [EMAIL PROTECTED]
Re: [HACKERS] Spoofing as the postmaster
Magnus Hagander wrote: We could make it so that we *require* the root certificate to be present on the client and make the check, and simply refuse to connect without it. But my guess is that it'll just increase the bar for SSL adoption at all, whilst most people will find some insecure way to get the root key over there anyway. Unless we want to start shipping our own batch of trusted roots, and only support paid-for certificates or something... Agreed. Requiring client root certificate checking is heavy-handed. At most we could emit a server log message when a client has no certificate. Of course I am not sure anyone knows how to get that information from SSL. We could do it in the clients we ship but a malicious client will just remove the check. -- 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
Bruce Momjian [EMAIL PROTECTED] writes: Agreed. Requiring client root certificate checking is heavy-handed. There seems to be some confusion here. I didn't think anyone was proposing that we force every installation to require client root certificate checking. What was under discussion (I thought) was providing the ability for a DBA to *choose* to require it. Of course I am not sure anyone knows how to get that information from SSL. Yeah, if OpenSSL doesn't support testing for this then the discussion is moot... 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: Bruce Momjian [EMAIL PROTECTED] writes: Agreed. Requiring client root certificate checking is heavy-handed. There seems to be some confusion here. I didn't think anyone was proposing that we force every installation to require client root certificate checking. What was under discussion (I thought) was providing the ability for a DBA to *choose* to require it. Oh, yea, that would be OK. I am a little worried that the extra configuration required to turn this on/off might be added complexity for little gain. It might be simpler to allow the administrator to control whether non-checking clients are logged, rather than refusing the connection. I think this makes it clearer the root client check is to make sure all your clients are doing it right, rather than an actual security enhancement (if that makes sense). Of course I am not sure anyone knows how to get that information from SSL. Yeah, if OpenSSL doesn't support testing for this then the discussion is moot... Yea. -- 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 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Spoofing as the postmaster
Tomasz Ostrowski wrote: 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. Good point. I have added the last two sentences to the documentation paragraph to highlight this issue: productnameOpenSSL/productname supports a wide range of ciphers and authentication algorithms, of varying strength. While a list of ciphers can be specified in the productnameOpenSSL/productname configuration file, you can specify ciphers specifically for use by the database server by modifying xref linkend=guc-ssl-ciphers in filenamepostgresql.conf/. It is possible to have authentication without the overhead of encryption by using literalNULL-SHA/ or literalNULL-MD5/ ciphers. However, a man-in-the-middle could read and pass communications between client and server. -- 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
Bruce Momjian wrote: Good point. I have added the last two sentences to the documentation paragraph to highlight this issue: productnameOpenSSL/productname supports a wide range of ciphers and authentication algorithms, of varying strength. While a list of ciphers can be specified in the productnameOpenSSL/productname configuration file, you can specify ciphers specifically for use by the database server by modifying xref linkend=guc-ssl-ciphers in filenamepostgresql.conf/. It is possible to have authentication without the overhead of encryption by using literalNULL-SHA/ or literalNULL-MD5/ ciphers. However, a man-in-the-middle could read and pass communications between client and server. A fact that the above misses, is that symmetric key encryption is actually quite cheap. It is asymmetric key encryption that is expensive. If you look up information on SSL accelerators, you will find claims that the initial SSL authentication negotiation is 1000X as expensive as the actual data encryption for a running session, and that SSL web services are usually limited by their ability to negotiate NEW sessions. In other words, as well intentioned and accurate as the claim you make above, it may be irrelevant in many real world scenarios. If you are going to go through all the expensive processing of having authentication enabled, you may as well have encryption enabled too. Cheers, mark -- Mark Mielke [EMAIL PROTECTED] ---(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: Bruce Momjian [EMAIL PROTECTED] writes: Agreed. Requiring client root certificate checking is heavy-handed. There seems to be some confusion here. I didn't think anyone was proposing that we force every installation to require client root certificate checking. What was under discussion (I thought) was providing the ability for a DBA to *choose* to require it. Of course I am not sure anyone knows how to get that information from SSL. Yeah, if OpenSSL doesn't support testing for this then the discussion is moot.. I believe SSL is only capable of letting you know whether authentication for each end point was 1) not requested, 2) optional requested, or 3) required. Note that even if the authentication is required, there is no way to know how authentication was performed. For example, did it check the signature chain, requiring it to map to a public root certificate lists used by most web browsers? If so, did it check the contents of the certificate, or is only checking that it exists? Did it check a local key store that has a copy of the public key certificate? Or did it just log the certificate subject? OpenSSH, for instance, presents the user with the finger print of the certificate and asks you: $ ssh 192.168.0.1 The authenticity of host '192.168.0.1 (192.168.0.1)' can't be established. RSA key fingerprint is 3e:a7:0f:04:60:7e:8e:64:52:bf:81:92:a9:05:c7:36. Are you sure you want to continue connecting (yes/no)? While this certainly gives you the opportunity to challenge it, I don't know of any person who actually checks this finger print. Luckily, it stores it to ~/.ssh/known_hosts, and so the real issue is if it suddenly changes, you get a warning. Still, I've seen the warning before, and realized that oh yes, that machine was upgraded, so it probably has a new public key. I have never personally checked the finger print against a known source. Authentication is only as strong as the person or process confirming it. In the case of trying to force a client to authenticate the server, this requires the client to know who the server is. As most clients will not know who the server is, I see clients implementing an OpenSSH-style authentication model (shown above), or providing their own no-op authentication routine to OpenSSL. I don't think it is worth it, and I don't think it would work. Cheers, mark -- Mark Mielke [EMAIL PROTECTED]
Re: [HACKERS] Spoofing as the postmaster
Mark Mielke wrote: Bruce Momjian wrote: Good point. I have added the last two sentences to the documentation paragraph to highlight this issue: productnameOpenSSL/productname supports a wide range of ciphers and authentication algorithms, of varying strength. While a list of ciphers can be specified in the productnameOpenSSL/productname configuration file, you can specify ciphers specifically for use by the database server by modifying xref linkend=guc-ssl-ciphers in filenamepostgresql.conf/. It is possible to have authentication without the overhead of encryption by using literalNULL-SHA/ or literalNULL-MD5/ ciphers. However, a man-in-the-middle could read and pass communications between client and server. A fact that the above misses, is that symmetric key encryption is actually quite cheap. It is asymmetric key encryption that is expensive. If you look up information on SSL accelerators, you will find claims that the initial SSL authentication negotiation is 1000X as expensive as the actual data encryption for a running session, and that SSL web services are usually limited by their ability to negotiate NEW sessions. In other words, as well intentioned and accurate as the claim you make above, it may be irrelevant in many real world scenarios. If you are going to go through all the expensive processing of having authentication enabled, you may as well have encryption enabled too. OK, updated paragraph: It is possible to have authentication without encryption overhead by using literalNULL-SHA/ or literalNULL-MD5/ ciphers. However, a man-in-the-middle could read and pass communications between client and server. Also, encryption overhead is minimal compared to the overhead of authentication. For these reasons NULL ciphers are not recommended. -- 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 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Spoofing as the postmaster
Bruce Momjian wrote: OK, updated paragraph: It is possible to have authentication without encryption overhead by using literalNULL-SHA/ or literalNULL-MD5/ ciphers. However, a man-in-the-middle could read and pass communications between client and server. Also, encryption overhead is minimal compared to the overhead of authentication. For these reasons NULL ciphers are not recommended. Looks good! Cheers, mark -- Mark Mielke [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Spoofing as the postmaster
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. 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
On Mon, Dec 24, 2007 at 12:04:16AM +0100, Tomasz Ostrowski wrote: 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. If you think that is complete protection against privilege escalation, I encourage you to read some more bugtraq archives. The answer to MITM attacks is not superuser-reserved ports anyway. The privileged port idea was a bad one in retrospect. The answer is strong authentication. A ---(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 09:52:14PM +0100, Magnus Hagander wrote: 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. The problem with that approach is that, in the computer security world, taking that approach is increasingly regarded as negligent. And pointing out that others are similarly negligent is not a response. Note that I am explicitly not subscribing to or disagreeing with that view. A ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Spoofing as the postmaster
On Sun, Dec 23, 2007 at 01:45:14AM -0500, Tom Lane wrote: The primary reason things work like that is that there are boatloads of machines that are marginally misconfigured. For instance, userland thinks there is IPv6 support when the kernel thinks not (or vice versa). Not only marginally misconfigured, but broken as shipped, in the case of some OSes. And in those cases, you can't even fix it. A ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Spoofing as the postmaster
Andrew Sullivan wrote: On Sun, Dec 23, 2007 at 09:52:14PM +0100, Magnus Hagander wrote: 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. The problem with that approach is that, in the computer security world, taking that approach is increasingly regarded as negligent. And pointing out that others are similarly negligent is not a response. Sure. But we *do* provide a way to work around it *if you have to*: use SSL with trusted certificates. In the large number of cases where you *don't* need to worry about it, there's no need to add any extra overhead. And if you're going with SSL already, the extra overhead of TCP vs Unix sockets shouldn't matter *at all*... So I don't really see a motivation for us to support SSL over Unix sockets, if it adds any complexity to the code. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Spoofing as the postmaster
Mark Mielke wrote: 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. I think that was one of the original reasons the Unix sockets code was added at all. 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, Probably not very, but you should be able to achieve the same thing by moving the socket to a protected directory, I think? 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? AFAIK, it's secure if the host that it's running on can be considered secure. It's not secure over the internet, because by definition wherever the client runs is not under your control. But if you fully control the machine that the client runs on, AFAIK, ident should be secure. //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
Tomasz Ostrowski wrote: On Sun, 23 Dec 2007, Tom Lane wrote: 3. Massive confusion and breakage as various people transition to the new standard at different times. As with any major version. No, it would introduce a client/server incompatibility. Generally, older clients (libpq) will still work fine with newer servers, or the other way around. Lots of attention is paid to maintaining that. 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. It would be a perfect spot to put in the MITM attack that this whole thread has been about... 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. There is no such thing as a secure LAN, unless you control every host and what every user can do on it. (Definition of LAN can be a bit different though. Say you implement proper IPsec isolation on it - in that case, only the machines on the inside of the ipsec cloud need to be trusted) Same thing really does go for the host - it's not a secure host if you can't control what the users are doing on it. So you can't treat it as such if that's the case. //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Spoofing as the postmaster
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Sure. But we *do* provide a way to work around it *if you have to*: use SSL with trusted certificates. In the large number of cases where you *don't* need to worry about it, there's no need to add any extra overhead. And if you're going with SSL already, the extra overhead of TCP vs Unix sockets shouldn't matter *at all*... So I don't really see a motivation for us to support SSL over Unix sockets, if it adds any complexity to the code. Well, the problem with the current behavior is that the client app can require SSL, but the request is silently ignored if the connection is over Unix socket. So you might think you're secure when you aren't. I think that the reason we don't support SSL over Unix socket is mainly that we thought it was useless; but this discussion has exposed reasons to use it. So I'm for just eliminating the asymmetry. I have no problem with that. But it does seem to me that we are going about this all wrong. The OP proposed a solution which was intended to ensure at the server end that an untrusted user could not spoof the postmaster if the postmaster were not running. Putting the onus of this on clients seems wrong. I don't have any experience with SELinux, but my impression is that it can be used to control who or what can open files, sockets etc. On Linux at least this strikes me as a more productive approach to the original problem, as it would put the solution in the SA's hands. Maybe other Unices and Windows have similar capabilities? cheers andrew ---(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 [EMAIL PROTECTED] writes: Sure. But we *do* provide a way to work around it *if you have to*: use SSL with trusted certificates. In the large number of cases where you *don't* need to worry about it, there's no need to add any extra overhead. And if you're going with SSL already, the extra overhead of TCP vs Unix sockets shouldn't matter *at all*... So I don't really see a motivation for us to support SSL over Unix sockets, if it adds any complexity to the code. Well, the problem with the current behavior is that the client app can require SSL, but the request is silently ignored if the connection is over Unix socket. So you might think you're secure when you aren't. I think that the reason we don't support SSL over Unix socket is mainly that we thought it was useless; but this discussion has exposed reasons to use it. So I'm for just eliminating the asymmetry. 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
Magnus Hagander wrote: 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, Probably not very, but you should be able to achieve the same thing by moving the socket to a protected directory, I think? What you are ulimately interested in is who runs a given server. Making the inference that if the socket is in a directory that is currently only writable by a certain user implies that the user owns the server that offers that socket doesn't sound like a given to me. And let's forget that it's not really straightforward to find out who has write access to some directory. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Spoofing as the postmaster
* Tom Lane ([EMAIL PROTECTED]) wrote: Most Linux distros don't have SELinux, AFAIK, so this is probably not a very useful suggestion. Not that I have a problem with Red-Hat-specific solutions ;-) Debian also has SELinux, if one wishes to configure it. I suspect other Debian-derived distributions also have it as a result. It can certainly be a pain to configure but it's far from impossible and if an SA has concerns such as those described, well, I'd be kind of suprised if they weren't considering SELinux (if they're on Linux anyway). ... but since one of the arguments being made against move-the-socket is that it introduces a lot of platform-specific assumptions, we have to apply that same criterion to alternative answers. I don't quite follow how one argues 'against' SELinux in this context as I don't believe upstream changes would be required here. Just a policy configuration whereby only the postgres user can listen on port 5432. As far as ensuring security from the server end, what about extending the pg_hba.conf options to require that the server has both checked a client certificate and presented its own certificate? (I'm not sure whether OpenSSL provides a way to determine that, though.) It'd be really nice to be able to have client-side certificates used for authentication by having a way to associate a certificate (or maybe at least the DN, but you can have dups) to a user. That's a seperate conversation tho, really. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Spoofing as the postmaster
Andrew Dunstan [EMAIL PROTECTED] writes: I have no problem with that. But it does seem to me that we are going about this all wrong. The OP proposed a solution which was intended to ensure at the server end that an untrusted user could not spoof the postmaster if the postmaster were not running. Putting the onus of this on clients seems wrong. I don't have any experience with SELinux, but my impression is that it can be used to control who or what can open files, sockets etc. On Linux at least this strikes me as a more productive approach to the original problem, as it would put the solution in the SA's hands. Maybe other Unices and Windows have similar capabilities? Most Linux distros don't have SELinux, AFAIK, so this is probably not a very useful suggestion. Not that I have a problem with Red-Hat-specific solutions ;-) ... but since one of the arguments being made against move-the-socket is that it introduces a lot of platform-specific assumptions, we have to apply that same criterion to alternative answers. As far as ensuring security from the server end, what about extending the pg_hba.conf options to require that the server has both checked a client certificate and presented its own certificate? (I'm not sure whether OpenSSL provides a way to determine that, though.) regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Spoofing as the postmaster
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I have no problem with that. But it does seem to me that we are going about this all wrong. The OP proposed a solution which was intended to ensure at the server end that an untrusted user could not spoof the postmaster if the postmaster were not running. Putting the onus of this on clients seems wrong. I don't have any experience with SELinux, but my impression is that it can be used to control who or what can open files, sockets etc. On Linux at least this strikes me as a more productive approach to the original problem, as it would put the solution in the SA's hands. Maybe other Unices and Windows have similar capabilities? Most Linux distros don't have SELinux, AFAIK, so this is probably not a very useful suggestion. Not that I have a problem with Red-Hat-specific solutions ;-) ... but since one of the arguments being made against move-the-socket is that it introduces a lot of platform-specific assumptions, we have to apply that same criterion to alternative answers. As far as ensuring security from the server end, what about extending the pg_hba.conf options to require that the server has both checked a client certificate and presented its own certificate? (I'm not sure whether OpenSSL provides a way to determine that, though.) A server has *always* presented its certificate. SSL doesn't work otherwise. What we can't know is if the client *verified* the certificate. But there's no way to control that from server-side anyway... And we do request the client certificate if the server is provided with a root certificate store to verify it against... I'm not sure we gain a lot by adding a second option to do the same thing (which still will need said root certificate store to work) //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Spoofing as the postmaster
Stephen Frost wrote: It'd be really nice to be able to have client-side certificates used for authentication by having a way to associate a certificate (or maybe at least the DN, but you can have dups) to a user. That's a seperate conversation tho, really. Absolutely, but as you say a completely different thing. And FYI, it's on my list of things I'd like to work on for 8.4. Usual disclaimers about not actually ending up having time to do it applies, of course :-) //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 wrote: 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 I agree - I forgot there were different flavours. I think any of these are just as good as SSL with public key authentication, and perhaps a lot cheaper in terms of performance. The only piece of information missing is the uid to compare against, which may as well be provided in the db open parameters the same as any other parameters might be provided. Cheers, mark -- Mark Mielke [EMAIL PROTECTED]
Re: [HACKERS] Spoofing as the postmaster
Mike Rylander wrote: On Dec 22, 2007 1:04 PM, Tom Lane [EMAIL PROTECTED] wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Wouldn't SSL work over Unix-domain sockets as well? The API only deals with file descriptors. Hmm ... we've always thought of SSL as being primarily comm security and thus useless on a Unix socket, but the mutual authentication aspect could come in handy as an answer for this type of threat. Anyone want to try this and see if it really works or not? Does OpenSSL have a mode where it only does mutual auth and not encryption? The encryption would be wasted cycles in this scenario, so being able to turn it off would be nice. [EMAIL PROTECTED]:~$ openssl ciphers -v 'NULL' NULL-SHASSLv3 Kx=RSA Au=RSA Enc=None Mac=SHA1 NULL-MD5SSLv3 Kx=RSA Au=RSA Enc=None Mac=MD5 I see no way to turn off the message digest, but maybe that's just an added benefit. So if we set ssl_ciphers in postgresql.conf to: ssl_ciphers = 'NULL-SHA:NULL-MD5' then SSL does client and server machine authentication with no encryption overhead? -- 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 5: don't forget to increase your free space map settings
Re: [HACKERS] Spoofing as the postmaster
Tomasz Ostrowski wrote: 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. Agreed. This was the big surprise for me, and hence the new documentation section I wrote. I think based on this discussion that there is no way for us easily to to avoid vulnerabilities so documentation/education seems the most appropriate approach. -- 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 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Spoofing as the postmaster
Mark Mielke wrote: Gregory Stark wrote: 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 I agree - I forgot there were different flavours. I think any of these are just as good as SSL with public key authentication, and perhaps a lot cheaper in terms of performance. The only piece of information missing is the uid to compare against, which may as well be provided in the db open parameters the same as any other parameters might be provided. True, but if you are going to have the client check a uid we might as well just put the socket file in a secure directory and be done with it. -- 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 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Spoofing as the postmaster
Bruce Momjian wrote: Mark Mielke wrote: I agree - I forgot there were different flavours. I think any of these are just as good as SSL with public key authentication, and perhaps a lot cheaper in terms of performance. The only piece of information missing is the uid to compare against, which may as well be provided in the db open parameters the same as any other parameters might be provided. True, but if you are going to have the client check a uid we might as well just put the socket file in a secure directory and be done with it. That's a good point too... :-) Cheers, mark -- Mark Mielke [EMAIL PROTECTED]
Re: [HACKERS] Spoofing as the postmaster
Tom Lane wrote: 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. I have added the section about preventing server spoofing and updated the SSL documentation to be more logical and clearer about certificates. The major updated sections are: http://momjian.us/tmp/pgsql/preventing-server-spoofing.html http://momjian.us/tmp/pgsql/ssl-tcp.html http://momjian.us/tmp/pgsql/libpq-ssl.html I have to say I didn't understand the certificate stuff before, but I think it should be clearer now to anyone who reads it. -- 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 6: explain analyze is your friend
Re: [HACKERS] Spoofing as the postmaster
Bruce Momjian wrote: Tom Lane wrote: 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. I have added the section about preventing server spoofing and updated the SSL documentation to be more logical and clearer about certificates. The major updated sections are: http://momjian.us/tmp/pgsql/preventing-server-spoofing.html http://momjian.us/tmp/pgsql/ssl-tcp.html http://momjian.us/tmp/pgsql/libpq-ssl.html I have to say I didn't understand the certificate stuff before, but I think it should be clearer now to anyone who reads it. I have just added two documentation tables outlining SSL file usage for client and server. -- 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 4: Have you searched our list archives? http://archives.postgresql.org
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
[HACKERS] Spoofing as the postmaster
A few months ago a security concern was sent to core. We have discussed it but see little we can do to address it in the code so I am posting to hackers in case there is something we didn't think of or if documentation additions are necessary. Most users understand that if they are connecting to the postmaster over an insecure network that it is possible for a middle-man to intercept passwords, queries, and results. SSL certificates are designed to avoid this problem. The new attack vector reported involves a local user on the same machine as the postmaster. When the postmaster is running it has bound port 5432 and created the unix-domain socket file in /tmp. The new attack involves cases where the postmaster is stopped. The attacker can bind to TCP port 5432 or create a socket file in /tmp and get passwords and queries. PGDATA is secure so results cannot be returned while the postmaster is down. They can also prevent the real server from starting. It is possible for the attacker to use one of the interfaces (tcp or unix domain) and wait for the postmaster to start. The postmaster will fail to start on the interface in use but will start on the other interface and the attacker could route queries to the active postmaster interface. So, what solutions exist? We could require the use of port numbers less than 1024 which typically require root and then become a non-root user, but that requires root to start the server. We could put the unix domain socket file in a secure directory (but where?) but the client has to know that location. An interesting idea would be for the unix domain client to check that the ownership of the socket file is the same as PGDATA, but clients typically don't know PGDATA, nor do they know who should be running the postmaster. I suppose we could create a poor-man's SSL for unix domain sockets that just checks the ownership of the socket file, but users can already do that by specifying the socket file in a directory that only has write permission for the postmaster user. Could we create some kind of lock mode that keeps these interfaces locked when the postmaster is down? Conclusion -- The fundamental problem is that because we don't require root, any user's postmaster or pretend postmaster is as legitimate as anyone else's. SSL certificates add legitimacy checks for TCP, but not for unix domain sockets. This is not a Postgres-specific problem. It is probably shared by any server that doesn't need root permissions, but our handling of passwords makes it a larger problem. 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? Remember, as long as your postmaster is running you are safe. It is only postmaster downtime that has this risk. -- 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 5: don't forget to increase your free space map settings
Re: [HACKERS] Spoofing as the postmaster
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. -- 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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Spoofing as the postmaster
Bruce Momjian wrote: The fundamental problem is that because we don't require root, any user's postmaster or pretend postmaster is as legitimate as anyone else's. SSL certificates add legitimacy checks for TCP, but not for unix domain sockets. Wouldn't SSL work over Unix-domain sockets as well? The API only deals with file descriptors. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Spoofing as the postmaster
Peter Eisentraut wrote: Bruce Momjian wrote: The fundamental problem is that because we don't require root, any user's postmaster or pretend postmaster is as legitimate as anyone else's. SSL certificates add legitimacy checks for TCP, but not for unix domain sockets. Wouldn't SSL work over Unix-domain sockets as well? The API only deals with file descriptors. But we don't check the SSL cert's credentials in the client, AFAIK. That means that postmaster spoofer could just as easily spoof SSL. Communications between the client and the endpoint will be protected, but there is no protection from a man in the middle attack, which is what this is. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
