Privilege escalation via LOAD

John,
_init() is the equivalent of DllMain on Linux/etc; in fact the other
database server I was looking at is vulnerable to this exact problem. If
postgresql accepts CLOB/BLOB input from a client to a table and then can
dump to disk you might be able to achieve it that way - which is how I did
it on the other rdbms.
Cheers,
David

----- Original Message -----
From: "John Heasman" <john(at)ngssoftware(dot)com>
To: <pgsql-bugs(at)postgresql(dot)org>
Cc: <dl-advisories(at)ngssoftware(dot)com>
Sent: Friday, January 21, 2005 7:08 PM
Subject: Privilege escalation via LOAD

> Hi guys,
>
> It appears that low privileged users can invoke the LOAD extension to load
> arbitrary libraries into the postgres process space. On Windows systems
> this is achieved by calling LoadLibrary
> (src/backend/port/dynloader/win32.c). The effect of this is that DllMain
> will be executed. Since LOAD takes an absolute path, UNC paths may be
> used on Windows, thus a low privileged database user can load an arbitrary
> library from an anonymous share they have set up, escalating to the
> privileges of the database user. I am still investigating the impact on
> Unix.
>
> Cheers
>
> John
>
> (this vulnerability was born out of a discussion on #postgresql between
> myself, lurka and dennisb).
>
>

Hi guys,

It appears that low privileged users can invoke the LOAD extension to load
arbitrary libraries into the postgres process space. On Windows systems
this is achieved by calling LoadLibrary
(src/backend/port/dynloader/win32.c). The effect of this is that DllMain
will be executed. Since LOAD takes an absolute path, UNC paths may be
used on Windows, thus a low privileged database user can load an arbitrary
library from an anonymous share they have set up, escalating to the
privileges of the database user. I am still investigating the impact on
Unix.

Cheers

John

(this vulnerability was born out of a discussion on #postgresql
between myself, lurka and dennisb).

John Heasman <john(at)ngssoftware(dot)com> writes:
> It appears that low privileged users can invoke the LOAD extension to load
> arbitrary libraries into the postgres process space.

Hmm. Creating C functions is restricted to superusers, but I guess no
one ever noticed that LOAD isn't. On a platform where that can execute
initialization functions this does seem like a security issue.

regards, tom lane

Tom Lane wrote:
> John Heasman <john(at)ngssoftware(dot)com> writes:
> > It appears that low privileged users can invoke the LOAD extension
> > to load arbitrary libraries into the postgres process space.
>
> Hmm. Creating C functions is restricted to superusers, but I guess
> no one ever noticed that LOAD isn't. On a platform where that can
> execute initialization functions this does seem like a security
> issue.

I believe all ELF platforms fall into that category.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

"David Litchfield" <davidl(at)ngssoftware(dot)com> writes:
> _init() is the equivalent of DllMain on Linux/etc; in fact the other
> database server I was looking at is vulnerable to this exact problem. If
> postgresql accepts CLOB/BLOB input from a client to a table and then can
> dump to disk you might be able to achieve it that way - which is how I did
> it on the other rdbms.

Just for the record, I don't believe there is any way to make Postgres
itself write out a shared library for you, at least not unless you
already have database superuser (in which case you already have all the
privileges a database attack could gain for you). There are no
unprivileged functions to write a file in the server filesystem,
and certainly not any that will "chmod +x" it for you. So this
vulnerability does not represent a useful remote exploit AFAICS.

As a local exploit, on the other hand, it's pretty trivial :-(

regards, tom lane