Lists: | pgsql-bugs |
---|
From: | "David Litchfield" <davidl(at)ngssoftware(dot)com> |
---|---|
To: | "John Heasman" <john(at)ngssoftware(dot)com>, <pgsql-bugs(at)postgresql(dot)org> |
Cc: | <dl-advisories(at)ngssoftware(dot)com> |
Subject: | Re: Privilege escalation via LOAD |
Date: | 2005-01-21 13:05:13 |
Message-ID: | 008701c4ffb9$d8b96d80$2100a8c0@SIRIUS |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
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).
>
>
From: | John Heasman <john(at)ngssoftware(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Cc: | dl-advisories(at)ngssoftware(dot)com |
Subject: | Privilege escalation via LOAD |
Date: | 2005-01-21 19:08:44 |
Message-ID: | Pine.WNT.4.61.0501211049190.1264@j2 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
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).
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | John Heasman <john(at)ngssoftware(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org, dl-advisories(at)ngssoftware(dot)com |
Subject: | Re: Privilege escalation via LOAD |
Date: | 2005-01-24 16:05:20 |
Message-ID: | 21745.1106582720@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
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
From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | John Heasman <john(at)ngssoftware(dot)com>, pgsql-bugs(at)postgresql(dot)org, dl-advisories(at)ngssoftware(dot)com |
Subject: | Re: Privilege escalation via LOAD |
Date: | 2005-01-24 16:34:04 |
Message-ID: | 200501241734.05297.peter_e@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
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/
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David Litchfield" <davidl(at)ngssoftware(dot)com> |
Cc: | "John Heasman" <john(at)ngssoftware(dot)com>, pgsql-bugs(at)postgresql(dot)org, dl-advisories(at)ngssoftware(dot)com |
Subject: | Re: Privilege escalation via LOAD |
Date: | 2005-01-25 18:54:29 |
Message-ID: | 5818.1106679269@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
"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