Vulnerability

    Postgres

Affected

    Postgresql

Description

    Robert  van  der  Meulen  found  following.   While migrating some
    postgres  databases   to  a   different  server   (including  user
    accounts) he  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).

    This  was  tested  on  postgres  versions  6.3.2 and 6.5.3, others
    probably experience this problem as well.

Solution

    Basically,  this  a  known  issue.   On  Debian  GNU/Linux potato,
    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?