Re: 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@ngssoftware.com>
To: <pgsql-bugs@postgresql.org>
Cc: <dl-advisories@ngssoftware.com>
Sent: Friday, January 21, 2005 7:08 PM
Subject: Privilege escalation via LOAD
Show quoted text
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).
Import Notes
Reference msg id not found: Pine.WNT.4.61.0501211049190.1264@j2
"David Litchfield" <davidl@ngssoftware.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