FW: [ppa-dev] Severe bug in debian - phppgadmin opens up databases for anyone!

This is a known problem. I just updated the documentation today to
stress that local users have full access to any database by default, and
that initdb -W and changing pg_hba.conf to password/md5 are the best
ways to fix this.

---------------------------------------------------------------------------

Hi guys,

This came across the phpPgAdmin list, and I'm reposting it here in case it
is actually true...? If it is, is it a Postgres or a Debian package issue?

Chris

-----Original Message-----
From: phppgadmin-devel-admin@lists.sourceforge.net
[mailto:phppgadmin-devel-admin@lists.sourceforge.net]On Behalf Of Guilherme
Barile
Sent: Wednesday, 28 November 2001 3:58 AM
To: phpPgAdmin-devel@lists.sourceforge.net
Subject: [ppa-dev] Severe bug in debian - phppgadmin opens up databases for
anyone!

Debian comes with a severe configuration fault in postgresql ... in
pg_hba.conf, it uses TRUST as the default authentication method (from
localhost) ... as phpPgAdmin runs on localhost, anyone can login without a
password.

There are DOZENS of sites out there running without any security! And this
is terrible! If I weren't a very nice person and simply didn't change
anything (I could, as postgres is superuser and I can log as it).
Here's how to fix it (on debian, don't know if any other distribution is
affected):
log in as postgres
run psql
check the pg_shadow table (SELECT * FROM pg_shadow;)
see if everyone has a password (especially user postgres)

After setting all the passwords, edit /etc/postgres/pg_hba.conf to match the
following lines:

local all password
host all 127.0.0.1 255.0.0.0 password

Then it will require a password.
Also, If you wish to block connections from the internet, add this also:

host all 0.0.0.0 0.0.0.0 reject

Please put this on the page or together with PhpPgAdmin's documentation.
(Search google.com with "phppgadmin local:5432" and check for yourself ...
login as postgres and type anything as password!)

Thank you very much for your attention (Please be kind and reply)

Guilherme Barile
Infoage Web Solutions
Sao Paulo - SP - Brazil

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

This came across the phpPgAdmin list, and I'm reposting it here in case it
is actually true...? If it is, is it a Postgres or a Debian package issue?

The default installation is indeed insecure with respect to other local
users; you don't want to use TRUST auth method on a multi-user box. We
need to document that more prominently. But the default install is not
insecure w.r.t. to outside connections, because it doesn't allow any.
In particular, this advice is horsepucky:

Also, If you wish to block connections from the internet, add this also:
host all 0.0.0.0 0.0.0.0 reject

because that will happen anyway.

regards, tom lane

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

This came across the phpPgAdmin list, and I'm reposting it here in case it
is actually true...? If it is, is it a Postgres or a Debian package issue?

The default installation is indeed insecure with respect to other local
users; you don't want to use TRUST auth method on a multi-user box. We
need to document that more prominently. But the default install is not
insecure w.r.t. to outside connections, because it doesn't allow any.
In particular, this advice is horsepucky:

Let me tell you what bothers me about our default install. If some
software installed all its data files in a world-writable directory, we
would consider it a security hole. But because we are Internet-enabled,
and because our insecurity is only local, it seems OK to people.

I am not sure about a solution, but I am shocked we haven't been beaten
up about this more often.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

... But because we are Internet-enabled,
and because our insecurity is only local, it seems OK to people.

It's not that it's "okay", it's that we haven't got any good
alternatives. Password auth sucks from a convenience point of view
(or even from a possibility point of view, for scripts; don't forget
the changes that you yourself recently applied to guarantee that a
script *cannot* supply a password to psql). Ident auth doesn't work,
or isn't secure, in a lot of cases. Kerberos, well, not a lot to
offer there either. What else do you want to make the default?

regards, tom lane

