@(#) 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

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,

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

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

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

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

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

"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

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

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

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

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

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

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

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

"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

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

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.

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