Thread: @(#) Mordred Labs advisory 0x0001: Buffer overflow in PostgreSQL (fwd)
Surprised it took this long. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 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
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 atPop4 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,
Pennsylvania19073
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, Pennsylvania19073
"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:
> 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
slashcommands \g or terminate with semicolon to execute query \q to quittest=> select
cash_words('-700000000000000000000000000000'); cash_words
--------------------------------------------------------------------------------------------------------------------
Minustwenty one million four hundred seventy four thousand eighthundred 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,
Pennsylvania19073
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
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)
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
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
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
> 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
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
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 atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
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
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.
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 atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
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 #
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
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
"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"
forthe return type of trigger functions"void" for the return type of things that return voidnot sure about encoding
conversionfunctions
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
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.
> 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 functionsResult data type | Schema | Name | Argument data types ------------------+------------+-------------------+---------------------------------integer | pg_catalog | iso8859_1_to_utf8| integer, integer, -, -, integer (1 row) -- Tatsuo Ishii
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
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
"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
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
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
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
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
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
protectfrombuffer overruns on long date/time input strings. [othercomments pruned, but note this commit did a lot of
otherstuff 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
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
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, Pennsylvania19073
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 whichare asleep, that ye sorrow not, even as others which have no hope. For if we believe that Jesus died and roseagain, even so them also which sleep in Jesus will God bring with him." IThessalonians 4:13,14
> > 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
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