Обсуждение: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in

> -----Original Message-----
> From: Neil Conway [mailto:neilc@samurai.com]
> Sent: Monday, August 19, 2002 10:22 PM
> To: Mark Pritchard
> Cc: Justin Clift; Tom Lane; Christopher Kings-Lynne;
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] @(#) Mordred Labs advisory 0x0001:
> Buffer overflow in
>
>
> Mark Pritchard <mark@tangent.net.au> writes:
> > I believe its been said before, in this forum no less, that
> PostgreSQL
> > should focus on its primary role as an RDBMS and not be
> paranoid about
> > security. I believe it was the thread on SSL connections, and Tom
> > suggested a simple ssh tunnel or vpn.
>
> I'd say the two issues are pretty different. IMHO, buffer
> overruns and similar security problems are just a special
> class of software bug (it's interesting to note that most of
> the buffer overruns have been found in the less-maintained
> parts of the system, like the cash type or contrib/).
> Therefore, the justification for fixing buffer overruns (and
> avoiding them in the first place) is the same as for fixing
> other kinds of bugs: it makes the system more reliable.
>
> On the other hand, adding something like SSL tends to make
> the system more complex (and therefore *less* reliable).
> There may or may not be a pay-off from a user's POV, but it's
> not the clear win that avoiding buffer overruns is, IMHO.
>
> > Of course, lets not leave the door wide open, but perhaps the
> > developer's time would be better spent on features such as
> schemas and
> > replication.
>
> It's probably worth noting that the "barrier to entry" for
> fixing buffer overruns or doing a code audit is much, much
> lower than for implementing advanced features like schemas or
> replication. The main thing that auditing code requires is
> time, rather than coding skill/knowledge.

Most computer virus problems are caused by buffer overrun.  Someone
decided it wasn't very important.

Some computer viruses have caused billions of dollars in damage.  Sounds
important to me.

"Please try our database.  Someday, we hope to close off all the virus
entry points, but right now, we figure it isn't too important."

Will you trust your multi-million dollar database to someone who says
the above?  I think the priorities are upside down.  Any *known*
buffer-overrun _must_ be repaired, and as quickly as possible.  And
potential overruns should be identified.  A grep for memcpy, strcpy,
gets, etc. should hunt down most of them.  A known buffer overrun should
fill the designer of a product with abject terror.  And I really mean
that, literally.  If you *know* of a buffer overrun, and simply decide
not to fix it, that sounds very negligent to me.  For a public project
like PostgreSQL, there is probably very little liability for the
programmers, but I am thinking of the damage that can be inflicted upon
potential clients using the database.

"Dann Corbit" <DCorbit@connx.com> writes:
> If you *know* of a buffer overrun, and simply decide not to fix it,
> that sounds very negligent to me.

*sigh*, no one is doing that, and it is pure negligence on your part
for replying to a thread that you clearly have not read.

Cheers,

Neil

-- 
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC

On Tue, 20 Aug 2002 15:35, Dann Corbit wrote:
> Most computer virus problems are caused by buffer overrun.  Someone
> decided it wasn't very important.
>
> Some computer viruses have caused billions of dollars in damage.  Sounds
> important to me.
>
> "Please try our database.  Someday, we hope to close off all the virus
> entry points, but right now, we figure it isn't too important."

This sounds a little hysterical to me...don't happen to have a remotely
accessible database do you? :)

> Will you trust your multi-million dollar database to someone who says
> the above?  I think the priorities are upside down.  Any *known*
> buffer-overrun _must_ be repaired, and as quickly as possible.  And

As always, feedback accepted in diff -c format.

Seriously though, Oracle was unbreakable for what, two days? Software has
bugs. I'm sure there are a stack more in PostgreSQL.

You limit your exposure to bugs/defects/etc through the use of multiple layers
of protection. If you leave your database out in the wild, you deserve to be
hacked.

> potential overruns should be identified.  A grep for memcpy, strcpy,
> gets, etc. should hunt down most of them.  A known buffer overrun should
> fill the designer of a product with abject terror.  And I really mean
> that, literally.  If you *know* of a buffer overrun, and simply decide

