[BUGS]

[Servio Medina]

Hello,

The purpose of this email is twofold: 1) to inform you of a reported
vulnerability by a third party, not myself,  involving one of your products,
and 2) to obtain confirmation/clarification and knowledge of any measures
taken to address this in the event it is viable. The report indicates that
appropriate contact was made to your organization - I trust this is the
case.

Below is the report (snipped):

--- Begin report ---
-Original Message-
From: Robert van der Meulen [mailto:[EMAIL PROTECTED]] 
Sent: Sunday, April 23, 2000 4:03 PM
To: [EMAIL PROTECTED]
Subject: Postgresql cleartext password storage


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

--

|  [EMAIL PROTECTED] - 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.   |




--- End report ---


An explanation of my query - I work for Infrastructure Defense, Inc., which
provides private publications to fortune 500 companies about
information/computer security trends, vulnerabilities, etc. I strive to
contact the appropriate parties whenever there is a question as to the
veracity of a post, claim, other. Hence, my email to you.

I hope to hear from you soon.


Servio Medina - [EMAIL PROTECTED]
Information Security Analyst
www.idefense.com 

Re: [BUGS]

[Tom Lane]

Servio Medina <[EMAIL PROTECTED]> writes:
> 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)

Not sure exactly what you think the vulnerability is.  Postgres and root
can read all the databases anyway, so what matter whether they can read
the passwords?

Of course, if one also uses one's login password as a database password,
it'd not be too cool, but cleartext storage of the passwords is far from
the weakest link...

regards, tom lane

Re: [BUGS] PostgreSQL 7.0 beta 4: Error in Insert/Select

[Tom Lane]

> Michael Shepelev <[EMAIL PROTECTED]> writes:
>> I found bug (IMHO) in Insert/Select Union command.
>> Result of SELECT UNION differs from INSERT SELECT UNION.

> Wow, that's bizarre.  I confirm seeing the inconsistent behavior.

On further investigation, it seems this is just another facet of the
known bogosities in INSERT ... SELECT ... UNION (see for example my
pghackers message of 7/19/99 22:59 EDT, as well as some others in the
archives).  The INSERT into "o1" needs to rewrite the result of the
SELECT to include a couple of null column values, and this is being
done to the first sub-SELECT's target list *but not the second's*.
The upshot is garbage data inserted into the result table.

I looked at fixing this and concluded that trying to fix it five
days before 7.0 release would be just plain foolhardy.  That part
of the code needs a thorough rewrite not emergency patches :-(
I recommend adding this example to the list of test cases for our
upcoming querytree rewrite.

In the meantime, an ugly workaround is available for Michael:
don't omit any columns in the INSERT targetlist, but instead
write explicit NULL results in the right places in the sub-SELECTs.
(Ick... but that's the best we can do for now...)

regards, tom lane