Thread: 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).
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 > 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@ngssoftware.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@ngssoftware.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@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