I'd be worried if my IT consultants experienced "abject terror". I much prefer
them to be calm, safe in the knowledge that vulnerabilities such as this will
not cause me any problems, because they had the forethought to plan for
situations like this and limit their exposure.

I worry about two pieces of software - Apache and OpenSSH. I compile from
source, knowing that I can fix the issue (be it the recent issues with either
piece of software) as soon as the fixed source becomes available. I may be in
the minority, but at least I don't experience abject terror too often (well,
unless I let my sister drive my car...but that is another story).

Cheers

Mark

On Mon, Aug 19, 2002 at 22:35:26 -0700,
> 
> Most computer virus problems are caused by buffer overrun.  Someone
> decided it wasn't very important.

I disaggree with this. Most computer viruses that I see are rely on
poorly designed software and poorly trained users to propagate.

Buffer overruns are used by worms and by some tools designed to get unauthorized
access to machines.

On Tue, 2002-08-20 at 00:35, Dann Corbit wrote:
>
> Most computer virus problems are caused by buffer overrun.  Someone
> decided it wasn't very important.

This is true.  IMO, it is extremely arrogant to ignore a buffer overrun
and announce it can't be exploited.  There is many cases where this
assertion has been proved to be false.  The real risk of overrun is not
what you think can be done with it (or lack there of), rather, it's how
someone else might decide to use it in some obscure manner which you can
not currently fathom or foresee.

> Will you trust your multi-million dollar database to someone who says
> the above?  I think the priorities are upside down.  Any *known*
> buffer-overrun _must_ be repaired, and as quickly as possible.  And

I agree with that too.  When setting priorities, using a scale of 1-10,
10 being highest priority, anything that effects stability or
reliability should always be a 10.  As such, they should always be
repaired even above new wiz-bang features.

IMO, if you don't embrace that rule of thumb, a developer shouldn't be
working on a project where stability and reliability are key components
of the end product.

> potential overruns should be identified.  A grep for memcpy, strcpy,
> gets, etc. should hunt down most of them.  A known buffer overrun should
> fill the designer of a product with abject terror.  And I really mean

Agreed.  It is horribly irresponsible to thumb a nose at such things in
this day and age.

> that, literally.  If you *know* of a buffer overrun, and simply decide
> not to fix it, that sounds very negligent to me.  For a public project
> like PostgreSQL, there is probably very little liability for the
> programmers, but I am thinking of the damage that can be inflicted upon
> potential clients using the database.
>

Not a question of it sounding negligent.  It is negligent.

If quality and stability is not the core developers #1 goal then
expecting people to trust the resulting product is laughable.  Please
tell me why anyone should use a database to maintain important data when
quality and stability is not important to the developers of such a
product.  It's an oxymoron.

Time and time again I've read what basically amounts to, "...if someone
can crash it it's because someone is stupid enough to allow someone to
be able to do it in the first place..."  Maybe you're right.  After all,
if core developers continue to turn a blind eye to such issues, they are
in fact, the facilitators of allowing people to do it to begin with.
That is, they are the ones that allowing people to do it in the first
place.  In short, every time I see that response, I immediately think,
"...now that's the pot calling the kettle black."

At some point in time, you have to stand and say, "the buck stops here."

Now then, after that long rant and rave, since these are known issues, I
don't have a problem with the next release going out as planned.  Once
it does go out, I would certainly hope that the developers would
readjust their priorities and target a bug fix release to immediately
follow.

You know, I've seen many people trash Oracle's "unbreakable" mantra.
I'm sure no one is confused at the fact that it is nothing but a
marketing ploy, however, perhaps there is a culture behind it.  Perhaps
this is their way of saying stability and reliability is very important
to them.  Perhaps their mantra is the rule of thumb outlined above.

Sign,
Greg Copeland

On Tue, 20 Aug 2002 23:48, Greg Copeland wrote:
> On Tue, 2002-08-20 at 00:35, Dann Corbit wrote:
> > Most computer virus problems are caused by buffer overrun.  Someone
> > decided it wasn't very important.
>
> This is true.  IMO, it is extremely arrogant to ignore a buffer overrun
> and announce it can't be exploited.  There is many cases where this
> assertion has been proved to be false.  The real risk of overrun is not

