Обсуждение: BUG #16079: Question Regarding the BUG #16064
The following bug has been logged on the website: Bug reference: 16079 Logged by: Yudhveer Kandukuri Email address: k.yudhveer@gmail.com PostgreSQL version: 10.10 Operating system: UBUNTU Description: As your team mentioned that LDAP process is not secured compared to the GSSAPI authentication. Can you clarify me this question, whenever the client provide his credentials to connect to the PostgreSQL server it will authenticated against the LDAP Server and then LDAP will direct the client connecttion to the Postgrers server. But the user credentials will not be sent to Postgresql server to authenticate. Because your team mentioned this statement " it's much more secure than using LDAP-based auth and avoids the user's password being sent to the PostgreSQL server (where it could be compromised if the PGprocess is compromised)." I am having user defined in the LDAP server with all the credentails and also same user in the postgres server.
Greetings, * PG Bug reporting form (noreply@postgresql.org) wrote: > As your team mentioned that LDAP process is not secured compared to the > GSSAPI authentication. No, it isn't. > Can you clarify me this question, whenever the client provide his > credentials to connect to the PostgreSQL server it will authenticated > against the LDAP Server and then LDAP will direct the client connecttion to > the Postgrers server. But the user credentials will not be sent to > Postgresql server to authenticate. Uh, the user's credentials certainly are sent to the PG server. Here's a nice short patch that just prints out the user's password after the server gets it when using LDAP auth. You'll see the results like this in the log: users password is: hello > Because your team mentioned this statement " it's much more secure than > using LDAP-based auth and avoids the user's password being > sent to the PostgreSQL server (where it could be compromised if the > PGprocess is compromised)." Yes, that's correct, if the PG server is compromised then the user's credentials, when using LDAP auth, can be captured. > I am having user defined in the LDAP server with all the credentails and > also same user in the postgres server. I'm not sure what you're suggesting here, but the way LDAP auth in PG works is that the user's password is sent to the PG server and then the PG server turns around and tries to use it to authenticate to the LDAP server and, if successful, the authentication is allowed, and if unsuccessful, the authentication is denied. When using LDAP auth, we don't look at the rolpassword column in pg_authid at all. I do think it'd be a useful improvement to add a way to control who is allowed to access a PG server (aka- authorization), perhaps through an LDAP query to check it, while using Kerberos/GSSAPI authentication to actually do the authentication, but there isn't a way to do that with PG today. Thanks, Stephen
Вложения
On Tue, Oct 29, 2019 at 4:48 AM Stephen Frost <sfrost@snowman.net> wrote: > Uh, the user's credentials certainly are sent to the PG server. Perhaps we should log a warning when PostgreSQL has received a password over the network without SSL. Perhaps we should log another warning when PostgreSQL has sent a password over the network without SSL. > users password is: hello The fact that you can steal the password from PostgreSQL's memory seems like a next level problem to me, but the fact that it's easy to configure PostgreSQL in a way that sends cleartext passwords over the network a couple of times seems to be a bigger problem to me. Here's a demonstration. I run make -C src/test/ldap check, just to get a working slapd setup, and then I start it like so: /usr/local/libexec/slapd -f slapd.conf -h ldap://localhost:8888 I put this into my pg_hba.conf: host postgres test1 127.0.0.1/32 ldap ldapurl="ldap://localhost:8888/dc=example,dc=net?uid?sub" I trace my postmaster + children with truss -p PID -s 1024 -f, and then I try to log in with psql -h localhost -p 8888 postgres test1, and give the password "foobar". Here is my password, which travelled over the network in cleartext twice (into PostgreSQL, and then out to slapd): 38412: accept(6,{ AF_INET 127.0.0.1:12891 },0x801d07118) = 9 (0x9) ... 38412: fork() = 38459 (0x963b) ... 38459: recvfrom(9,"p\0\0\0\vfoobar\0",8192,0,NULL,0x0) = 12 (0xc) ... 38459: connect(4,{ AF_INET 127.0.0.1:8888 },16) = 0 (0x0) 38459: write(4,"0-\^B\^A\^A`(\^B\^A\^C\^D\^[uid=test1,dc=example,dc=net\M^@\^Ffoobar",47) = 47 (0x2f)
On Fri, Nov 15, 2019 at 5:42 AM Thomas Munro <thomas.munro@gmail.com> wrote:
On Tue, Oct 29, 2019 at 4:48 AM Stephen Frost <sfrost@snowman.net> wrote:
> Uh, the user's credentials certainly are sent to the PG server.
Perhaps we should log a warning when PostgreSQL has received a
password over the network without SSL. Perhaps we should log another
warning when PostgreSQL has sent a password over the network without
SSL.
For the old plaintext "password" method, we log a warning when we parse the configuration file.
Maybe we should do the same for LDAP (and RADIUS)? This seems like a better place to put it than to log it at every time it's received?
Greetings, * Thomas Munro (thomas.munro@gmail.com) wrote: > On Tue, Oct 29, 2019 at 4:48 AM Stephen Frost <sfrost@snowman.net> wrote: > > Uh, the user's credentials certainly are sent to the PG server. > > Perhaps we should log a warning when PostgreSQL has received a > password over the network without SSL. Perhaps we should log another > warning when PostgreSQL has sent a password over the network without > SSL. I like the idea of having these warnings, I don't like the idea of limiting it to when SSL is or isn't being used. > > users password is: hello > > The fact that you can steal the password from PostgreSQL's memory > seems like a next level problem to me, but the fact that it's easy to > configure PostgreSQL in a way that sends cleartext passwords over the > network a couple of times seems to be a bigger problem to me. Both are issues and clearly users are confused when they use an enterprise authentication system (eg: Active Directory) and configure PG to use it ("ldap") and expect us to do things intelligently like other similar products do (SQL Server). Is it our fault that they don't realize that they aren't configuring PG properly in an AD environment when they use the LDAP auth method? Maybe not *technically*, but we sure don't make it very clear that the LDAP auth method is *not* the same as what they get with something like a SQL Server instance and that it's an poor way of doing authentication when you're in an Active Directory environment. > Here's a demonstration. I run make -C src/test/ldap check, just to > get a working slapd setup, and then I start it like so: > > /usr/local/libexec/slapd -f slapd.conf -h ldap://localhost:8888 > > I put this into my pg_hba.conf: > > host postgres test1 127.0.0.1/32 ldap > ldapurl="ldap://localhost:8888/dc=example,dc=net?uid?sub" > > I trace my postmaster + children with truss -p PID -s 1024 -f, and > then I try to log in with psql -h localhost -p 8888 postgres test1, > and give the password "foobar". Here is my password, which travelled > over the network in cleartext twice (into PostgreSQL, and then out to > slapd): > > 38412: accept(6,{ AF_INET 127.0.0.1:12891 },0x801d07118) = 9 (0x9) > ... > 38412: fork() = 38459 (0x963b) > ... > 38459: recvfrom(9,"p\0\0\0\vfoobar\0",8192,0,NULL,0x0) = 12 (0xc) > ... > 38459: connect(4,{ AF_INET 127.0.0.1:8888 },16) = 0 (0x0) > 38459: write(4,"0-\^B\^A\^A`(\^B\^A\^C\^D\^[uid=test1,dc=example,dc=net\M^@\^Ffoobar",47) > = 47 (0x2f) Yes, this is indeed also terrible, heh. Thanks, Stephen
Вложения
Greetings, * Magnus Hagander (magnus@hagander.net) wrote: > On Fri, Nov 15, 2019 at 5:42 AM Thomas Munro <thomas.munro@gmail.com> wrote: > > > On Tue, Oct 29, 2019 at 4:48 AM Stephen Frost <sfrost@snowman.net> wrote: > > > Uh, the user's credentials certainly are sent to the PG server. > > > > Perhaps we should log a warning when PostgreSQL has received a > > password over the network without SSL. Perhaps we should log another > > warning when PostgreSQL has sent a password over the network without > > SSL. > > For the old plaintext "password" method, we log a warning when we parse the > configuration file. > > Maybe we should do the same for LDAP (and RADIUS)? This seems like a better > place to put it than to log it at every time it's received? Seems like a reasonable approach to me though we should probably also include details in the documentation around what this warning means, exactly, since we probably can't write the full paragraph or more that we'd need to inside the warning itself. Sorry though.. where do we log that warning you're talking about wrt the 'password' method? I just started a 13devel with 'password' configured in pg_hba.conf and didn't see any warnings... (commit b5273943679d22f58f1e1e269ad75e791172f557) I'm all for adding a warning when any of these methods is used, maybe with an optional override of "yes, I know this is bad but I don't care". Thanks, Stephen
Вложения
Greetings, * Magnus Hagander (magnus@hagander.net) wrote: > On Fri, Nov 15, 2019 at 5:42 AM Thomas Munro <thomas.munro@gmail.com> wrote: > > On Tue, Oct 29, 2019 at 4:48 AM Stephen Frost <sfrost@snowman.net> wrote: > > > Uh, the user's credentials certainly are sent to the PG server. > > > > Perhaps we should log a warning when PostgreSQL has received a > > password over the network without SSL. Perhaps we should log another > > warning when PostgreSQL has sent a password over the network without > > SSL. > > For the old plaintext "password" method, we log a warning when we parse the > configuration file. > > Maybe we should do the same for LDAP (and RADIUS)? This seems like a better > place to put it than to log it at every time it's received? A dollar short and a year late, but ... +1. Thanks, Stephen