Thread: Re: initdb and "exit_nicely"
A suggestion: Have initdb do a tar and gzip of the prior contents of PG_DATA, and leave the result in the newly initialized PG_DATA under a standard name, e.g. $PG_DATA.old. Maybe also issue a warning/informative message so that the installer is reminded to go back and recover any files that are actually needed, or simply delete the .tar.gz file in order to recover the space. Subject: Re: initdb and "exit_nicely"... > Date: Thu, 18 May 2000 11:05:58 -0400 > From: Tom Lane <tgl@sss.pgh.pa.us> > To: "Len Morgan" <len-morgan@crcom.net> > CC: pgsql-general@hub.org > References: <002001bfc0be$fdbe7560$0908a8c0@H233.bstx.cc> > > "Len Morgan" <len-morgan@crcom.net> writes: > > The reason that IMHO this deserves a little consideration (i.e., doing it at > > all rather than just saying "Don't store any files in PG_DATA") is that > > RedHat based rpm installations create the postgres superuser account as part > > of the process and set the home directory for this user to PG_DATA. > > To be blunt, that's *incredibly* brain dead. The contents of the PGDATA > directory are way too critical to be the account's home directory. The > correct fix for this is to change the way the RPM sets up the account. > > I don't think we are doing anyone a service if we tweak initdb in a way > that will make it slightly safer to keep random files in PGDATA. You > shouldn't do it anyway, and modifying initdb to make it look like you > can will only increase the risk of people accidentally screwing up their > installation. > > regards, tom lane
I'm currently evaluating PostreSQL, but this posting regarding passwords
being stored in cleartext has me a bit concerned. I tried to find more
information regarding this issue, but with no luck. Could you please share
you thoughts on this.
-david
Date: Sun, 23 Apr 2000 22:02:45 +0200
From: Robert van der Meulen <rvdm@CISTRON.NL>
Subject: Postgresql cleartext password storage
To: BUGTRAQ@SECURITYFOCUS.COM
Hi,
While migrating some postgres databases to a different server (including
user accounts) i noticed the following problem in the way postgres stores
user passwords:
SmellyCat:/var/postgres/data# strings pg_shadow
someaccountname
someaccountpassword
anotheraccountname
anotheraccountpassword
SmellyCat:/var/postgres/data#
This means postgresql stores usernames and passwords, cleartext, in
pg_shadow.
pg_shadow (and the other administrative tables) are owned by user postgres,
and only readable by user postgres, although modifying them trough the pgsql
monitor is usually protected by a password.
The passwords being cleartext, and readable by user postgres (and root,
ofcourse), allows bypassing the password mechanism, and gives access to all
databases. (compromising user 'postgres' or reading the pg_shadow file gives
access to the usernames/passwords)
Ofcourse this came in handy for me, but i think it's not the way it should
be :)
I tested this on postgres versions 6.3.2 and 6.5.3 , others probably
experience this problem as well.
This message is mailed to bugtraq, and Cc'd to the postgresql developers.
Greets,
Robert van der Meulen/Emphyrio
--
| rvdm@cistron.nl - Cistron Internet Services - www.cistron.nl |
| php3/c/perl/html/c++/sed/awk/linux/sql/cgi/security |
| My statements are mine, and not necessarily cistron's. |
One of the nice things about MySql is a function that can encrypt
passwords for you. You end up with something like the password scheme in
unix where you can encrypt, but not decrypt, which is good enough for many
puposes. Once the password is encrypted, it could just be stored as a
plain text field.
There has to be some library which provides a function to encrypt
passwords. One would just have to write a wrapper for it to make that a
dynamically loaded function in Postgres. Then you could do something
like:
insert into my_password_table values ('idnum', 'Travis Bauer', encrypt('my
password);
That couldn't be too hard.
----------------------------------------------------------------
Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer
----------------------------------------------------------------
On Thu, 18 May 2000, David Duddleston wrote:
>
>
> I'm currently evaluating PostreSQL, but this posting regarding passwords
> being stored in cleartext has me a bit concerned. I tried to find more
> information regarding this issue, but with no luck. Could you please share
> you thoughts on this.
>
> -david
>
>
> Date: Sun, 23 Apr 2000 22:02:45 +0200
> From: Robert van der Meulen <rvdm@CISTRON.NL>
> Subject: Postgresql cleartext password storage
> To: BUGTRAQ@SECURITYFOCUS.COM
>
> Hi,
>
> While migrating some postgres databases to a different server (including
> user accounts) i noticed the following problem in the way postgres stores
> user passwords:
>
> SmellyCat:/var/postgres/data# strings pg_shadow
> someaccountname
> someaccountpassword
> anotheraccountname
> anotheraccountpassword
> SmellyCat:/var/postgres/data#
>
> This means postgresql stores usernames and passwords, cleartext, in
> pg_shadow.
> pg_shadow (and the other administrative tables) are owned by user postgres,
> and only readable by user postgres, although modifying them trough the pgsql
> monitor is usually protected by a password.
>
> The passwords being cleartext, and readable by user postgres (and root,
> ofcourse), allows bypassing the password mechanism, and gives access to all
> databases. (compromising user 'postgres' or reading the pg_shadow file gives
> access to the usernames/passwords)
>
> Ofcourse this came in handy for me, but i think it's not the way it should
> be :)
> I tested this on postgres versions 6.3.2 and 6.5.3 , others probably
> experience this problem as well.
>
> This message is mailed to bugtraq, and Cc'd to the postgresql developers.
>
> Greets,
> Robert van der Meulen/Emphyrio
>
> --
>
> | rvdm@cistron.nl - Cistron Internet Services - www.cistron.nl |
> | php3/c/perl/html/c++/sed/awk/linux/sql/cgi/security |
> | My statements are mine, and not necessarily cistron's. |
>
On Thu, May 18, 2000 at 11:17:10AM -0700, David Duddleston wrote: > I'm currently evaluating PostreSQL, but this posting regarding passwords > being stored in cleartext has me a bit concerned. I tried to find more > information regarding this issue, but with no luck. Could you please share > you thoughts on this. by default, the passwords are stored in clear text. however, if you are configuring passwords, then likely you are going to need to change settings in pg_hba.conf. in there you can specify "crypt", and the system will expect that the passwds in pg_shadow are encrypted. -- [ Jim Mercer jim@reptiles.org +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]
Jim Mercer <jim@reptiles.org> writes:
> On Thu, May 18, 2000 at 11:17:10AM -0700, David Duddleston wrote:
>> I'm currently evaluating PostreSQL, but this posting regarding passwords
>> being stored in cleartext has me a bit concerned. I tried to find more
>> information regarding this issue, but with no luck. Could you please share
>> you thoughts on this.
> by default, the passwords are stored in clear text.
> however, if you are configuring passwords, then likely you are going to need
> to change settings in pg_hba.conf.
> in there you can specify "crypt", and the system will expect that the passwds
> in pg_shadow are encrypted.
Not so! "crypt" authentication provides for sending passwords in
crypted form during login (which is good if you're afraid of password-
sniffers, but then maybe you should be using SSL to protect your whole
session, not only the password). But it doesn't change the contents
of pg_shadow.
David, you can find several discussions of this topic in the pg-hackers
archives, the latest just a couple of weeks ago. The short answer is
that many of us think the risk has been drastically overstated by
complainers --- if someone has broken into your database enough to read
the contents of pg_shadow, then you've got worse problems than whether
he knows your password. However, we did converge on what seemed to be a
good plan to change the implementation, and I think there is someone
working on it.
BTW, there is no particularly good reason to be storing passwords in
the Postgres database at all --- you can instead use Kerberos
authentication, or perhaps "ident" authentication (though ident is
only OK if logins are only accepted from machines whose sysadmins you
trust, since ident is easily faked on an insecure machine).
regards, tom lane
Tom Lane wrote:
>
> Jim Mercer <jim@reptiles.org> writes:
> > by default, the passwords are stored in clear text.
> > however, if you are configuring passwords, then likely you are going
> > to need to change settings in pg_hba.conf. in there you can specify
> > "crypt", and the system will expect that the passwds in pg_shadow
> > are encrypted.
>
> Not so! "crypt" authentication provides for sending passwords in
> crypted form during login (which is good if you're afraid of password-
> sniffers, but then maybe you should be using SSL to protect your whole
> session, not only the password). But it doesn't change the contents
> of pg_shadow.
...
>
> BTW, there is no particularly good reason to be storing passwords in
> the Postgres database at all --- you can instead use Kerberos
> authentication, or perhaps "ident" authentication (though ident is
> only OK if logins are only accepted from machines whose sysadmins you
> trust, since ident is easily faked on an insecure machine).
>
> regards, tom lane
Unfortunately for those depending on Kerberos, a CERT advisory
was released just yesterday:
CERT Advisory CA-2000-06 Multiple Buffer Overflows in Kerberos
Authenticated Services
Original release date: May 17, 2000
Last revised: --
Source: The MIT Kerberos Team, CERT/CC
A complete revision history is at the end of this file.
Systems Affected
* Systems running services authenticated via Kerberos 4
* Some systems running services authenticated via Kerberos 5
* Systems running the Kerberized remote shell daemon (krshd)
* Systems with the Kerberos 5 ksu utility installed
* Systems with the Kerberos 5 v4rcp utility installed
Overview
The CERT Coordination Center has recently been notified of
several
buffer overflow vulnerabilities in the Kerberos authentication
software. The most severe vulnerability allows remote
intruders to
gain root privileges on systems running services using
Kerberos
authentication. If vulnerable services are enabled on the Key
Distribution Center (KDC) system, the entire Kerberos domain
may be
compromised.
...
Mike Mascari
At 05:38 PM 18-05-2000 -0400, Tom Lane wrote: >Not so! "crypt" authentication provides for sending passwords in >crypted form during login (which is good if you're afraid of password- >sniffers, but then maybe you should be using SSL to protect your whole >session, not only the password). But it doesn't change the contents >of pg_shadow. But if someone sniffs the crypted form, won't they be able to reuse it? What's there to prevent reuse of the crypted form? If there's nothing to prevent that, I do not see any benefit of the crypt method, it's just a waste of time. I never really understood the postgresql crypt password mode- if it was what I understood it to be, it was pretty much useless. In the end I stuck to plaintext passwords, easier for me to understand. >BTW, there is no particularly good reason to be storing passwords in >the Postgres database at all --- you can instead use Kerberos >authentication, or perhaps "ident" authentication (though ident is >only OK if logins are only accepted from machines whose sysadmins you >trust, since ident is easily faked on an insecure machine). That probably means that ident is easily faked on most machines :). I figure it's probably better to have a secure net (switched perhaps). If external insecure machines need to use stuff in the secure net, there should be a dedicated VPN or SSL server for that purpose. Cheerio, Link.
Lincoln Yeoh <lylyeoh@mecomb.com> writes:
> At 05:38 PM 18-05-2000 -0400, Tom Lane wrote:
>> Not so! "crypt" authentication provides for sending passwords in
>> crypted form during login (which is good if you're afraid of password-
>> sniffers, but then maybe you should be using SSL to protect your whole
>> session, not only the password). But it doesn't change the contents
>> of pg_shadow.
> But if someone sniffs the crypted form, won't they be able to reuse it?
Not unless they're lucky enough to be challenged with the same random
"salt" value that was used in the login transaction they sniffed.
I don't particularly care to rehash the *very* long discussion we just
went through on the hackers list. Suffice it to say that the current
method is not a waste of time, but it could be made better. See the
archives (if Marc ever gets them working again :-() for details.
regards, tom lane
At 09:59 PM 18-05-2000 -0400, Tom Lane wrote: >Lincoln Yeoh <lylyeoh@mecomb.com> writes: >> At 05:38 PM 18-05-2000 -0400, Tom Lane wrote: > >> But if someone sniffs the crypted form, won't they be able to reuse it? > >Not unless they're lucky enough to be challenged with the same random >"salt" value that was used in the login transaction they sniffed. Well then it's a max of 4096 tries? Assuming a normal crypt size salt. Of course a dictionary crack might be easy enough and definitely less obstrusive than <salt-permutation> tries. Does 7.0 log authentication failures on a different level? Cheerio, Link.
Lincoln Yeoh <lylyeoh@mecomb.com> writes:
>>> But if someone sniffs the crypted form, won't they be able to reuse it?
>>
>> Not unless they're lucky enough to be challenged with the same random
>> "salt" value that was used in the login transaction they sniffed.
> Well then it's a max of 4096 tries? Assuming a normal crypt size salt.
Right, it's not real strong with standard crypt :-(
However, you must agree that that is the fault of the crypt engine
and not of the protocol. The plan that was being discussed on pghackers
was to replace crypt with an MD5 crypto-hash algorithm and widen the
random salt sufficiently that pure luck wouldn't let an attacker see
the same salt twice. See the archives if you want to pursue this;
I really don't care to repeat the discussion-so-far...
regards, tom lane