I would certainly hope you are not misquoting me here. I have never stated we
should ignore the bug. I suggested that with proper network level protection,
the bug should not be exploitable.

If you did indeed misquote me, perhaps extreme arrogance in this case is the
attribution of comments to people without basis?

> I agree with that too.  When setting priorities, using a scale of 1-10,
> 10 being highest priority, anything that effects stability or
> reliability should always be a 10.  As such, they should always be
> repaired even above new wiz-bang features.

So, cutting through the self-supporting hyperbole, you believe that stability
or reliability is more important than new features. I don't disagree. What I
do disagree with is the "panic" mentality that seems so evident in this type
of post.

If you have set up your production infrastructure in a sensible manner (of
course sensible is open for interpretation), this bug does not affect you.

This does highlight the root cause of our difference in opinions - I don't
feel this is an issue because it doesn't affect me. You may be concerned by
these issues because your infrastructure allows the general 'net using public
to directly access your database. While I disagree with this
configuration...it doesn't make you fundamentely wrong, simply different in
our respective approaches.

> IMO, if you don't embrace that rule of thumb, a developer shouldn't be
> working on a project where stability and reliability are key components
> of the end product.

I wasn't aware that PostgreSQL as an open source collaborative project had any
specific requirements of upon it at all. While stability and reliability are
obvious goals, if you feel the project does not meet your needs you are more
than welcome to try one of the alternatives. MySQL for example :)

Seriously though, its similar to the people who run Linus' kernels. Oh my god
they say, the stable 2.4.x series has VM issues. We can't trust it anymore!

Why are you using that kernel in the first place? Where has Linus said that
this is suitable for production use? Stable does not mean "production ready".

> > potential overruns should be identified.  A grep for memcpy, strcpy,
> > gets, etc. should hunt down most of them.  A known buffer overrun should
> > fill the designer of a product with abject terror.  And I really mean
>
> Agreed.  It is horribly irresponsible to thumb a nose at such things in
> this day and age.

I'm not going to restate my previous response to this view, but I will ask,
who is affected by the "horribly irresponsible" approach? If it is you, then
why hasn't your due dilligence process audited the code? Perhaps you would
feel more comfortable with one of the closed source/closed development model
organisations? But what bugs lie within the depths of DBs such as SQL Server?
How will you audit those? Or will you just trust the sales guy?

> > programmers, but I am thinking of the damage that can be inflicted upon
> > potential clients using the database.
>
> Not a question of it sounding negligent.  It is negligent.
>
> If quality and stability is not the core developers #1 goal then
> expecting people to trust the resulting product is laughable.  Please

Where is an expectation at all? If you want to use PostgreSQL, then use it. If
it doesn't meet your needs, don't use it, or start fixing the issues
yourself. If you can't do it, buy Oracle, or DB2, or whatever else.

> Time and time again I've read what basically amounts to, "...if someone
> can crash it it's because someone is stupid enough to allow someone to
> be able to do it in the first place..."  Maybe you're right.  After all,
> if core developers continue to turn a blind eye to such issues, they are
> in fact, the facilitators of allowing people to do it to begin with.

I'm not sure how you make the jump from knowing that an issue exists and
allowing people to exploit it, to the inference that core developers are
turning a blind eye to it. Forgive me if I misquote you Tom, but I don't
think he has ever said "we should not fix this bug", simply that the effort
is significant, and there are other factors to consider.

> You know, I've seen many people trash Oracle's "unbreakable" mantra.
> I'm sure no one is confused at the fact that it is nothing but a
> marketing ploy, however, perhaps there is a culture behind it.  Perhaps
> this is their way of saying stability and reliability is very important
> to them.  Perhaps their mantra is the rule of thumb outlined above.

Perhaps we need a pgsql-hackers-heated_discussions list so we can take these
discussions offline? :)

Cheers

Mark