It's not that it's "okay", it's that we haven't got any good
alternatives. Password auth sucks from a convenience point of view
(or even from a possibility point of view, for scripts; don't forget
the changes that you yourself recently applied to guarantee that a
script *cannot* supply a password to psql). Ident auth doesn't work,
or isn't secure, in a lot of cases. Kerberos, well, not a lot to
offer there either. What else do you want to make the default?

Someone, somewhere, please help us. :-)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

At 01:08 AM 11/28/01 -0500, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

... But because we are Internet-enabled,
and because our insecurity is only local, it seems OK to people.

It's not that it's "okay", it's that we haven't got any good
alternatives. Password auth sucks from a convenience point of view
(or even from a possibility point of view, for scripts; don't forget
the changes that you yourself recently applied to guarantee that a
script *cannot* supply a password to psql). Ident auth doesn't work,

Ack. We can't send in passwords to psql anymore? :(

Is there a safe way to send username and password to psql?

Cheerio,
Link.

Lincoln Yeoh wrote:

At 01:08 AM 11/28/01 -0500, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

... But because we are Internet-enabled,
and because our insecurity is only local, it seems OK to people.

It's not that it's "okay", it's that we haven't got any good
alternatives. Password auth sucks from a convenience point of view
(or even from a possibility point of view, for scripts; don't forget
the changes that you yourself recently applied to guarantee that a
script *cannot* supply a password to psql). Ident auth doesn't work,

Ack. We can't send in passwords to psql anymore? :(

Is there a safe way to send username and password to psql?

smbclient does it via a file which must be 0600, but I don't know if
psql has anything like that.

-----------
Hannu

Lincoln Yeoh <lyeoh@pop.jaring.my> writes:

At 01:08 AM 11/28/01 -0500, Tom Lane wrote:

... Password auth sucks from a convenience point of view
(or even from a possibility point of view, for scripts; don't forget
the changes that you yourself recently applied to guarantee that a
script *cannot* supply a password to psql).

Ack. We can't send in passwords to psql anymore? :(

Well, Bruce, you were the one that was hot to make that /dev/tty change.
Time to defend it.

Is there a safe way to send username and password to psql?

If you want to put those things in a script, you could still do

export PGUSER=whatever
export PGPASSWORD=whatever
psql ...

This would actually work a lot better than other ways for cases such
as doing pg_dumpall, where you'd otherwise need to supply the password
multiple times.

regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

Is there a safe way to send username and password to psql?

If you want to put those things in a script, you could still do

export PGUSER=whatever
export PGPASSWORD=whatever
psql ...

But this way the password ends up in the environment, which on many
systems is visible to other processes/users (via /proc or the 'ps'
command). Might as well use "trust"...

-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863

Doug McNaught <doug@wireboard.com> writes:

But this way the password ends up in the environment, which on many
systems is visible to other processes/users (via /proc or the 'ps'
command).

Your *environment* is visible to other users? Geez, what a broken
system ...

regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

Doug McNaught <doug@wireboard.com> writes:

But this way the password ends up in the environment, which on many
systems is visible to other processes/users (via /proc or the 'ps'
command).

Your *environment* is visible to other users? Geez, what a broken
system ...

True on Solaris (/usr/ucb/ps -eax) at least. Other systems too I'm
pretty sure. I thought that Linux let you do it but I just checked
and /proc/<pid>/environ is mode 0400...

-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863

Doug McNaught <doug@wireboard.com> writes:

But this way the password ends up in the environment, which on many
systems is visible to other processes/users (via /proc or the 'ps'
command).

Your *environment* is visible to other users? Geez, what a broken
system ...

Try "ps axewww" ? Doesn't work on your platform ?
Works on AIX, Linux?, ...

Andreas

Zeugswetter Andreas SB SD wrote:

Doug McNaught <doug@wireboard.com> writes:

But this way the password ends up in the environment, which on many
systems is visible to other processes/users (via /proc or the 'ps'
command).

Your *environment* is visible to other users? Geez, what a broken
system ...

Try "ps axewww" ? Doesn't work on your platform ?
Works on AIX, Linux?, ...

