Thread: Re: pgsql: Fix backend crash in parsing incorrect tsquery.
On Mon, 12 Feb 2007, Teodor Sigaev wrote: > Log Message: > ----------- > Fix backend crash in parsing incorrect tsquery. > > Per report from Jon Rosebaugh <jon@inklesspen.com> Is this a security issue? Does it need a new security release? I hope that the answer is not "this is contrib, it isn't as important" since I have been trying to convince others that contrib is not less secure or well supported than core. If this is a security issue (and if it can crash the backend due to a function parameter, it probably is) the community response to it will be particularly compelling evidence. > Modified Files: > -------------- > pgsql/contrib/tsearch2: > query.c (r1.30 -> r1.31) > (http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/tsearch2/query.c.diff?r1=1.30&r2=1.31) > > -- Colvard's Logical Premises:All probabilities are 50%. Either a thing will happen or itwon't. Colvard's Unconscionable Commentary:This is especially true when dealing with someone you'reattracted to. Grelb's CommentaryLikelihoods, however, are 90% against you.
Jeremy Drake wrote: > On Mon, 12 Feb 2007, Teodor Sigaev wrote: > > Log Message: > > ----------- > > Fix backend crash in parsing incorrect tsquery. > > > > Per report from Jon Rosebaugh <jon@inklesspen.com> > > Is this a security issue? Does it need a new security release? We don't treat crashes to be security issues of the kind that calls for the full security exercise. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Tue, 13 Feb 2007, Peter Eisentraut wrote: > We don't treat crashes to be security issues of the kind that calls for > the full security exercise. But if a "security issue", by whatever definition of the term applies to core, is found in contrib, it would result in the full security exercise, correct? Of course, the people I am trying to convince that contrib is not insecure have yet to update their server with the latest security release (still running 8.1.3), so it is probably pretty much moot :) -- Anyone can hold the helm when the sea is calm. -- Publius Syrus
Jeremy Drake <pgsql@jdrake.com> writes:
> On Mon, 12 Feb 2007, Teodor Sigaev wrote:
>> Fix backend crash in parsing incorrect tsquery.
> Is this a security issue? Does it need a new security release?
We looked at this and determined that the worst that could be done with
it is crash the backend. Which is annoying, but if we treated every
such bug as a security exercise then we'd be having a new release every
week or so. Core's current policy is that we'll consider a bug worthy
of a security release if it can be used to force execution of arbitrary
code, access otherwise-unavailable information, etc. A simple crash is
at worst a momentary denial of service to other DB users, and if you've
got the ability to issue arbitrary SQL there are lots of ways to create
denial-of-service situations of one magnitude or another.
Also, recent history should impress on you the disadvantages of treating
problems as security exercises: patches that go in without any public
review or testing are far more likely to create new problems than those
that go through the normal process. So setting a low bar for what
constitutes a security issue is likely to decrease the system's overall
reliability.
regards, tom lane
On Mon, 12 Feb 2007, Tom Lane wrote: > Jeremy Drake <pgsql@jdrake.com> writes: > > On Mon, 12 Feb 2007, Teodor Sigaev wrote: > >> Fix backend crash in parsing incorrect tsquery. > > > Is this a security issue? Does it need a new security release? > > We looked at this and determined that the worst that could be done with > it is crash the backend. Which is annoying, but if we treated every > such bug as a security exercise then we'd be having a new release every > week or so. Core's current policy is that we'll consider a bug worthy > of a security release if it can be used to force execution of arbitrary > code, access otherwise-unavailable information, etc. A simple crash is > at worst a momentary denial of service to other DB users, and if you've > got the ability to issue arbitrary SQL there are lots of ways to create > denial-of-service situations of one magnitude or another. > > Also, recent history should impress on you the disadvantages of treating > problems as security exercises: patches that go in without any public > review or testing are far more likely to create new problems than those > that go through the normal process. So setting a low bar for what > constitutes a security issue is likely to decrease the system's overall > reliability. I understand. This is reasonable. I am glad that this was considered, and weighed against the same policy as core. -- Andrea: Unhappy the land that has no heroes. Galileo: No, unhappy the land that _____needs heroes. -- Bertolt Brecht, "Life of Galileo"