Thread: Re: [pgsql-advocacy] MySQL worm attacks Windows servers
Cross-posting to general due to more general nature of response Josh Berkus wrote: >Chris, > > > >>http://www.theregister.co.uk/2005/01/28/mysql_worm/ >> >> > >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/
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
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
On Sun, Jan 30, 2005 at 06:05:37PM -0500, Greg Stark wrote: > 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. While true, I think an argument can be made to notify as many people as possible and posting to -core means a message is more likely to go -announce where more PostgreSQL admins will see it. It's possible not all admins will be reading -general. > 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). Sure. Actually for something as obvious as trusting network access I'd actually assume the person posting it would be smart enough to point out the solution as well. While I'm for public disclosure in general I do think 24 hour notice is not too much to ask for. And hey, given the volume of -general sending to security@ might get it read a little earlier by people who can do something than just dumping on the mailing list. My preferred scenario would be to actually ring someone in -core on the phone and discuss it directly and work it out from there. But I don't know the chances of that. At the end of the day the people making the disclosure make the decision, our discussing it won't make a difference there... :) Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Attachment
On 1/30/2005 10:18 AM, Peter Eisentraut 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. > No, Peter. Posting a vulnerability on a public mailing list "before" there is a known fix for it means that you put everyone who has that vulnerability into jeopardy. Vulnerabilities are a special breed of bugs and need to be exterminated a little different. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Jan Wieck wrote: > On 1/30/2005 10:18 AM, Peter Eisentraut 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. >> > > No, Peter. > > Posting a vulnerability on a public mailing list "before" there is a > known fix for it means that you put everyone who has that vulnerability > into jeopardy. Vulnerabilities are a special breed of bugs and need to > be exterminated a little different. > > > Jan > ain't that the truth. if a vulnerability is found, try to find a fix, or work around, post it privately to the developer, give them an opportunity to get it fixed before going public. when dealing with open souurce, this system works great. when dealing with proprietary / closed source [ specifically microsoft ] expect that it's the public announcement that's going to start them doing something about it. I personally would only give ms a week at most to fix the problem before going public. since open source if usually fixed in that time frame. Jaqui
Jan Wieck <JanWieck@Yahoo.com> writes: > No, Peter. > > Posting a vulnerability on a public mailing list "before" there is a known fix > for it means that you put everyone who has that vulnerability into jeopardy. > Vulnerabilities are a special breed of bugs and need to be exterminated a > little different. Many people disagree with this. Posting the vulnerability isn't what puts people into jeopardy, the presence of the vulnerability puts people in jeopardy. Posting it at least allows people to disable the feature or close off access. Or at least monitor for possible intrusions. Not posting it leaves people in jeopardy and in the dark about it. If you think you're the first one to find the vulnerability you're probably wrong. Often malicious hackers who search for vulnerabilities find them and keep them secret long before they're reported. How would you feel if your system was compromised and then you found out later that it was a known security hole in a feature you had no need for and the vulnerability had been kept secret? This is really the wrong place to have such a debate. This is a long-standing debate and one that you should at just recognize exists. Don't present one side as dogma. -- greg
On 2/6/2005 4:31 PM, Greg Stark wrote: > Jan Wieck <JanWieck@Yahoo.com> writes: > >> No, Peter. >> >> Posting a vulnerability on a public mailing list "before" there is a known fix >> for it means that you put everyone who has that vulnerability into jeopardy. >> Vulnerabilities are a special breed of bugs and need to be exterminated a >> little different. > > Many people disagree with this. Posting the vulnerability isn't what puts > people into jeopardy, the presence of the vulnerability puts people in > jeopardy. Posting it at least allows people to disable the feature or close > off access. Or at least monitor for possible intrusions. Not posting it leaves > people in jeopardy and in the dark about it. > > If you think you're the first one to find the vulnerability you're probably > wrong. Often malicious hackers who search for vulnerabilities find them and > keep them secret long before they're reported. > > How would you feel if your system was compromised and then you found out later > that it was a known security hole in a feature you had no need for and the > vulnerability had been kept secret? It's interesting that everyone advocating for "immediate public report" is allways talking about vulnerabilities that can be taken care of by disabling some unused feature. What do you do if you find a vulnerability in the text/varchar data type multibyte handling? Still tell the world about it before having a fix? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #