MySQL worm attacks Windows servers
Chris,
Yep. And each time someone asks you "But why can't I install PostgreSQL as
Administrator" you can point them to that worm ....
--
Josh Berkus
Aglio Database Solutions
San Francisco
Cross-posting to general due to more general nature of response
Josh Berkus wrote:
Chris,
Yep. And each time someone asks you "But why can't I install PostgreSQL as
Administrator" you can point them to that worm ....
Now, if PostgreSQL is installed with TRUST authentication for remote
ports, can't one try to create an untrusted language and function that
will cause the sustem to scan for other such servers and connect,
thereby spreading a worm? Of course most of the PostgreSQL instances I
have seen are behind firewalls, but I don't think we are that invulnerable.
Maybe we should set the default authentication to only use TRUST on
local sockets only. At least as of 7.4, the default was to trust
network ports.
Best Wishes,
Chris Travers
Metatron Technology Consulting
On Sat, Jan 29, 2005 at 00:34:07 -0800,
Chris Travers <chris@travelamericas.com> wrote:
Maybe we should set the default authentication to only use TRUST on
local sockets only. At least as of 7.4, the default was to trust
network ports.
I believe the previous default was not to allow network connections
by default. For 8.0 only network connections from localhost are allowed
by default.
No one in their right mind is going to use trust authentication on
connections from random IP addresses. And in most cases they aren't
even going to allow connections from random IP addresses.
Chris Travers <chris@travelamericas.com> writes:
Maybe we should set the default authentication to only use TRUST on
local sockets only. At least as of 7.4, the default was to trust
network ports.
Perhaps you should check your facts before posting.
regards, tom lane
Chris,
Maybe we should set the default authentication to only use TRUST on
local sockets only. At least as of 7.4, the default was to trust
network ports.
If you know of a PostgreSQL package, from any source, that installs with trust
on network ports, please notify Core (and Core only, please).
--
Josh Berkus
Aglio Database Solutions
San Francisco
Tom Lane wrote:
Chris Travers <chris@travelamericas.com> writes:
Maybe we should set the default authentication to only use TRUST on
local sockets only. At least as of 7.4, the default was to trust
network ports.Perhaps you should check your facts before posting.
Ok. Pardon me. I misread the file. I apologize.
Best Wishes,
Chris Travers
Josh Berkus wrote:
If you know of a PostgreSQL package, from any source, that installs with trust
on network ports, please notify Core (and Core only, please).
Why only -core?
-Neil
On Sun, 30 Jan 2005 20:23:15 +1100, Neil Conway <neilc@samurai.com> wrote:
Josh Berkus wrote:
If you know of a PostgreSQL package, from any source, that installs with trust
on network ports, please notify Core (and Core only, please).Why only -core?
I think it is in good taste that when you find a bug/vulnerability/etc
first you contact the author (in this case: core), leave them some
time to fix the problem and then go on announcing it to the
world.
I think it is perfectly reasonable!
Regards,
Dawid
Dawid Kuroczko wrote:
I think it is in good taste that when you find a
bug/vulnerability/etc first you contact the author (in this case:
core), leave them some time to fix the problem and then go on
announcing it to the
world.
In this case, core is not the author of the object in question. And of
course, to report a "bug/vulnerability/etc" you would write to
pgsql-bugs, not core.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Sun, 30 Jan 2005 16:18:53 +0100, Peter Eisentraut <peter_e@gmx.net> wrote:
Dawid Kuroczko wrote:
I think it is in good taste that when you find a
bug/vulnerability/etc first you contact the author (in this case:
core), leave them some time to fix the problem and then go on
announcing it to the
world.In this case, core is not the author of the object in question. And of
course, to report a "bug/vulnerability/etc" you would write to
pgsql-bugs, not core.
Well, if some pgsql distribution (say a Foo Package Manager packet
for FooBar *nix) has a modified pg_hba.conf then indeed this
FooBar *nix can be considered as pg_hba.conf's author.
Anyhow I still think >>core<< can be considered as original
author of pg_hba.conf default contents.
...and right you are, pgsql-bugs is the right place.
But all this discussion is getting pointless so I shall from now on
abstain from sending to this thread. ;)
Regards,
Dawid
Peter Eisentraut <peter_e@gmx.net> writes:
Dawid Kuroczko wrote:
I think it is in good taste that when you find a
bug/vulnerability/etc first you contact the author (in this case:
core), leave them some time to fix the problem and then go on
announcing it to the
world.
In this case, core is not the author of the object in question. And of
course, to report a "bug/vulnerability/etc" you would write to
pgsql-bugs, not core.
Josh's point is that if you don't want to publicize a vulnerability
to the entire world in advance of there being any chance to fix it,
you don't send your report to an open, publicly-archived bugs list.
We don't really have an official security contact. The next best thing
is to send such reports to pgsql-core, which is not an open list, but
will reach a good chunk of those with an interest in fixing such
problems.
regards, tom lane
On Sun, Jan 30, 2005 at 12:55:28PM -0500, Tom Lane wrote:
We don't really have an official security contact. The next best thing
is to send such reports to pgsql-core, which is not an open list, but
will reach a good chunk of those with an interest in fixing such
problems.
IMHO this fact should be more clearly announced somewhere on the
website. A little phrase like "Please send security vulnerability
reports to pgsql-core@postgresql.org" at the top of the developer's page
should do.
--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Some men are heterosexual, and some are bisexual, and some
men don't think about sex at all... they become lawyers" (Woody Allen)
Tom,
We don't really have an official security contact. The next best thing
is to send such reports to pgsql-core, which is not an open list, but
will reach a good chunk of those with an interest in fixing such
problems.
Is there any reason not to set up a "security@postgresql.org" mail alias?
--
Josh Berkus
Aglio Database Solutions
San Francisco
where should it be aliased to? pgsql-core?
On Sun, 30 Jan 2005, Josh Berkus wrote:
Tom,
We don't really have an official security contact. The next best thing
is to send such reports to pgsql-core, which is not an open list, but
will reach a good chunk of those with an interest in fixing such
problems.Is there any reason not to set up a "security@postgresql.org" mail alias?
--
Josh Berkus
Aglio Database Solutions
San Francisco---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Josh Berkus <josh@agliodbs.com> writes:
We don't really have an official security contact. The next best thing
is to send such reports to pgsql-core, which is not an open list, but
will reach a good chunk of those with an interest in fixing such
problems.
Is there any reason not to set up a "security@postgresql.org" mail alias?
Probably not --- Marc, do you want to do that (and make it point to
pgsql-core for now)?
I was just in the middle of adding notes to problems.sgml and
bug.template to tell people to send security issues to pgsql-core,
but I can make it say security@ instead.
regards, tom lane
Tom Lane wrote:
Is there any reason not to set up a "security@postgresql.org" mail
alias?Probably not --- Marc, do you want to do that (and make it point to
pgsql-core for now)?
I think this is a good idea. But note that mail addressed to pgsql-core
will be held up in the moderator queue. I'm not sure that we want that
for mail addressed to security@.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes:
Probably not --- Marc, do you want to do that (and make it point to
pgsql-core for now)?
I think this is a good idea. But note that mail addressed to pgsql-core
will be held up in the moderator queue. I'm not sure that we want that
for mail addressed to security@.
That's something that can and should be dealt with behind the scenes,
though. The immediate point is to agree on having this alias.
I'm about to commit documentation updates into all the upcoming release
branches recommending security@postgresql.org for security-sensitive
reports.
regards, tom lane
On Sun, 30 Jan 2005, Tom Lane wrote:
Josh Berkus <josh@agliodbs.com> writes:
We don't really have an official security contact. The next best thing
is to send such reports to pgsql-core, which is not an open list, but
will reach a good chunk of those with an interest in fixing such
problems.Is there any reason not to set up a "security@postgresql.org" mail alias?
Probably not --- Marc, do you want to do that (and make it point to
pgsql-core for now)?I was just in the middle of adding notes to problems.sgml and
bug.template to tell people to send security issues to pgsql-core,
but I can make it say security@ instead.
Consider it done ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Dawid Kuroczko <qnex42@gmail.com> writes:
Why only -core?
I think it is in good taste that when you find a bug/vulnerability/etc
first you contact the author (in this case: core), leave them some
time to fix the problem and then go on announcing it to the
world.I think it is perfectly reasonable!
In case there are some that are not aware, this is a matter of some
controversy. Many people believe it better to disclose vulnerabilities
publicly.
There are always ways for a sysadmin to close the vulnerability, even if it
means temporarily limiting access until the fix is available. How would you
like to be a sysadmin that finds his system exploited only to discover that
the vulnerability was known and he could have worked around it had he been
informed but those in the know kept it secret until a patch was published.
The only way keeping it secret is really justified is if a) You know no
malicious persons are aware of the vulnerability (which of course one never
really knows for certain) b) it's more reasonable for a sysadmin to run with
the vulnerability than to work around it using whatever means necessary (and
you feel comfortable making that decision for every sysadmin everywhere).
There are certainly others that disagree but I think history shows that when
vulnerabilities are disclosed in full sysadmins can react more effectively and
vendors release fixes faster and the net result is fewer compromises and
better software.
Of course in this case the argument that Postgres would have responded quicker
had the vulnerability been known is almost certainly baseless. And it may turn
out to be the case that there were no compromises because not a single
malicious user knew about the hole. It doesn't always work out that way
though.
--
greg