Linux Debian Unstable (updated 1 week ago).

For a non-root user, only her processes' environment appears.
(and /proc/*/environ permissions are 400, the user being the process owner)

For root, all processes' environment is shown.

Antonio

At 01:08 AM 11/28/01 -0500, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

... But because we are Internet-enabled,
and because our insecurity is only local, it seems OK to people.

It's not that it's "okay", it's that we haven't got any good
alternatives. Password auth sucks from a convenience point of view
(or even from a possibility point of view, for scripts; don't forget
the changes that you yourself recently applied to guarantee that a
script *cannot* supply a password to psql). Ident auth doesn't work,

Ack. We can't send in passwords to psql anymore? :(

Is there a safe way to send username and password to psql?

The standard way I know of is to use 'expect' and wrap your psql call
around that.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Lincoln Yeoh <lyeoh@pop.jaring.my> writes:

At 01:08 AM 11/28/01 -0500, Tom Lane wrote:

... Password auth sucks from a convenience point of view
(or even from a possibility point of view, for scripts; don't forget
the changes that you yourself recently applied to guarantee that a
script *cannot* supply a password to psql).

Ack. We can't send in passwords to psql anymore? :(

Well, Bruce, you were the one that was hot to make that /dev/tty change.
Time to defend it.

Hey, if people want it back, it is easy to do.

My only goal was to make psql consistent with other applications that
require passwords.

Is there a safe way to send username and password to psql?

If you want to put those things in a script, you could still do

export PGUSER=whatever
export PGPASSWORD=whatever
psql ...

This would actually work a lot better than other ways for cases such
as doing pg_dumpall, where you'd otherwise need to supply the password
multiple times.

What about 'ps -e' that shows all environment variables? This is in
some ways worse than piping the password into psql. At least there was
some chance that they were using 'cat' from a file with the proper
permissions. WIth PGPASSWORD, there is no way to restrict who can see
it via 'ps -e'.

Seems we shouldn't allow PGPASSWORD either.

The idea of allowing the password to be stored in a file with 600
permissions seems quite standard. CVS does this.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Doug McNaught <doug@wireboard.com> writes:

But this way the password ends up in the environment, which on many
systems is visible to other processes/users (via /proc or the 'ps'
command).

Your *environment* is visible to other users? Geez, what a broken
system ...

Try "ps axewww" ? Doesn't work on your platform ?
Works on AIX, Linux?, ...

Works on BSD/OS too, so I assume it works on all the BSD's.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Is there a safe way to send username and password to psql?

The standard way I know of is to use 'expect' and wrap your psql call
around that.

Didn't you break that by making psql read the password from /dev/tty?
Or can 'expect' take control of /dev/tty?

regards, tom lane

Zeugswetter Andreas SB SD wrote:

Doug McNaught <doug@wireboard.com> writes:

But this way the password ends up in the environment, which on many
systems is visible to other processes/users (via /proc or the 'ps'
command).

Your *environment* is visible to other users? Geez, what a broken
system ...

Try "ps axewww" ? Doesn't work on your platform ?
Works on AIX, Linux?, ...

Linux Debian Unstable (updated 1 week ago).

For a non-root user, only her processes' environment appears.
(and /proc/*/environ permissions are 400, the user being the process owner)

For root, all processes' environment is shown.

On BSD/OS, it doesn't matter what user you are. You can see the
environment of all processes.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Is there a safe way to send username and password to psql?

The standard way I know of is to use 'expect' and wrap your psql call
around that.

Didn't you break that by making psql read the password from /dev/tty?
Or can 'expect' take control of /dev/tty?

Expect communicates with the process via pseudo-ttys, so it works fine.
Also, if it can't read /dev/tty, it will read from stdin. At least that
is that standard way to do it.

getpass() docs said:

The getpass() function displays a prompt to, and reads in a password
from, /dev/tty. If this file is not accessible, getpass displays the
prompt on the standard error output and reads from the standard input.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026