
Surprised it took this long.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
         56K Nationwide Dialup from $16.00/mo at Pop4 Networking
      http://www.camping-usa.com      http://www.cloudninegifts.com
   http://www.meanstreamradio.com       http://www.unknown-artists.com
==========================================================================



---------- Forwarded message ----------
Date: Mon, 19 Aug 2002 15:40:28 +0000
From: Sir Mordred The Traitor <mordred@s-mail.com>
To: bugtraq@securityfocus.com
Subject: @(#) Mordred Labs advisory 0x0001: Buffer overflow in PostgreSQL

// @(#) Mordred Labs Advisory 0x0001

Release data: 19/08/02
Name: Buffer overflow in PostgreSQL
Versions affected: <= 7.2
Risk: average

--[ Description:
PostgreSQL is an advanced object-relational database management system
that supports an extended subset of the SQL standard, including
transactions,
foreign keys, subqueries, triggers, user-defined types and functions.

There exists a stack based buffer overflow in cash_words() function, that
potentially allows an attacker to execute malicious code.

--[ How to reproduce:
psql> select cash_words('-700000000000000000000000000000');
pgReadData() -- backend closed the channel unexpectedly.
	.... ....
The connection to the server was lost...

--[ Solution:
Upgrade to version 7.2.1.




________________________________________________________________________
This letter has been delivered unencrypted. We'd like to remind you that
the full protection of e-mail correspondence is provided by S-mail
encryption mechanisms if only both, Sender and Recipient use S-mail.
Register at S-mail.com: http://www.s-mail.com/inf/en


Mon, 19 Aug 2002 12:44:33 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
@(#) Mordred Labs advisory 0x0001: Buffer overflow in PostgreSQL
 (fwd)
Hi Vince,

Glad he made the advisory for something there's a fix for.  :)

Regards and best wishes,

Justin Clift


Vince Vielhaber wrote:
> 
> Surprised it took this long.
> 
> Vince.
> --
> ==========================================================================
> Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
>          56K Nationwide Dialup from $16.00/mo at Pop4 Networking
>       http://www.camping-usa.com      http://www.cloudninegifts.com
>    http://www.meanstreamradio.com       http://www.unknown-artists.com
> ==========================================================================
> 
> ---------- Forwarded message ----------
> Date: Mon, 19 Aug 2002 15:40:28 +0000
> From: Sir Mordred The Traitor <mordred@s-mail.com>
> To: bugtraq@securityfocus.com
> Subject: @(#) Mordred Labs advisory 0x0001: Buffer overflow in PostgreSQL
> 
> // @(#) Mordred Labs Advisory 0x0001
> 
> Release data: 19/08/02
> Name: Buffer overflow in PostgreSQL
> Versions affected: <= 7.2
> Risk: average
> 
> --[ Description:
> PostgreSQL is an advanced object-relational database management system
> that supports an extended subset of the SQL standard, including
> transactions,
> foreign keys, subqueries, triggers, user-defined types and functions.
> 
> There exists a stack based buffer overflow in cash_words() function, that
> potentially allows an attacker to execute malicious code.
> 
> --[ How to reproduce:
> psql> select cash_words('-700000000000000000000000000000');
> pgReadData() -- backend closed the channel unexpectedly.
>         .... ....
> The connection to the server was lost...
> 
> --[ Solution:
> Upgrade to version 7.2.1.
> 
> ________________________________________________________________________
> This letter has been delivered unencrypted. We'd like to remind you that
> the full protection of e-mail correspondence is provided by S-mail
> encryption mechanisms if only both, Sender and Recipient use S-mail.
> Register at S-mail.com: http://www.s-mail.com/inf/en
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
   - Indira Gandhi

Tue, 20 Aug 2002 02:51:30 +1000
Justin Clift <justin@postgresql.org>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 
Justin Clift <justin@postgresql.org> writes:
> Glad he made the advisory for something there's a fix for.  :)

The claim that this bug allows execution of arbitrary code is bogus anyway.
The overflow at INT_MIN will clobber the stack, yes, but in an absolutely
predetermined way; an attacker will have no opportunity to insert code
of his choosing.

			regards, tom lane

Mon, 19 Aug 2002 14:24:08 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 
Vince,

Do you reckon it's worth you responding to "Sir Mordred" and pointing
out that he overstated the vulnerability?

:-)

Regards and best wishes,

Justin Clift


Tom Lane wrote:
> 
> Justin Clift <justin@postgresql.org> writes:
> > Glad he made the advisory for something there's a fix for.  :)
> 
> The claim that this bug allows execution of arbitrary code is bogus anyway.
> The overflow at INT_MIN will clobber the stack, yes, but in an absolutely
> predetermined way; an attacker will have no opportunity to insert code
> of his choosing.
> 
>                         regards, tom lane

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
   - Indira Gandhi

Tue, 20 Aug 2002 08:56:02 +1000
Justin Clift <justin@postgresql.org>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tue, 20 Aug 2002, Justin Clift wrote:

> Vince,
>
> Do you reckon it's worth you responding to "Sir Mordred" and pointing
> out that he overstated the vulnerability?

Not me.  Tom (pref) or Marc would be the proper respondent.

>
> :-)
>
> Regards and best wishes,
>
> Justin Clift
>
>
> Tom Lane wrote:
> >
> > Justin Clift <justin@postgresql.org> writes:
> > > Glad he made the advisory for something there's a fix for.  :)
> >
> > The claim that this bug allows execution of arbitrary code is bogus anyway.
> > The overflow at INT_MIN will clobber the stack, yes, but in an absolutely
> > predetermined way; an attacker will have no opportunity to insert code
> > of his choosing.
> >
> >                         regards, tom lane
>
>


Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
         56K Nationwide Dialup from $16.00/mo at Pop4 Networking
      http://www.camping-usa.com      http://www.cloudninegifts.com
   http://www.meanstreamradio.com       http://www.unknown-artists.com
==========================================================================




Mon, 19 Aug 2002 18:59:44 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
> On Tue, 20 Aug 2002, Justin Clift wrote:
> 
> > Vince,
> >
> > Do you reckon it's worth you responding to "Sir Mordred" and pointing
> > out that he overstated the vulnerability?
> 
> Not me.  Tom (pref) or Marc would be the proper respondent.

Has it actually been fixed?

Chris


Tue, 20 Aug 2002 09:36:16 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Christopher Kings-Lynne wrote:
> 
> > On Tue, 20 Aug 2002, Justin Clift wrote:
> >
> > > Vince,
> > >
> > > Do you reckon it's worth you responding to "Sir Mordred" and pointing
> > > out that he overstated the vulnerability?
> >
> > Not me.  Tom (pref) or Marc would be the proper respondent.
> 
> Has it actually been fixed?

The TODO list only mentions the cash_out(2) problem, whilst the email
archives mention them both.

 From the info still around, this looks to mean that the cash_words()
problem was fixed, but the cash_out() problem was harder to fix.

Tom/Bruce, is that correct?

+ Justin
 
> Chris

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
   - Indira Gandhi

Tue, 20 Aug 2002 11:51:35 +1000
Justin Clift <justin@postgresql.org>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Vince Vielhaber wrote:
> 
> Surprised it took this long.

Yes, me too, and it says the solution is to upgrade to 7.2.1.  Nope.


> ---------- Forwarded message ----------
> Date: Mon, 19 Aug 2002 15:40:28 +0000
> From: Sir Mordred The Traitor <mordred@s-mail.com>
> To: bugtraq@securityfocus.com
> Subject: @(#) Mordred Labs advisory 0x0001: Buffer overflow in PostgreSQL
> 
> // @(#) Mordred Labs Advisory 0x0001
> 
> Release data: 19/08/02
> Name: Buffer overflow in PostgreSQL
> Versions affected: <= 7.2
> Risk: average
> 
> --[ Description:
> PostgreSQL is an advanced object-relational database management system
> that supports an extended subset of the SQL standard, including
> transactions,
> foreign keys, subqueries, triggers, user-defined types and functions.
> 
> There exists a stack based buffer overflow in cash_words() function, that
> potentially allows an attacker to execute malicious code.
> 
> --[ How to reproduce:
> psql> select cash_words('-700000000000000000000000000000');
> pgReadData() -- backend closed the channel unexpectedly.
> 	.... ....
> The connection to the server was lost...
> 
> --[ Solution:
> Upgrade to version 7.2.1.
> 
> 
> 
> 
> ________________________________________________________________________
> This letter has been delivered unencrypted. We'd like to remind you that
> the full protection of e-mail correspondence is provided by S-mail
> encryption mechanisms if only both, Sender and Recipient use S-mail.
> Register at S-mail.com: http://www.s-mail.com/inf/en
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 19 Aug 2002 22:28:58 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Has it actually been fixed?

I couldn't reproduce a problem with his example.  The buffer size in
cash_words is awfully tight though --- it's dimensioned 128 which looks
like a round number rather than a carefully calculated one, and the
required size is at least 115.  I was thinking of bumping it up to 256
just to be sure.

			regards, tom lane

Mon, 19 Aug 2002 22:30:26 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 
Justin Clift wrote:
> Hi Vince,
> 
> Glad he made the advisory for something there's a fix for.  :)

Oh, I see he jumpe on cash_words() and didn't mention cash_out.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 19 Aug 2002 22:30:47 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Justin Clift wrote:
> Christopher Kings-Lynne wrote:
> > 
> > > On Tue, 20 Aug 2002, Justin Clift wrote:
> > >
> > > > Vince,
> > > >
> > > > Do you reckon it's worth you responding to "Sir Mordred" and pointing
> > > > out that he overstated the vulnerability?
> > >
> > > Not me.  Tom (pref) or Marc would be the proper respondent.
> > 
> > Has it actually been fixed?
> 
> The TODO list only mentions the cash_out(2) problem, whilst the email
> archives mention them both.
> 
> >From the info still around, this looks to mean that the cash_words()
> problem was fixed, but the cash_out() problem was harder to fix.
> 
> Tom/Bruce, is that correct?

Looks like cash_words is fixed in current CVS, so I guess in 7.2.1:
	
	Welcome to psql 7.3devel, the PostgreSQL interactive terminal.
	
	Type:  \copyright for distribution terms
	       \h for help with SQL commands
	       \? for help on internal slash commands
	       \g or terminate with semicolon to execute query
	       \q to quit
	
	test=> select cash_words('-700000000000000000000000000000');
	                                                     cash_words         
	                                           
	--------------------------------------------------------------------------------------------------------------------
	
	 Minus twenty one million four hundred seventy four thousand eight
	hundred thirty six dollars and forty eight cents
	(1 row)

Looks like cash_out still bombs:


	test=> select cash_out(2);
	server closed the connection unexpectedly
	        This probably means the server terminated abnormally
	        before or while processing the request.
	The connection to the server was lost. Attempting reset: Failed.


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 19 Aug 2002 22:32:35 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Justin Clift <justin@postgresql.org> writes:
> From the info still around, this looks to mean that the cash_words()
> problem was fixed, but the cash_out() problem was harder to fix.

> Tom/Bruce, is that correct?

The cash_out problem can't really be fixed until we do something about
subdividing type "opaque" into multiple pseudo-types with more carefully
defined meanings.  cash_out is declared cash_out(opaque) which does not
really mean that it accepts any input type ... but one of the several
meanings of "opaque" is "accepts any type", so the parser doesn't reject
cash_out(2).

I'd like to see something done about this fairly soon, but it's not
happening for 7.3 ...

			regards, tom lane

Mon, 19 Aug 2002 22:42:26 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 
Tom Lane wrote:
> 
> Justin Clift <justin@postgresql.org> writes:
> > From the info still around, this looks to mean that the cash_words()
> > problem was fixed, but the cash_out() problem was harder to fix.
> 
> > Tom/Bruce, is that correct?
> 
> The cash_out problem can't really be fixed until we do something about
> subdividing type "opaque" into multiple pseudo-types with more carefully
> defined meanings.  cash_out is declared cash_out(opaque) which does not
> really mean that it accepts any input type ... but one of the several
> meanings of "opaque" is "accepts any type", so the parser doesn't reject
> cash_out(2).
> 
> I'd like to see something done about this fairly soon, but it's not
> happening for 7.3 ...

Hang on, you seem to be suggesting we release a major new upgrade, with
major new functionality, knowing it contains a way to trivially crash
the backend.

Err.. hang on.  What happened to our reputation for quality and
releasing "when it's ready"?

Since when were we Microsoft-ized?

;-)

Regards and best wishes,

Justin Clift
 
>                         regards, tom lane

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
   - Indira Gandhi

Tue, 20 Aug 2002 13:17:44 +1000
Justin Clift <justin@postgresql.org>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
> Looks like cash_words is fixed in current CVS, so I guess in 7.2.1:
> 	
> 	Welcome to psql 7.3devel, the PostgreSQL interactive terminal.
> 	
> 	Type:  \copyright for distribution terms
> 	       \h for help with SQL commands
> 	       \? for help on internal slash commands
> 	       \g or terminate with semicolon to execute query
> 	       \q to quit
> 	
> 	test=> select cash_words('-700000000000000000000000000000');
> 	                                                     
> cash_words         
> 	                                           
> 	
> ------------------------------------------------------------------
> --------------------------------------------------
> 	
> 	 Minus twenty one million four hundred seventy four thousand eight
> 	hundred thirty six dollars and forty eight cents
> 	(1 row)

It doesn't crash - but it sure is giving the wrong answer ;)

Chris


Tue, 20 Aug 2002 11:24:43 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Justin Clift <justin@postgresql.org> writes:
> Hang on, you seem to be suggesting we release a major new upgrade, with
> major new functionality, knowing it contains a way to trivially crash
> the backend.

This particular hole has been in *every* release since Postgres 1.01.

I'm really not interested in responding to any argument that we cannot
release 7.3 until we have fixed everything that could be labeled a DOS
threat.  7.3 already contains a bunch of bug fixes; shall we postpone
releasing those because there are other unfixed bugs?

			regards, tom lane

Mon, 19 Aug 2002 23:27:43 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 
Tom Lane wrote:
> 
> Justin Clift <justin@postgresql.org> writes:
> > Hang on, you seem to be suggesting we release a major new upgrade, with
> > major new functionality, knowing it contains a way to trivially crash
> > the backend.
> 
> This particular hole has been in *every* release since Postgres 1.01.

How many releases have we known about this and still done a major
release?
 
> I'm really not interested in responding to any argument that we cannot
> release 7.3 until we have fixed everything that could be labeled a DOS
> threat.  7.3 already contains a bunch of bug fixes; shall we postpone
> releasing those because there are other unfixed bugs?

How trivial are they to exploit?

For example, thinking about something like the various ISP's around who
host PostgreSQL databases; how much effort would it take to fix the
vulnerabilities that let someone with remote access, but no ability to
run a "trusted" language, take out the backend?

Regards and best wishes,

Justin Clift
 
>                         regards, tom lane

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
   - Indira Gandhi

Tue, 20 Aug 2002 13:40:22 +1000
Justin Clift <justin@postgresql.org>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
>> test=> select cash_words('-700000000000000000000000000000');
>> Minus twenty one million four hundred seventy four thousand eight
>> hundred thirty six dollars and forty eight cents

> It doesn't crash - but it sure is giving the wrong answer ;)

Well, yeah, it's only a 32-bit storage value.  Overflow per se is not
the issue here.  (One reason why I'm not excited about fixing this on an
emergency basis is that I can't believe anyone is using the money type
for any mission-critical applications... it's too limited.)

			regards, tom lane

Mon, 19 Aug 2002 23:47:30 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 
> > I'd like to see something done about this fairly soon, but it's not
> > happening for 7.3 ...
>
> Hang on, you seem to be suggesting we release a major new upgrade, with
> major new functionality, knowing it contains a way to trivially crash
> the backend.
>
> Err.. hang on.  What happened to our reputation for quality and
> releasing "when it's ready"?
>
> Since when were we Microsoft-ized?

I personally agree with Justin that it should be fixed for 7.3 (just imagine
all those people selling colo postgres services).  There should be a 7.2.2
as well that fixes the date parser problem.

However, if you let people just run anything they want on your server (eg.
select cash_out(2);) then you're already in a world of pain because they can
quite easily DOS you by doing large, expensive queries, creating 1000
billion row tables, etc., etc.

Chris


Tue, 20 Aug 2002 11:50:47 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote:
> > > I'd like to see something done about this fairly soon, but it's not
> > > happening for 7.3 ...
> >
> > Hang on, you seem to be suggesting we release a major new upgrade, with
> > major new functionality, knowing it contains a way to trivially crash
> > the backend.
> >
> > Err.. hang on.  What happened to our reputation for quality and
> > releasing "when it's ready"?
> >
> > Since when were we Microsoft-ized?
> 
> I personally agree with Justin that it should be fixed for 7.3 (just imagine
> all those people selling colo postgres services).  There should be a 7.2.2
> as well that fixes the date parser problem.

Has anyone actually considered the time required to make the appropriate
fix (clean up use of OPAQUE)?  I don't think this bug is worthy of
pushing the 7.3 release out a few weeks.

The simple fix is to drop the money type entirely as it serves few
purposes -- but there are some who use it.


19 Aug 2002 23:58:06 -0400
Rod Taylor <rbt@zort.ca>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Justin Clift <justin@postgresql.org> writes:
> Tom Lane wrote:
>> This particular hole has been in *every* release since Postgres 1.01.

> How many releases have we known about this and still done a major
> release?

Several; a quick glance in the archives shows this has been on the TODO
list since 7.0.something.

I really have zero patience for arguments that "problem FOO is so bad
that we should drop everything else until we've fixed it".  There are
too many possible candidates for problem FOO, and there are still only
24 hours in the day.

			regards, tom lane

Mon, 19 Aug 2002 23:58:49 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 
Rod Taylor dijo: 

> The simple fix is to drop the money type entirely as it serves few
> purposes -- but there are some who use it.

There are a lot of other functions that cause the same problem.  Just
dropping or fixing cash_out is not the solution.

-- 
Alvaro Herrera (<alvherre[a]atentus.com>)
One man's impedance mismatch is another man's layer of abstraction.
(Lincoln Yeoh)


Tue, 20 Aug 2002 00:17:30 -0400 (CLT)
Alvaro Herrera <alvherre@atentus.com>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tue, 20 Aug 2002 13:40, Justin Clift wrote:
[snip]
> For example, thinking about something like the various ISP's around who
> host PostgreSQL databases; how much effort would it take to fix the
> vulnerabilities that let someone with remote access, but no ability to
> run a "trusted" language, take out the backend?

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.

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.

I know that all of my clients have their databases behind several layers of 
firewalls, and taking advantage of a vulnerability such as this remotely is 
extremely difficult.

Finally, question the due dilligence process that selects an ISP partner who 
would leave a database open to the world, even if they run "unbreakable" 
Oracle :)

Cheers

Mark

Tue, 20 Aug 2002 14:46:24 +1000
Mark Pritchard <mark@tangent.net.au>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Hi Mark,

Mark Pritchard wrote:
> 
<snip> 
> 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.
> 
> 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.

What you're saying has a lot of merit, these are important features. 
However, part of our reputation is as being a higher-end, more powerful,
more mature, database offering than other solutions around.

As Tom pointed out, we've already had several releases without getting
rid of this OPAQUE DOS bug, and as pointed out he also really doesn't
have the patience for fixing it (yet).

Was hoping we could get serious bugs fixed sooner rather than later,
otherwise I'm afraid of us just adding more bugs over time until we
start to affect our "having come good" reputation.
 
> I know that all of my clients have their databases behind several layers of
> firewalls, and taking advantage of a vulnerability such as this remotely is
> extremely difficult.

Totally agreed.  Lots of higher end or corporate places are, and that's
not a bad thing in any way.

For your clients, this particular bugfix doesn't sounds like its
necessary.

> Finally, question the due dilligence process that selects an ISP partner who
> would leave a database open to the world, even if they run "unbreakable"
> Oracle :)

This is the one point of yours I don't feel you've quite got down pat. 
Err... *why* is it safe to leave a HTTP, SSH, IMAP, etc server open to
the world (configured correctly of course), but somehow fundamentally
wrong to leave a database server open to the world.  If we've got a
product without these bugs, there wouldnt be a security vulnerability
would there?

The schema side of things could be *really* useful for ISPs' for
example, yet a large number of them probably wouldn't be so comfortable
having PostgreSQL available for their clients whilst knowing that these
kinds of DOS bugs exists.  Mentally, it's not a good thing.

Not trying to be a pain here, but instead trying to keep our QA level
up.

:)

Regards and best wishes,

Justin Clift
 
> Cheers
> 
> Mark

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
   - Indira Gandhi

Tue, 20 Aug 2002 15:19:42 +1000
Justin Clift <justin@postgresql.org>
Re: @(#) 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.

Cheers,

Neil

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


20 Aug 2002 01:22:09 -0400
Neil Conway <neilc@samurai.com>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
> As Tom pointed out, we've already had several releases without getting
> rid of this OPAQUE DOS bug, and as pointed out he also really doesn't
> have the patience for fixing it (yet).
>
> Was hoping we could get serious bugs fixed sooner rather than later,
> otherwise I'm afraid of us just adding more bugs over time until we
> start to affect our "having come good" reputation.

Getting a buggy rep on BugTraq has got to be a Bad Thing.  We already have
enough trouble competing with MySQL mindshare, and they haven't had BugTraq
problems.

Chris


Tue, 20 Aug 2002 13:31:38 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tue, 20 Aug 2002 15:22, Neil Conway wrote:
> 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.

Agreed - different issues, similar argument. They should be fixed, I just 
don't think its a sky is falling type problem. Not saying you said I was 
(*grin*), just that a competent network administrator has taken steps to 
secure the database over and above that expected of the developers.

> 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.

Definitely, and I wish I had some to spend on Postgres! Time that is :)

As you noted, most of the issues are in contrib - obviously due to the 
skills/knowledge of the core team and the strength of the development model. 
However, if the quality of programmers in the market is anything to go by, I 
don't hold out for the future unless Postgres is rewritten in something that 
holds hands as well as Java :)

Cheers

Mark

Tue, 20 Aug 2002 16:15:03 +1000
Mark Pritchard <mark@tangent.net.au>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Mon, 19 Aug 2002, Tom Lane wrote:

> Justin Clift <justin@postgresql.org> writes:
> > From the info still around, this looks to mean that the cash_words()
> > problem was fixed, but the cash_out() problem was harder to fix.
>
> > Tom/Bruce, is that correct?
>
> The cash_out problem can't really be fixed until we do something about
> subdividing type "opaque" into multiple pseudo-types with more carefully
> defined meanings.  cash_out is declared cash_out(opaque) which does not
> really mean that it accepts any input type ... but one of the several
> meanings of "opaque" is "accepts any type", so the parser doesn't reject
> cash_out(2).
>
> I'd like to see something done about this fairly soon, but it's not
> happening for 7.3 ...

Can we trap and just return an error before it goes into the weeds and
put the subdividing opaque fix in later?

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
         56K Nationwide Dialup from $16.00/mo at Pop4 Networking
      http://www.camping-usa.com      http://www.cloudninegifts.com
   http://www.meanstreamradio.com       http://www.unknown-artists.com
==========================================================================




Tue, 20 Aug 2002 07:36:29 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Mon, 19 Aug 2002, Tom Lane wrote:

> Justin Clift <justin@postgresql.org> writes:
> > From the info still around, this looks to mean that the cash_words()
> > problem was fixed, but the cash_out() problem was harder to fix.
> 
> > Tom/Bruce, is that correct?
> 
> The cash_out problem can't really be fixed until we do something about
> subdividing type "opaque" into multiple pseudo-types with more carefully
> defined meanings.  cash_out is declared cash_out(opaque) which does not
> really mean that it accepts any input type ... but one of the several
> meanings of "opaque" is "accepts any type", so the parser doesn't reject
> cash_out(2).
> 
> I'd like to see something done about this fairly soon, but it's not
> happening for 7.3 ...

Does anyone have an idea about what other functions are affected by this?

As a stop gap measure to remove the *known* DoS issue how about changing the
pg_proc entry to restrict input types, i.e. not cash_out(opaque)? cash_words is
already listed as only taking the money type is cash_out really that different?

On a related topic cash_out() is listed in pg_proc as returning an int4 but
doesn't the code clearly show that is incorrect?


-- 
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants



Tue, 20 Aug 2002 12:59:22 +0100 (BST)
"Nigel J. Andrews" <nandrews@investsystems.co.uk>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On August 19, 2002 11:58 pm, Rod Taylor wrote:
> On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote:
> The simple fix is to drop the money type entirely as it serves few
> purposes -- but there are some who use it.

As the original creator of the type I probably have the most emotional 
attachment to it but even I am thinking of dropping its use.  I would have 
preferred to fix it (more automatic casts and 64 bit storage as well as the 
fixes in the current thread) but I seem to be alone so it hardly seems worth 
it.  I still think that there is some benefit to being able to do integer 
arithmetic though.  I know that I do a lot of calculations (mostly sums) on 
money and going to numeric is going to be a hit.  No matter how efficient it 
is it can't be as efficient as a cpu register addition.

But maybe I'm wrong and the hit will be negligible.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

Tue, 20 Aug 2002 08:22:52 -0400
"D'Arcy J.M. Cain" <darcy@druid.net>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tue, 20 Aug 2002, D'Arcy J.M. Cain wrote:

> On August 19, 2002 11:58 pm, Rod Taylor wrote:
> > On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote:
> > The simple fix is to drop the money type entirely as it serves few
> > purposes -- but there are some who use it.
>
> As the original creator of the type I probably have the most emotional
> attachment to it but even I am thinking of dropping its use.  I would have
> preferred to fix it (more automatic casts and 64 bit storage as well as the
> fixes in the current thread) but I seem to be alone so it hardly seems worth
> it.  I still think that there is some benefit to being able to do integer
> arithmetic though.  I know that I do a lot of calculations (mostly sums) on
> money and going to numeric is going to be a hit.  No matter how efficient it
> is it can't be as efficient as a cpu register addition.
>
> But maybe I'm wrong and the hit will be negligible.

I used to use the money tag but someone said it was going away in a future
version and to use the numeric type instead.  I was under the impression
that it was going to be history long before now - it seems I was told this
back in 6.3.something.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
         56K Nationwide Dialup from $16.00/mo at Pop4 Networking
      http://www.camping-usa.com      http://www.cloudninegifts.com
   http://www.meanstreamradio.com       http://www.unknown-artists.com
==========================================================================




Tue, 20 Aug 2002 08:30:42 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Justin Clift wrote:
> 
> Hi Mark,
> 
> Mark Pritchard wrote:
> >
> [...]
> > Finally, question the due dilligence process that selects an ISP partner who
> > would leave a database open to the world, even if they run "unbreakable"
> > Oracle :)
> 
> This is the one point of yours I don't feel you've quite got down pat.
> Err... *why* is it safe to leave a HTTP, SSH, IMAP, etc server open to
> the world (configured correctly of course), but somehow fundamentally
> wrong to leave a database server open to the world.  If we've got a
> product without these bugs, there wouldnt be a security vulnerability
> would there?

Because in every system I've seen so far, the application plays a major
role in ensuring the data integrity by implementing at least part of the
business logic. Referential integrity and all the stuff is nice to have
and supports the application developer fighting against concurrency
issues, very hard to solve on the application layer. But the decision if
accountant Victor is permitted to cancel this payment for Hugo is still
up to the application.

If you say your users need direct DB access on the SQL interface level,
I say trash your application because the data it produces isn't worth
the magnetism on the media. It's not that we ugently need to fix such a
bug that can only cause a DOS in case someone finds a way to hack
through the application into the SQL interface. It's that the
application has to be fixed not to allow that, because even if the
server wouldn't be crashable, such a hack would end in a disaster. 


Jan

-- 

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

Tue, 20 Aug 2002 09:05:03 -0400
Jan Wieck <JanWieck@Yahoo.com>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Vince Vielhaber <vev@michvhf.com> writes:
> On Mon, 19 Aug 2002, Tom Lane wrote:
>> I'd like to see something done about this fairly soon, but it's not
>> happening for 7.3 ...

> Can we trap and just return an error before it goes into the weeds and
> put the subdividing opaque fix in later?

I don't think there's any quick and dirty solution.

One thing we could probably do in a relatively short amount of time,
considering that we already have one pseudo-type in the system, is to
go ahead and invent the "C string" pseudo-type and then change all the
built-in I/O functions to be declared as taking or returning C string
(as appropriate).  We couldn't really do strong type checking on this
yet, because we couldn't expect user-defined types' I/O functions to be
declared correctly for awhile yet, but at least it would plug the hole
for built-in types.

What this needs is someone to do the legwork...

			regards, tom lane

Tue, 20 Aug 2002 09:39:58 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 
On Tue, 2002-08-20 at 08:05, Jan Wieck wrote:
> If you say your users need direct DB access on the SQL interface level,
> I say trash your application because the data it produces isn't worth
> the magnetism on the media. It's not that we ugently need to fix such a
> bug that can only cause a DOS in case someone finds a way to hack
> through the application into the SQL interface. It's that the
> application has to be fixed not to allow that, because even if the
> server wouldn't be crashable, such a hack would end in a disaster. 
> 

The problem is, the vast majority of these issues are actually caused by
internal resources (people) rather than external "attacks".

The real fear is internal resources DoSing internal resources.  The
reaction on the list is usually to look outward for sources of possible
problems.  That in it self is a problem.  It's well documented the vast
majority (what, 70+%) of these issues actually originate internally.

It is because of these issues that it is often, no longer an issue of
"application this or that", as an application may of been completely
bypassed.

And yes, you can argue all day long that if this happens, you should be
fearing destruction of your data.  While that's true, data can be
restored.  It also requires a different personality type.  Many people
would be willing to DoS a system, however, that doesn't have to mean
they are willing to destroy data.


Regards,

	Greg Copeland
20 Aug 2002 09:05:16 -0500
Greg Copeland <greg@CopelandConsulting.Net>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
>> I'd like to see something done about this fairly soon, but it's not
>> happening for 7.3 ...

> Does anyone have an idea about what other functions are affected by this?

As a first approximation, every output function for a built-in
pass-by-reference datatype will show this same behavior.  cash_out is
just getting picked on because it was the one mentioned in the first
complaint.  For that matter, every input function for any datatype
has the same problem:
	regression=# select cash_in(2);
	server closed the connection unexpectedly

Let's see ... I count 264 standard pg_proc entries that are declared
with one or more "opaque" parameters.  Many but by no means all are I/O
functions.  There are another 13 standard functions declared to return
"opaque".  To plug the hole in a credible fashion we'd need to do
something about every one of these; so belay that last suggestion that
just implementing a "C string" pseudo-type would be enough to be
meaningful.

Right offhand it looks like we'd need at least:
	"C string" for the I/O functions
	"internal type" for index access functions, selectivity, etc
	"any array" for array_eq and array_dims
	"any type" for count(*) (and not much else!)
	"tuple" for the return type of trigger functions
	"void" for the return type of things that return void
	not sure about encoding conversion functions

The functions handling internal-type stuff are probably things we don't
want the user calling at all.  As long as we don't declare any of them
to *return* an internal type, there would be no way to construct a
function call that the parser would accept, so that hole would be
plugged with just one pseudo-type; we don't really need to distinguish
which internal type is meant in any one case.  The "any array"
pseudo-type would probably take a special-case kluge in parse_coerce,
but that doesn't seem intolerable.

Anyone see something I missed?  Tatsuo, what exactly should the function
signature really be for all those encoding conversion functions you just
added?

			regards, tom lane

Tue, 20 Aug 2002 10:09:01 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 
On Tue, 2002-08-20 at 08:22, D'Arcy J.M. Cain wrote:
> On August 19, 2002 11:58 pm, Rod Taylor wrote:
> > On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote:
> > The simple fix is to drop the money type entirely as it serves few
> > purposes -- but there are some who use it.
> 
> As the original creator of the type I probably have the most emotional 
> attachment to it but even I am thinking of dropping its use.  I would have 
> preferred to fix it (more automatic casts and 64 bit storage as well as the 

> But maybe I'm wrong and the hit will be negligible.

It wouldn't fix this particular problem anyway :) -- so I'm going to
vote to keep it.

Though for my own work I've created a money domain due to lack of digits
with the type -- not to mention I needed to store hundredths of a cent.


20 Aug 2002 10:21:25 -0400
Rod Taylor <rbt@zort.ca>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
> Anyone see something I missed?  Tatsuo, what exactly should the function
> signature really be for all those encoding conversion functions you just
> added?

test=# \df iso8859_1_to_utf8
                                  List of functions
 Result data type |   Schema   |       Name        |       Argument data types       
------------------+------------+-------------------+---------------------------------
 integer          | pg_catalog | iso8859_1_to_utf8 | integer, integer, -, -, integer
(1 row)
--
Tatsuo Ishii

Wed, 21 Aug 2002 00:08:37 +0900 (JST)
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>> Anyone see something I missed?  Tatsuo, what exactly should the function
>> signature really be for all those encoding conversion functions you just
>> added?

> test=# \df iso8859_1_to_utf8
>                                   List of functions
>  Result data type |   Schema   |       Name        |       Argument data types       
> ------------------+------------+-------------------+---------------------------------
>  integer          | pg_catalog | iso8859_1_to_utf8 | integer, integer, -, -, integer

Right, that's what they are now, but what do the "-" entries really
mean?  Also, are the "integer" args and result truthful, or do they
really mean something else?

			regards, tom lane

Tue, 20 Aug 2002 11:13:38 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 
On Tue, 20 Aug 2002, Tom Lane wrote:

> "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> >> I'd like to see something done about this fairly soon, but it's not
> >> happening for 7.3 ...
> 
> > Does anyone have an idea about what other functions are affected by this?
> 
> As a first approximation, every output function for a built-in
> pass-by-reference datatype will show this same behavior.  cash_out is
> just getting picked on because it was the one mentioned in the first
> complaint.  For that matter, every input function for any datatype
> has the same problem:
> 	regression=# select cash_in(2);
> 	server closed the connection unexpectedly
>
> ...

But going back to the idea that it seems that the only problem being publicised
in the 'outside world' is the cash_out(2) version can we not do the restriction
on acceptable input type in order to claim that the fix?

Obviously this is only a marketing ploy but on the basis that a real fix seems
unlikely before beta in 11 days time (I'm still trying to work out what Tom's
suggestion is) perhaps one worth implementing.
 

-- 
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants


Tue, 20 Aug 2002 16:22:35 +0100 (BST)
"Nigel J. Andrews" <nandrews@investsystems.co.uk>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> But going back to the idea that it seems that the only problem being
> publicised in the 'outside world' is the cash_out(2) version can we
> not do the restriction on acceptable input type in order to claim that
> the fix?

Totally pointless IMHO, when the same problem exists in hundreds of
other functions.  Also, there really is no way to patch cash_out per se;
the problem is a system-level problem, namely failure to enforce type
checking.  cash_out has no way to know that what it's been passed is the
wrong kind of datum.

Basically, we've used "opaque" as a substitute for accurate type
declarations; that's got to stop.

			regards, tom lane

Tue, 20 Aug 2002 11:28:32 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 
Tom Lane wrote:
> "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> 
>>>I'd like to see something done about this fairly soon, but it's not
>>>happening for 7.3 ...
>>
> 
>>Does anyone have an idea about what other functions are affected by this?
> 
> 
> As a first approximation, every output function for a built-in
> pass-by-reference datatype will show this same behavior.  cash_out is
> just getting picked on because it was the one mentioned in the first
> complaint.  For that matter, every input function for any datatype
> has the same problem:
> 	regression=# select cash_in(2);
> 	server closed the connection unexpectedly
> 
> Let's see ... I count 264 standard pg_proc entries that are declared
> with one or more "opaque" parameters.  Many but by no means all are I/O
> functions.  There are another 13 standard functions declared to return
> "opaque".  To plug the hole in a credible fashion we'd need to do
> something about every one of these; so belay that last suggestion that
> just implementing a "C string" pseudo-type would be enough to be
> meaningful.

Is there ever a reason for a user to call a function with an opaque 
parameter directly? If not, can we simply REVOKE EXECUTE for these 
functions?


Joe


Tue, 20 Aug 2002 08:37:18 -0700
Joe Conway <mail@joeconway.com>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow
On Tue, Aug 20, 2002 at 11:28:32AM -0400, Tom Lane wrote:
> "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> > But going back to the idea that it seems that the only problem being
> > publicised in the 'outside world' is the cash_out(2) version can we
> > not do the restriction on acceptable input type in order to claim that
> > the fix?
> 
> Totally pointless IMHO, when the same problem exists in hundreds of
> other functions.  Also, there really is no way to patch cash_out per se;
> the problem is a system-level problem, namely failure to enforce type
> checking.  cash_out has no way to know that what it's been passed is the
> wrong kind of datum.
> 
> Basically, we've used "opaque" as a substitute for accurate type
> declarations; that's got to stop.

Hmm, are there _any_ cases where it's appropriate to call an 'opaque'
function directly from user code? cash_out() and it's kin are type
output functions that are called under controlled conditions, with
backend controlled parameters. Trigger functions also are called with
backend controlled parameters. Is there a 'hack' fix that doesn't allow
opaque returning functions in user-defined locations?

Ross

Tue, 20 Aug 2002 10:44:20 -0500
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Joe Conway <mail@joeconway.com> writes:
> Is there ever a reason for a user to call a function with an opaque 
> parameter directly? If not, can we simply REVOKE EXECUTE for these 
> functions?

Not sure, but that doesn't solve the problem for array_eq and array_dims
in any case.

Good thought though ...

			regards, tom lane

Tue, 20 Aug 2002 11:45:37 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 
On Tuesday 20 August 2002 11:28 am, Tom Lane wrote:
> "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> > But going back to the idea that it seems that the only problem being
> > publicised in the 'outside world' is the cash_out(2) version can we
> > not do the restriction on acceptable input type in order to claim that
> > the fix?

> Basically, we've used "opaque" as a substitute for accurate type
> declarations; that's got to stop.

Umm, but what about the reply buffer overrun advisory?  I've read this whole 
thread, and the reply advisory (AFAICT, unless I've just hit delete too 
quickly) has NOT been addressed.  Let's repeat the salient portion of Florian 
Weimer's message:

> PostgreSQL 7.2.1 has a buffer overflow bug in the date parser (which
> is invoked each time a string is converted to a datetime object).  If
> a frontend does not perform proper date checking and rejects overlong
> date strings, a buffer is overwritten by parser.  The string has to
> pass some checks of the parser, so it is not immediately obvious that
> this can be exploited.  Denial of service is possible, though,
> especially if the frontend does not automatically reestablish the
> database connection. (All connections are affected, not just the one
> that is issueing the query.)

In the DATE parser, not money.  Not cash_out.  Where do we stand on the DATE 
overrun, if one actually exists?  If it exists, can it be exploited by a bad 
date entry on someone's web form or other client application? If it's not 
exploitable, then it lessens the impact -- but it is irresponsible to assume 
that just because we can't find a way to exploit it that no one else can.

Now it's possible I just hit delete too quickly; but it's also possible that 
everyone has just assumed that this was the cash_out problem and has started 
hashing on that.  Although this reply advisory hasn't been out as long as the 
original one, which WAS cash_words.

If there is indeed an exploitable overrun in the DATE parser, then I believe 
we should issue a 7.2.2 to fix this problem.  I know that MANY people will be 
using 7.2.x for quite awhile, as they won't want to make a MAJOR database 
upgrade (which is not painless thanks to the need to use 7.3's pg_dump for 
things).  If the upgrade was painless, I'd agree that 7.3 is the solution -- 
but a real security fix shouldn't wait for 7.3.  But I'm holding judgment on 
a proven exploit.  A proven exploit will change my mind to say 'we need a 
7.2.2 NOW that fixes this overrun.'
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Tue, 20 Aug 2002 11:59:20 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Lamar Owen <lamar.owen@wgcr.org> writes:
> Umm, but what about the reply buffer overrun advisory?  I've read this whole 
> thread, and the reply advisory (AFAICT, unless I've just hit delete too 
> quickly) has NOT been addressed.

Yes it has.  CVS logs show

2002-08-04 02:44  thomas

	* src/backend/utils/adt/: date.c, datetime.c, format_type.c,
	nabstime.c, timestamp.c, varlena.c: Add guard code to protect from
	buffer overruns on long date/time input  strings. [other
	comments pruned, but note this commit did a lot of other stuff too]

The original argument was about whether we should push out a 7.2.2
release just because of this fix.  AFAIK no one has even troubled to
look at the patch and see whether it applies directly to the 7.2 branch;
Thomas has revised the date/time code quite a bit since 7.2, so I'd
expect that it's not going to apply exactly.

I'd put more stock in the concern level of the people making complaints
if anyone had bothered to do even that much legwork.  Without an offered
patch against 7.2 branch, I don't think the folks who push out releases
(which is not me, but Marc, Bruce, you, Trond, etc) should bother to
take notice of the complaints at all.

			regards, tom lane

Tue, 20 Aug 2002 12:15:38 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 
On Tuesday 20 August 2002 12:15 pm, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > Umm, but what about the reply buffer overrun advisory?  I've read this
> > whole thread, and the reply advisory (AFAICT, unless I've just hit delete
> > too quickly) has NOT been addressed.

> Yes it has.  CVS logs show

> I'd put more stock in the concern level of the people making complaints
> if anyone had bothered to do even that much legwork.  Without an offered
> patch against 7.2 branch, I don't think the folks who push out releases
> (which is not me, but Marc, Bruce, you, Trond, etc) should bother to
> take notice of the complaints at all.

If a patch is proffered to 7.2.1 to fix this, I'll be happy to roll a new 
RPMset.  I tend to agree with you on this detail, Tom.

I had just apparently missed that portion; thanks for the reminder.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Tue, 20 Aug 2002 12:28:27 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Nigel J. Andrews wrote:
> On Tue, 20 Aug 2002, Tom Lane wrote:
> 
> > "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> > >> I'd like to see something done about this fairly soon, but it's not
> > >> happening for 7.3 ...
> > 
> > > Does anyone have an idea about what other functions are affected by this?
> > 
> > As a first approximation, every output function for a built-in
> > pass-by-reference datatype will show this same behavior.  cash_out is
> > just getting picked on because it was the one mentioned in the first
> > complaint.  For that matter, every input function for any datatype
> > has the same problem:
> > 	regression=# select cash_in(2);
> > 	server closed the connection unexpectedly
> >
> > ...
> 
> But going back to the idea that it seems that the only problem being publicized
> in the 'outside world' is the cash_out(2) version can we not do the restriction
> on acceptable input type in order to claim that the fix?
> 
> Obviously this is only a marketing ploy but on the basis that a real fix seems
> unlikely before beta in 11 days time (I'm still trying to work out what Tom's
> suggestion is) perhaps one worth implementing.

If we wanted to hide the vulnerability, I wouldn't have put it on the
TODO list.  One of our styles is not to deceive people;  if we have a
problem, we document it so others know about it and so someday someone
will fix it --- today may be that day.  ;-)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 20 Aug 2002 16:04:32 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tue, 2002-08-20 at 17:15, Tom Lane wrote:
> Yes it has.  CVS logs show
> 
> 2002-08-04 02:44  thomas
> 
> 	* src/backend/utils/adt/: date.c, datetime.c, format_type.c,
> 	nabstime.c, timestamp.c, varlena.c: Add guard code to protect from
> 	buffer overruns on long date/time input  strings. [other
> 	comments pruned, but note this commit did a lot of other stuff too]
> 
> The original argument was about whether we should push out a 7.2.2
> release just because of this fix.  AFAIK no one has even troubled to
> look at the patch and see whether it applies directly to the 7.2 branch;
> Thomas has revised the date/time code quite a bit since 7.2, so I'd
> expect that it's not going to apply exactly.

It doesn't.  I tried, since there's a Debian bug requesting those
patches be applied, but as far as I remember every hunk failed.
I didn't have time to try to make it fit.

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight, UK                            
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
                 ========================================
     "But I would not have you to be ignorant, brethren, 
      concerning them which are asleep, that ye sorrow not, 
      even as others which have no hope. For if we believe 
      that Jesus died and rose again, even so them also 
      which sleep in Jesus will God bring with him."        
                                I Thessalonians 4:13,14 


20 Aug 2002 22:23:41 +0100
Oliver Elphick <olly@lfix.co.uk>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
> > test=# \df iso8859_1_to_utf8
> >                                   List of functions
> >  Result data type |   Schema   |       Name        |       Argument data types       
> > ------------------+------------+-------------------+---------------------------------
> >  integer          | pg_catalog | iso8859_1_to_utf8 | integer, integer, -, -, integer
> 
> Right, that's what they are now, but what do the "-" entries really
> mean?  Also, are the "integer" args and result truthful, or do they
> really mean something else?

They are like:

 * conv_proc(
 *		INTEGER,	-- source encoding id
 *		INTEGER,	-- destination encoding id
 *		OPAQUE,		-- source string (null terminated C string)
 *		OPAQUE,		-- destination string (null terminated C string)
 *		INTEGER		-- source string length

For the second and third argument they are actually treated as:

unsigned char *src = PG_GETARG_CSTRING(2);
unsigned char *dest = PG_GETARG_CSTRING(3);

The first one is an input parameter(source string), and second one is
an output parameter(destination string). The caller of this function
is responsible for allocationg enough memory for destination string.

The returned integer is actually dummy. The function always returns 1.
--
Tatsuo Ishii

Wed, 21 Aug 2002 10:10:09 +0900 (JST)
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> They are like:

>  * conv_proc(
>  *		INTEGER,	-- source encoding id
>  *		INTEGER,	-- destination encoding id
>  *		OPAQUE,		-- source string (null terminated C string)
>  *		OPAQUE,		-- destination string (null terminated C string)
>  *		INTEGER		-- source string length

Got it (shoulda read the documentation before asking ;-))

> The returned integer is actually dummy. The function always returns 1.

Yes.  I will change these to be declared as

	foo(int, int, cstring, cstring, int) returns void

unless anyone has a problem with that?

			regards, tom lane

Tue, 20 Aug 2002 23:13:52 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 