Re: BUG #16079: Question Regarding the BUG #16064
От | Thomas Munro |
---|---|
Тема | Re: BUG #16079: Question Regarding the BUG #16064 |
Дата | |
Msg-id | CA+hUKGJw4Ax25=fcCA+DQD=82v2pKu9VGmkYZO8HeH7+-P2Cxw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #16079: Question Regarding the BUG #16064 (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: BUG #16079: Question Regarding the BUG #16064
Re: BUG #16079: Question Regarding the BUG #16064 |
Список | pgsql-bugs |
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)
В списке pgsql-bugs по дате отправления: