Skip site navigation (1) Skip section navigation (2)

Re: Privilege escalation via LOAD

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 (view raw or flat)
Thread:
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).
>
> 



In response to

Responses

pgsql-bugs by date

Next:From: Rick WalrondDate: 2005-01-21 13:38:21
Subject: BUG #1430: CSRSS.EXE high CPU after 8.0 Installed
Previous:From: Hendrik MuellerDate: 2005-01-21 11:43:26
Subject: BUG #1429: stats tests fails

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group