Re: bugtraq post

On 6/17/07, Ray Stell <stellr@cns.vt.edu> wrote:
>
> For the security minded:
>
> Nico Leidecker <nicoLeidecker@web.de> posted this to bugtraq yesterday, fyi.
>
> "I'd like to present a paper about security issues with PostgreSQL. The paper describes weaknesses in the
configurationthat may 
> +allow attackers to escalade privileges, execute shell commands and to upload arbitrary (binary) files via SQL
injections.
>
> You can either get the TXT version from http://www.leidecker.info/pgshell/Having_Fun_With_PostgreSQL.txt
> Or as PDF at at http://www.portcullis.co.uk/uplds/whitepapers/Having_Fun_With_PostgreSQL.pdf
>
> The paper comes with a tool called `pgshell' that can be downloaded at http://www.leidecker.info/pgshell"

Interesting, though it seems its nothing really special. Basically, if you are
a superuser you can do pretty much everything you want.  After all PostgreSQL
is about flexibility.

>  The  default  PostgreSQL  configuration from the sources has local trust au-
>  thentication enabled. Any connection made from the local host to  the  data-
>  base  will  be  accepted and the user directly logged in without the need to
>  supply a password. It is hard to understand, why such a feature is  part  ofd
>  the  default  configuration  and  yet, the warning in the corresponding file
>  ('pg_hba.conf') is unmistakable:

All "default" instalations I've used had "ident sameuser" as default auth method
for postmaster.  Anyhow, one can say Oracle has similar problem, where user
can with help of DBMS_TCP shutdown listener, for example.

And dblink is not installed by default, so DBA should be careful for whom and
how he makes it available (security definer function? View? I guess normal
user should never ever be able to call it directly).

And of course, if user has a superuser privilege, he can do about anything he
wants.  No surprise here, though I enjoyed the equillibristics with
open/writle/close,
when one could put a shell script into temp table, COPY it somewhere and
then system("...") it. ;-)

Anyhow it's good to know that most vulnerabilities in PostgreSQL require
superuser privilege. :-)

   Regards,
     Dawid