greg@CopelandConsulting.Net (Greg Copeland) wrote

> Time and time again I've read what basically amounts to, "...if someone
> can crash it it's because someone is stupid enough to allow someone to
> be able to do it in the first place..."  Maybe you're right.  After all,
> if core developers continue to turn a blind eye to such issues, they are
> in fact, the facilitators of allowing people to do it to begin with.=20
> That is, they are the ones that allowing people to do it in the first
> place.  In short, every time I see that response, I immediately think,
> "...now that's the pot calling the kettle black."
> 
> At some point in time, you have to stand and say, "the buck stops here."
> 

I agree here, but at the same time you cannot put 100% of the 
responsibility on the developers.  If you are the dba/sysadmin/whatever/etc 
then it is your responsibility.  It is up to you to know about potential 
problems and have workarounds or whatever it is you need to do.  I think 
that is one of the things that seperates a "good" admin from a "not-so-
good" one.

Afterall, when your boss calls you into his office monday morning and asks 
for a really good explanation for why the db was cracked, I dont think he 
is going to accept the excuse "this guy, you dont know him but his name is 
tom lane.. well anyway, he didnt fix this bug i knew about so i didnt do 
nothing about it because i shouldnt have to because that would be like the 
pot calling the kettle black"

That being said, I do agree the developers should give things like this 
more priority.  But, its open source...  so you either live with it or 
write your own patch.

On Tue, 2002-08-20 at 18:40, Mark Pritchard wrote:
> On Tue, 20 Aug 2002 23:48, Greg Copeland wrote:
> > On Tue, 2002-08-20 at 00:35, Dann Corbit wrote:
> > > Most computer virus problems are caused by buffer overrun.  Someone
> > > decided it wasn't very important.
> >
> > This is true.  IMO, it is extremely arrogant to ignore a buffer overrun
> > and announce it can't be exploited.  There is many cases where this
> > assertion has been proved to be false.  The real risk of overrun is not
>
> I would certainly hope you are not misquoting me here. I have never stated we
> should ignore the bug. I suggested that with proper network level protection,
> the bug should not be exploitable.

Don't think I quoted you at all.  I don't see quotation marks and am
including Dan's remark.  Perhaps everyone isn't talking about you after
all.  Continue with the green pills.  ;)

> do disagree with is the "panic" mentality that seems so evident in this type
> of post.

Hmmm.  Interesting.  I didn't see panic or anything alarmist in my post.

>
>
> > IMO, if you don't embrace that rule of thumb, a developer shouldn't be
> > working on a project where stability and reliability are key components
> > of the end product.
>
> I wasn't aware that PostgreSQL as an open source collaborative project had any
> specific requirements of upon it at all. While stability and reliability are
> obvious goals, if you feel the project does not meet your needs you are more
> than welcome to try one of the alternatives. MySQL for example :)

In other words, if someone if verbal about development goals or
objectives they should go elsewhere.

As for specific requirements, I've said nothing which are not inherently
obvious.  Without a stable and reliable product, no one is going to use
it for serious work.  As such, it's certainly not a leap of faith to
assume that developers without such ideals in mind should be shunned or
properly guided.  Why?  Obviously (amazed I have to spell this out),
said developer efforts would be counter to the project's objectives
(stated or otherwise implicitly obvious).

You also seem to imply that "open source collaborative project[s]"
should not aim for high goals.  I think it's safe to say, we disagree.

> I'm not going to restate my previous response to this view, but I will ask,
> who is affected by the "horribly irresponsible" approach? If it is you, then
> why hasn't your due dilligence process audited the code? Perhaps you would
> feel more comfortable with one of the closed source/closed development model
> organisations? But what bugs lie within the depths of DBs such as SQL Server?
> How will you audit those? Or will you just trust the sales guy?

Hmm.  Keep a blind and pretend it doesn't exist.  Not a good response.
Since this thread came out of someone's dilligence (coders or
otherwise), I fail to see the significance of your comments.  After all,
mucho-peer review is supposed to be one of the perks of using OSS
software.  Considering I'm not asserted I'm performance a code audit,
this seems completely unrelated to the topic at hand.

