Thread: [Fwd: Bug#184566: security threat to postgresql applications]

Is this paranoia, or is it a valid security point.  Any comments,
please?

-----Forwarded Message-----

From: Erik Thiele <erik@thiele-hydraulik.de>
To: submit@bugs.debian.org
Subject: Bug#184566: security threat to postgresql applications
Date: 13 Mar 2003 09:22:13 +0100

Package: postgresql
Version: 7.2.1-2woody2

if an application is linked against libpq, then the user is able to
specify environmental variables to override the defaults:

PGPORT sets the default TCP port number or Unix-domain socket file
extension for communicating with the PostgreSQL backend.
PGDATABASE sets the default PostgreSQL database name.
PGUSER sets the user name used to connect to the database and for
authentication.
PGPASSWORD sets the password used if the backend demands password
authentication. This is not recommended because the password can be read
by others using the ps command with special options on some platforms.
PGREALM sets the Kerberos realm to use with PostgreSQL, if it is
different from the local realm. If PGREALM is set, PostgreSQL
applications will attempt authentication with servers for this realm and
use separate ticket files to avoid conflicts with local ticket files.
This environment variable is only used if Kerberos authentication is
selected by the backend.
PGOPTIONS sets additional runtime options for the PostgreSQL backend.
PGTTY sets the file or tty on which debugging messages from the backend
server are displayed.
PGDATESTYLE sets the default style of date/time representation.
PGTZ sets the default time zone.
PGCLIENTENCODING sets the default client encoding (if multibyte support
was selected when configuring PostgreSQL).
PGGEQO sets the default mode for the genetic optimizer.

the usual user program probably does something like:

PQconnectdb("host='myhost' dbname='mydb' user='myuser' password='s'");


FIRST POINT:
------------

the resulting executable program must be --x--x--x so that the users
using it
cannot read the binary and thus cannot see the password. that should be
in the documentation! programmers must not forget this issue!!


SECOND POINT:
-------------

if the user runs the program with the environment variable PORT set to
23423, he can install his own program on that port listening for the
password! he can then use that password to connect to the real database
and delete everything.


the two POINT must be documentated. a fix for the first point is not
neccessary. but a fix for the second point cannot be done due to
backward compatibility. ALL environment variables should be ignored.
there should be a "mkoptions_from_environment" function that has to be
explicitly called.

the environment stuff is like a second way into a function. not clean
design. i.e:

printf("hello");

does not print hello, but prints "goodbye" instead because the
environment sais so. i don't like the idea in general.

the documentation must say that one has to specify the port even if it
is the default port, because otherwise the database password can be
stolen.


but really there must be documentation on the issue!!

not all apps are web based. there are still native programs floating
around that are called by ordinary users...

cu
erik

-- 
Erik Thiele
email: erik@thiele-hydraulik.de
-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight, UK                             http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
========================================   "Thy word have I hid in mine heart, that I might not      sin against thee."
      Psalms 119:11 
 

On Fri, 2003-03-21 at 16:06, Oliver Elphick wrote:
> Is this paranoia, or is it a valid security point.  Any comments,
> please?

A little from column A, a little from column B, IMHO.

> if an application is linked against libpq, then the user is able to
> specify environmental variables to override the defaults

Note that this overrides the *default* -- if the application specifies
the full set of data of the host it wants to connect to, the
environmental vars shouldn't be used, AFAIK.

> if the user runs the program with the environment variable PORT set to
> 23423, he can install his own program on that port listening for the
> password! he can then use that password to connect to the real database
> and delete everything.

How is that any different than the user altering the database hostname
the client connects to, and setting up a fake DB server on that host?
Many database applications allow that...

Cheers,

Neil

Neil Conway <neilc@samurai.com> writes:
> On Fri, 2003-03-21 at 16:06, Oliver Elphick wrote:
>> Is this paranoia, or is it a valid security point.  Any comments,
>> please?

> A little from column A, a little from column B, IMHO.

Mostly column A, IMHO.  The presumption is that an attacker (a) knows
that program X contains an embedded password and (b) is able to control
the environment in which the program is executed.  Given that
combination I can think of hardly anything that would *not* be
vulnerable.  For one thing, setting up a man-in-the-middle situation
would be pretty easy.

I can't imagine any situation in which I'd recommend embedding a
password into a postgres client app anyway.
        regards, tom lane