Bugtraq mailing list archives
Re: Postgresql cleartext password storage
From: razor () LDC RO (Alexandru Popa)
Date: Tue, 25 Apr 2000 00:11:30 +0300
On Sun, 23 Apr 2000, Robert van der Meulen wrote:
Hi,
Hello, had you looked at pg_pwd, you would have seen the usarnames and passwords in cleartext, in an all-text file.
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)
Compromising user postgres would give you the opportunity to stop the postmaster daemon and start it with a "trust" option for local/remote connections, allowing you to connect as any user, no questions asked.
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
Basically, this a known issue. On Debian GNU/Linux potato, updates including yesterday, in file /usr/share/doc/postgresql-doc/README.passwords you can find: ------------- Passwords are stored in pg_shadow in clear, but if `crypt' authentication is specified, the frontend encrypts the password with a random salt and the backend uses the same salt to encrypt the password in the database. If the two encrypted passwords match, the user is allowed access. If the authentication method is `password', the password is transmitted and compared in clear. ------------- and a little lower: ------------- 2. In general, passwords are insecure, because they are held in clear in pg_shadow. Anyone with create-user privilege can not only alter but also read them. They ought to be stored with one-way encryption, as with the Unix password system. ------------- So this is well known and documented. Anyway, you don't have normal users on the database server, now do you? ------------+------------------------------------------ Alex Popa, |There never was a good war or a bad peace razor () ldc ro| -- B. Franklin ------------+------------------------------------------ "It took the computing power of three C-64s to fly to the Moon. It takes a 486 to run Windows 95. Something is wrong here."
Current thread:
- Re: CVS DoS, (continued)
- Re: CVS DoS Kris Kennaway (Apr 24)
- finding Meeting Maker passwords using tcpdump mhpower () MIT EDU (Apr 24)
- ZoneAlarm Vulnerability Alfred Huger (Apr 25)
- Solaris Sparc 2.6 & 7 lp/lpset/lpstat root compromise exploit Laurent LEVIER (Apr 25)
- Re: Solaris Sparc 2.6 & 7 lp/lpset/lpstat root compromise exploit Casper Dik (Apr 26)
- Re: Solaris Sparc 2.6 & 7 lp/lpset/lpstat root compromise exploit Dimitri Avgoustakis (Apr 26)
- Re: Solaris Sparc 2.6 & 7 lp/lpset/lpstat root compromise exploit Theodor R. Gislason (Apr 26)
- SECURITY: UPDATED - RHSA-2000:014 New Piranha release available Cristian Gafton (Apr 26)
- gpm-root initgroups() Koblinger Egmont (Apr 23)
- Postgresql cleartext password storage Robert van der Meulen (Apr 23)
- Re: Postgresql cleartext password storage Alexandru Popa (Apr 24)
- Re: ZoneAlarm Stephen M. Milton (Apr 24)
- Microsoft Security Bulletin (MS00-027) Microsoft Product Security (Apr 20)
- Remote vulnerability in LCDproc 0.4 Andrew Hobgood (Apr 20)
- Remote DoS attack in RealServer David Cotter (Apr 20)
- CMD.EXE overflow (CISADV000420) Cerberus Security Team (Apr 21)