> Where is an expectation at all? If you want to use PostgreSQL, then use it. If
> it doesn't meet your needs, don't use it, or start fixing the issues
> yourself. If you can't do it, buy Oracle, or DB2, or whatever else.

In other words, if someone if verbal about development goals they should
go elsewhere.  Furthermore, you seem to assert that only the core
developers should be using this database.  Wow, I'm amazed.  Just
because someone does or does not contributes code doesn't suddenly
invalidate observations.  That, of course, doesn't mean the observations
have to be valid.

Simply stated, if it meets my needs, shut-up and use it.  If it doesn't,
go elsewhere.  Bad attitude.

> I'm not sure how you make the jump from knowing that an issue exists and
> allowing people to exploit it, to the inference that core developers are
> turning a blind eye to it. Forgive me if I misquote you Tom, but I don't
> think he has ever said "we should not fix this bug", simply that the effort
> is significant, and there are other factors to consider.

Because it was stated that these are known issues.  Because it was
stated these have been known issues for a very long time.  Because it
was stated that, more or less, no one is excited about doing the lots of
effort which is seemingly required to put some of these issues to bed.

The expression, "turning a blind eye", means that something is being
ignored.  It means it won't be focused on for now.  That does not have
to mean forever.  The statement is valid and supported by pretty much
every posting on this list on the topic at hand.  I stand by my
statement.

Stop with the misquoting comments already.  The quotes I used were
properly attributed.   Believe it or not, everyone is not talking about
you or trying to place words in your mouth.  Believe it or not, the
quotes are correct.  I have no idea what you're talking about.

> Perhaps we need a pgsql-hackers-heated_discussions list so we can take these
> discussions offline? :)
>

I'm concerned that you feel comments on corporate culture should be
considered a heated discussion.  I in no way, shape or form, asserted
anything other then perhaps there is a cultural emphasis behind the
marketing ploy.  You can say no and I can say maybe all day long.
Either way, that's hardly heated.

Somewhere around here, we've wondered from the road.

Regards,
Greg Copeland

On Tue, 2002-08-20 at 19:59, ngpg@grymmjack.com wrote:
> greg@CopelandConsulting.Net (Greg Copeland) wrote
> > At some point in time, you have to stand and say, "the buck stops here."
> >
>
> I agree here, but at the same time you cannot put 100% of the
> responsibility on the developers.  If you are the dba/sysadmin/whatever/etc
> then it is your responsibility.  It is up to you to know about potential
> problems and have workarounds or whatever it is you need to do.  I think
> that is one of the things that seperates a "good" admin from a "not-so-
> good" one.

I absolutely agree.  I was not trying to say that bugs don't happen and
that sometimes those bugs may cause crashes.  What I was trying to say
is what amounts to, "dr, when I move my arm like this, it hurts", and
the response is, "don't do that."  Humor aside, surely there has to be a
happy medium in between.  Perhaps, with a skewing toward fixing rather
than prescribing.  ;)

>
> Afterall, when your boss calls you into his office monday morning and asks
> for a really good explanation for why the db was cracked, I dont think he
> is going to accept the excuse "this guy, you dont know him but his name is

I understand and agree with ya.

>
> That being said, I do agree the developers should give things like this
> more priority.  But, its open source...  so you either live with it or
> write your own patch.
>

Well, the priority portion was what I was shooting for.  Perhaps it came
off being over zealous.  I'm not really sure.  I re-read it and I didn't
think so.  But, I'm not you and you're not me...so, it's hard to say how
exactly it was received.

As for the open source comment, that fine and all...but...there are
companies which are paying for postgres' development too.  Some of the
developers are being paid to do this.  The "write your own patch" has
much more meaning on simple projects.  For a project as complex as
postgres, simply asking for a patch is almost meaningless.  Along those
lines, I have been reading (code and the list) and learning for sometime
now, as time allows.  One day, I will contribute significant patches.
However, until that day comes, I would hope that observational
commentary is simply not invalidated just because they're not one with
the code yet.


Regards,
Greg Copeland