Bugtraq: Having Fun With PostgreSQL
A message entitled "Having Fun With PostgreSQL" was posted to Bugtraq
today. I haven't read through the paper yet so I don't know if the
author discusses security problems that need attention or if the
article is more like a compilation of "Stupid PostgreSQL Tricks."
http://www.securityfocus.com/archive/1/471541/30/0/threaded
--
Michael Fuhr
Michael Fuhr <mike@fuhr.org> writes:
A message entitled "Having Fun With PostgreSQL" was posted to Bugtraq
today. I haven't read through the paper yet so I don't know if the
author discusses security problems that need attention or if the
article is more like a compilation of "Stupid PostgreSQL Tricks."
http://www.securityfocus.com/archive/1/471541/30/0/threaded
It appears he's discovered the astonishing facts that
1. The out-of-the-box authentication setup is "trust".
2. A superuser can make the database do whatever he wants (within
the OS privilege limits of the postgres user).
We've debated #1 before, and a lot of repackagers change it, but I
don't really feel a strong urge to change it in the source distro.
As for #2, that's not a bug, it's intended behavior.
regards, tom lane
PS: I skimmed the paper pretty fast, so it's possible I missed
something interesting, but it sure looked like "what else is new?"
On Sat, 16 Jun 2007, Michael Fuhr wrote:
A message entitled "Having Fun With PostgreSQL" was posted to Bugtraq
today. I haven't read through the paper yet so I don't know if the
author discusses security problems that need attention or if the
article is more like a compilation of "Stupid PostgreSQL Tricks."
The crux of this seems to be two-fold:
1. If dblink is installed, an untrusted user could use it to gain
privileges, either using trust/ident auth (you have a superuser named
after the account the postmaster is runing as), or can be scripted to
brute force passwords.
2. If you are a superuser, you can gain access to the external system, ie,
by creating C language functions.
Neither of these are news to me, but maybe some new postgres admin will
read it and figure out to disable trust auth and not to let untrusted
users call dblink (either not install it or REVOKE the rights to call it).
--
Around computers it is difficult to find the correct unit of time to
measure progress. Some cathedrals took a century to complete. Can you
imagine the grandeur and scope of a program that would take as long?
-- Epigrams in Programming, ACM SIGPLAN Sept. 1982
Tom Lane wrote:
Michael Fuhr <mike@fuhr.org> writes:
A message entitled "Having Fun With PostgreSQL" was posted to Bugtraq
today. I haven't read through the paper yet so I don't know if the
author discusses security problems that need attention or if the
article is more like a compilation of "Stupid PostgreSQL Tricks."
http://www.securityfocus.com/archive/1/471541/30/0/threadedIt appears he's discovered the astonishing facts that
1. The out-of-the-box authentication setup is "trust".
2. A superuser can make the database do whatever he wants (within
the OS privilege limits of the postgres user).We've debated #1 before, and a lot of repackagers change it, but I
don't really feel a strong urge to change it in the source distro.
As for #2, that's not a bug, it's intended behavior.
On #1, the fact that we allow trust as default is embarrassing. It would
be just as bad as having the default root password be password on a
linux box. We should be using md5 and force passing the password with
initdb.
Sincerely,
Joshua D. Drake
regards, tom lane
PS: I skimmed the paper pretty fast, so it's possible I missed
something interesting, but it sure looked like "what else is new?"---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
The world rejoiced as jd@commandprompt.com ("Joshua D. Drake") wrote:
Tom Lane wrote:
Michael Fuhr <mike@fuhr.org> writes:
A message entitled "Having Fun With PostgreSQL" was posted to Bugtraq
today. I haven't read through the paper yet so I don't know if the
author discusses security problems that need attention or if the
article is more like a compilation of "Stupid PostgreSQL Tricks."
http://www.securityfocus.com/archive/1/471541/30/0/threadedIt appears he's discovered the astonishing facts that
1. The out-of-the-box authentication setup is "trust".
2. A superuser can make the database do whatever he wants (within
the OS privilege limits of the postgres user).
We've debated #1 before, and a lot of repackagers change it, but I
don't really feel a strong urge to change it in the source distro.
As for #2, that's not a bug, it's intended behavior.On #1, the fact that we allow trust as default is embarrassing. It
would be just as bad as having the default root password be password
on a linux box. We should be using md5 and force passing the password
with initdb.
That won't help; that would introduce the "embarrassment" of having a
known default password.
This is a case where it takes careful thought to grasp whether there
is a problem or not.
If all we do is to shift the embarrassment around, that's not much
help.
--
output = reverse("moc.liamg" "@" "enworbbc")
http://linuxfinances.info/info/slony.html
"If all you can see is vast masses of end-users chewing their cud and
running Win95 on Gateways, then what good is platform independence?"
-- David LeBlanc (dleblanc@mindspring.com)
Christopher Browne wrote:
The world rejoiced as jd@commandprompt.com ("Joshua D. Drake") wrote:
Tom Lane wrote:
We've debated #1 before, and a lot of repackagers change it, but I
don't really feel a strong urge to change it in the source distro.
As for #2, that's not a bug, it's intended behavior.On #1, the fact that we allow trust as default is embarrassing. It
would be just as bad as having the default root password be password
on a linux box. We should be using md5 and force passing the password
with initdb.That won't help; that would introduce the "embarrassment" of having a
known default password.
No it wouldn't unless the packagers set it up to do that. My point is
that when a packager (or source) runs initdb, it would prompt for the
postgres user password. Just like when you create a ssh key or cert etc...
Joshua D. Drake
This is a case where it takes careful thought to grasp whether there
is a problem or not.If all we do is to shift the embarrassment around, that's not much
help.
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Christopher Browne <cbbrowne@acm.org> writes:
The world rejoiced as jd@commandprompt.com ("Joshua D. Drake") wrote:
On #1, the fact that we allow trust as default is embarrassing.
This is a case where it takes careful thought to grasp whether there
is a problem or not.
If all we do is to shift the embarrassment around, that's not much
help.
We've argued this in considerable detail in the past. The bottom line
is that the trust default is the worst possible choice, except for all
the others. One of the more obvious problems with the others is that
a newbie who can't get into his database at all will not become a
Postgres adopter...
regards, tom lane
"Joshua D. Drake" <jd@commandprompt.com> writes:
Christopher Browne wrote:
That won't help; that would introduce the "embarrassment" of having a
known default password.
No it wouldn't unless the packagers set it up to do that. My point is
that when a packager (or source) runs initdb, it would prompt for the
postgres user password.
Practically every existing packaging of PG tries to run initdb as a
hidden, behind-the-scenes, definitely not-interactive procedure.
regards, tom lane
That won't help; that would introduce the "embarrassment" of having a
known default password.No it wouldn't unless the packagers set it up to do that. My point is
that when a packager (or source) runs initdb, it would prompt for the
postgres user password.Practically every existing packaging of PG tries to run initdb as a
hidden, behind-the-scenes, definitely not-interactive procedure.
afaik, practically every existing packaging of pg has *already* solved the problem and does not set trust as default anyway. ident sameuser I think is the most
common.
One thing I've thought about doing is to remove the default in initdb completely and *force* the user to choose auth type. Packagers can then just use that to
set ident or whatever. and interactive users can pick trust if they really need it, but it will be a known choice.
/Magnus
Hi,
On Mon, 2007-06-18 at 01:58 -0400, Tom Lane wrote:
Practically every existing packaging of PG tries to run initdb as a
hidden, behind-the-scenes, definitely not-interactive procedure.
Also, from RPM perspective: RPMs are *not* interactive, and will *never*
be. So we cannot ask user a password during initdb, or such.
Regards,
--
Devrim GÜNDÜZ
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/
* Jeremy Drake (pgsql@jdrake.com) wrote:
The crux of this seems to be two-fold:
1. If dblink is installed, an untrusted user could use it to gain
privileges, either using trust/ident auth (you have a superuser named
after the account the postmaster is runing as), or can be scripted to
brute force passwords.
The dblink w/ ident case is at least somewhat interesting since, iirc
anyway, if you install dblink it comes with permissions for anyone to
run it. That's pretty ugly if your PG superuser is the same user
PostgreSQL runs as and you're using ident (which is quite common, esp.
over unix sockets). The answer here being, don't allow just anyone to
run dblink.
2. If you are a superuser, you can gain access to the external system, ie,
by creating C language functions.
Which, as an issue, is pretty much resolved in 8.2 anyway... You'd have
to be able to compile and/or upload new libraries to the system w/ 8.2
since the PG_MODULE_MAGIC is required now.
Neither of these are news to me, but maybe some new postgres admin will
read it and figure out to disable trust auth and not to let untrusted
users call dblink (either not install it or REVOKE the rights to call it).
I'm strongly tempted to say this should be set up as the default for
dblink, if it's not too hard to implement (I'd expect there's already a
.sql which does the in-db create function and whatnot, just revoke all
from it after it's created and tell people to create views using it
instead as superuser).
Thanks,
Stephen
On Jun 18, 2007, at 12:58 AM, Tom Lane wrote:
"Joshua D. Drake" <jd@commandprompt.com> writes:
Christopher Browne wrote:
That won't help; that would introduce the "embarrassment" of
having a
known default password.No it wouldn't unless the packagers set it up to do that. My point is
that when a packager (or source) runs initdb, it would prompt for the
postgres user password.Practically every existing packaging of PG tries to run initdb as a
hidden, behind-the-scenes, definitely not-interactive procedure.
I know there's issues with using ident sameuser via TCP, but what
about for filesystem socket connections?
As for the interactive/non-interactive, we could just leave that as
an option to initdb, and make the default to ask for a password.
Packagers would just need to feed the right option to initdb.
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Jim,
I know there's issues with using ident sameuser via TCP, but what
about for filesystem socket connections?
Not all OSes support ident ... Solaris and OpenBSD for two, don't, because
they see ident as insecure.
We switched the default to "trust localhost only" after many, many complaints
by newbies that they had installed PostgreSQL but couldn't log into it.
Other than maybe putting more emphasis on setting up the superuser password
in the tutorial, I really don't think that we should change the behavior.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
On Jun 19, 2007, at 1:27 PM, Josh Berkus wrote:
I know there's issues with using ident sameuser via TCP, but what
about for filesystem socket connections?Not all OSes support ident ... Solaris and OpenBSD for two, don't,
because
they see ident as insecure.
What about the unix domain socket, though? AFAIK that doesn't rely on
ident but some other method...
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Jim Nasby <decibel@decibel.org> writes:
On Jun 19, 2007, at 1:27 PM, Josh Berkus wrote:
Not all OSes support ident ... Solaris and OpenBSD for two, don't,
because they see ident as insecure.
What about the unix domain socket, though? AFAIK that doesn't rely on
ident but some other method...
On OpenBSD we use getpeereid() for unix sockets, and there are
equivalent things on some other Unixen. We could never go over to
ident as the standard default, though, because not all platforms
have these sorts of features (if indeed they have unix sockets at
all ...); and in any case it's not very secure for TCP.
regards, tom lane
Magnus Hagander wrote:
That won't help; that would introduce the "embarrassment" of
having a known default password.No it wouldn't unless the packagers set it up to do that. My
point is that when a packager (or source) runs initdb, it would
prompt for the postgres user password.Practically every existing packaging of PG tries to run initdb as a
hidden, behind-the-scenes, definitely not-interactive procedure.afaik, practically every existing packaging of pg has *already*
solved the problem and does not set trust as default anyway. ident
sameuser I think is the most common.One thing I've thought about doing is to remove the default in initdb
completely and *force* the user to choose auth type. Packagers can
then just use that to set ident or whatever. and interactive users
can pick trust if they really need it, but it will be a known choice.
Since nobody comemnted on this, let me turn it around and ask: Does
anybody have any reason *not* to do this?
If not, I'll just make it happen... (that should at least make people
speak up :P)
//Magnus
Magnus Hagander wrote:
Magnus Hagander wrote:
That won't help; that would introduce the "embarrassment" of
having a known default password.No it wouldn't unless the packagers set it up to do that. My
point is that when a packager (or source) runs initdb, it would
prompt for the postgres user password.Practically every existing packaging of PG tries to run initdb as a
hidden, behind-the-scenes, definitely not-interactive procedure.afaik, practically every existing packaging of pg has *already*
solved the problem and does not set trust as default anyway. ident
sameuser I think is the most common.One thing I've thought about doing is to remove the default in initdb
completely and *force* the user to choose auth type. Packagers can
then just use that to set ident or whatever. and interactive users
can pick trust if they really need it, but it will be a known choice.Since nobody comemnted on this, let me turn it around and ask: Does
anybody have any reason *not* to do this?If not, I'll just make it happen... (that should at least make people
speak up :P)
It will break the buildfarm. Of course I can unbreak it by adding
"--auth=trust" to the initdb args (and if we go this route we'll need to
do that for the regression temp installs too), but we'd need every
buildfarm member to have upgraded before we put it in. Is that really
the sort of disruption you want right now?
cheers
andrew
Andrew Dunstan wrote:
Magnus Hagander wrote:
Magnus Hagander wrote:
That won't help; that would introduce the "embarrassment" of
having a known default password.No it wouldn't unless the packagers set it up to do that. My
point is that when a packager (or source) runs initdb, it would
prompt for the postgres user password.Practically every existing packaging of PG tries to run initdb as a
hidden, behind-the-scenes, definitely not-interactive procedure.afaik, practically every existing packaging of pg has *already*
solved the problem and does not set trust as default anyway. ident
sameuser I think is the most common.One thing I've thought about doing is to remove the default in initdb
completely and *force* the user to choose auth type. Packagers can
then just use that to set ident or whatever. and interactive users
can pick trust if they really need it, but it will be a known choice.Since nobody comemnted on this, let me turn it around and ask: Does
anybody have any reason *not* to do this?If not, I'll just make it happen... (that should at least make people
speak up :P)It will break the buildfarm. Of course I can unbreak it by adding
"--auth=trust" to the initdb args (and if we go this route we'll need to
do that for the regression temp installs too), but we'd need every
buildfarm member to have upgraded before we put it in. Is that really
the sort of disruption you want right now?
Ouch. No. Didn't think of that.
If we want to do that, we should probably do it right at the start of
the 8.4 cycle then?
//Magnus
Magnus Hagander <magnus@hagander.net> writes:
One thing I've thought about doing is to remove the default in initdb
completely and *force* the user to choose auth type. Packagers can
then just use that to set ident or whatever. and interactive users
can pick trust if they really need it, but it will be a known choice.
Since nobody comemnted on this, let me turn it around and ask: Does
anybody have any reason *not* to do this?
I'll object if no one else does: this will break existing installation
habits and processes to no real benefit.
regards, tom lane
Tom Lane wrote:
Magnus Hagander <magnus@hagander.net> writes:
One thing I've thought about doing is to remove the default in initdb
completely and *force* the user to choose auth type. Packagers can
then just use that to set ident or whatever. and interactive users
can pick trust if they really need it, but it will be a known choice.Since nobody comemnted on this, let me turn it around and ask: Does
anybody have any reason *not* to do this?I'll object if no one else does: this will break existing installation
habits and processes to no real benefit.
The benefit would be that PostgreSQL would be "secure by default". Which
we are *not* today.
As a comparison, that's been one of the most common complaints against
Windows earlier - stuff is installed and enabled by default, and only if
you already know the system do you know that you should disable it. The
same thing applies here - if you don't already know how PostgreSQL
works, you will by default install a database that's completely without
authentication.
//Magnus
