Horton
Menu

Thread

  1. @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

    Vince Vielhaber <vev@michvhf.com> — 2002-08-20T19:52:52Z

    Here's yet another.  He claims malicious code can be run on the server
with this one.

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: Tue, 20 Aug 2002 14:28:49 +0000
From: Sir Mordred The Traitor <mordred@s-mail.com>
To: bugtraq@securityfocus.com
Subject: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL

//@(#)Mordred Labs advisory 0x0003

Release data: 20/08/02
Name: Buffer overflow in PostgreSQL
Versions affected: all versions
Risk: high

--[ Description:

...PostgreSQL is a sophisticated Object-Relational DBMS,
supporting almost all SQL constructs, including subselects,
transactions, and user-defined types and functions. It is the
most advanced open-source database available anywhere...blah...blah...
For more info check out this link:
http://www.postgresql.org/idocs/index.php?preface.html#INTRO-WHATIS

There exists a heap buffer overflow in a repeat(text, integer) function,
which
allows an attacker to execute malicious code.

--[ Details:

Upon invoking a repeat() function, a
src/backend/utils/adt/oracle_compat.c::repeat() function
will gets called which suffers from a buffer overflow.

--[ How to reproduce:

psql> select repeat('xxx',1431655765);
pqReadData() -- backend closed the channel unexpectedly.
        This probably means the backend terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

--[ Solution

Do you still running postgresql? ...Can't believe that...
If so, execute the following command as a root: "killall -9 postmaster",
and wait until the patch will be available.



________________________________________________________________________
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

  2. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

    Tom Lane <tgl@sss.pgh.pa.us> — 2002-08-20T20:05:11Z

    Vince Vielhaber <vev@michvhf.com> writes:
> Here's yet another.  He claims malicious code can be run on the server
> with this one.

regression=# select repeat('xxx',1431655765);
server closed the connection unexpectedly

This is probably caused by integer overflow in calculating the size of
the repeat's result buffer.  It'd take some considerable doing to create
an arbitrary-code exploit, but perhaps could be done.  Anyone want to
investigate a patch?  I think we likely need something like

	bufsize = input_length * repeats;
+	/* check for overflow in multiplication */
+	if (bufsize / repeats != input_length)
+		elog(ERROR, "repeat result too long");

but I haven't thought it through in detail.

			regards, tom lane

  3. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Vince Vielhaber <vev@michvhf.com> — 2002-08-20T20:11:26Z

    On Tue, 20 Aug 2002, Tom Lane wrote:

> Vince Vielhaber <vev@michvhf.com> writes:
> > Here's yet another.  He claims malicious code can be run on the server
> > with this one.
>
> regression=# select repeat('xxx',1431655765);
> server closed the connection unexpectedly
>
> This is probably caused by integer overflow in calculating the size of
> the repeat's result buffer.  It'd take some considerable doing to create
> an arbitrary-code exploit, but perhaps could be done.  Anyone want to
> investigate a patch?  I think we likely need something like
>
> 	bufsize = input_length * repeats;
> +	/* check for overflow in multiplication */
> +	if (bufsize / repeats != input_length)
> +		elog(ERROR, "repeat result too long");
>
> but I haven't thought it through in detail.

Where do we check that this:

		result = (text *) palloc(tlen);

is even successful?  Is it in one of the macros (VARATT_SIZEP or VARDATA)?
It appears like it goes into the count and copy regardless.

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

  4. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

    Tom Lane <tgl@sss.pgh.pa.us> — 2002-08-20T20:15:01Z

    Vince Vielhaber <vev@michvhf.com> writes:
> Where do we check that this:
> 		result = (text *) palloc(tlen);
> is even successful?

palloc elogs if it can't allocate the space; it's unlike malloc in that
respect.  I believe it also has a guard to reject requests > 1Gb, so
I think it's reasonably proof against internal arithmetic overflows.

This problem is strictly repeat's error, not palloc's.

			regards, tom lane

  5. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

    Neil Conway <neilc@samurai.com> — 2002-08-20T20:31:50Z

    Tom Lane <tgl@sss.pgh.pa.us> writes:

> Vince Vielhaber <vev@michvhf.com> writes:
> > Here's yet another.  He claims malicious code can be run on the server
> > with this one.
> 
> regression=# select repeat('xxx',1431655765);
> server closed the connection unexpectedly
> 
> This is probably caused by integer overflow in calculating the size of
> the repeat's result buffer.  It'd take some considerable doing to create
> an arbitrary-code exploit, but perhaps could be done.  Anyone want to
> investigate a patch?

This seems to fix the problem:

nconway=# select repeat('xxx',1431655765);
ERROR:  Requested buffer is too large.

It uses the logic you suggested. Just a quick and dirty fix, I may
have missed something... The patch applies cleanly to both CVS HEAD
and the 7.2 stable branch.

Cheers,

Neil

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

  6. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

    Tom Lane <tgl@sss.pgh.pa.us> — 2002-08-20T20:36:09Z

    Neil Conway <neilc@samurai.com> writes:
> + 	/* Check for integer overflow */
> + 	if (tlen / slen != count)
> + 		elog(ERROR, "Requested buffer is too large.");

What about slen == 0?

			regards, tom lane

  7. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

    Neil Conway <neilc@samurai.com> — 2002-08-20T20:43:31Z

    Vince Vielhaber <vev@michvhf.com> writes:
> Here's yet another.

Should someone from the core team perhaps get in contact with this guy
and ask if he could get in contact with the development team before
publicizing any further security holes? AFAIK that is standard
operating procedure in most cases...

Second, it might be worth pushing a 7.2.2 release containing the fix
for this bug, as well as the datetime problem. If that sounds
reasonable to the people who have to do the most work on a new release
(e.g. Marc), I can volunteer to backport a fix for the datetime
problem.

Cheers,

Neil

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

  8. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Vince Vielhaber <vev@michvhf.com> — 2002-08-20T20:50:45Z

    On 20 Aug 2002, Neil Conway wrote:

> Vince Vielhaber <vev@michvhf.com> writes:
> > Here's yet another.
>
> Should someone from the core team perhaps get in contact with this guy
> and ask if he could get in contact with the development team before
> publicizing any further security holes? AFAIK that is standard
> operating procedure in most cases...

I just asked him/her that on bugtraq.

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

  9. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-08-20T20:50:46Z

    Vince Vielhaber wrote:
> 
> Here's yet another.  He claims malicious code can be run on the server
> with this one.

> --[ Solution
> 
> Do you still running postgresql? ...Can't believe that...
> If so, execute the following command as a root: "killall -9 postmaster",
> and wait until the patch will be available.

You've got to love this last part.  ;-)

This has the attitude of "Oh, look at me, I found a bug.  Let me
publicize it and get more attention.  Aren't you proud of me?"

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

  10. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

    Neil Conway <neilc@samurai.com> — 2002-08-20T20:54:23Z

    Tom Lane <tgl@sss.pgh.pa.us> writes:
> Neil Conway <neilc@samurai.com> writes:
> > + 	/* Check for integer overflow */
> > + 	if (tlen / slen != count)
> > + 		elog(ERROR, "Requested buffer is too large.");
> 
> What about slen == 0?

Good point -- that wouldn't cause incorrect results or a security
problem, but it would reject input that we should really accept.

Revised patch is attached.

Cheers,

Neil

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

  11. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-08-20T21:09:43Z

    This is all an indication of our increasing usage.  Several PostgreSQL
articles have appeared in the past week in _major_ media outlets, not
just the open-source press (eweek, Bloomburg), a major PostgreSQL
support company bought a Linux distribution (SRA-Turbolinux), and we
have independent projects auditing our code.  It is only going to get
worse.  ;-)

---------------------------------------------------------------------------

Vince Vielhaber wrote:
> On 20 Aug 2002, Neil Conway wrote:
> 
> > Vince Vielhaber <vev@michvhf.com> writes:
> > > Here's yet another.
> >
> > Should someone from the core team perhaps get in contact with this guy
> > and ask if he could get in contact with the development team before
> > publicizing any further security holes? AFAIK that is standard
> > operating procedure in most cases...
> 
> I just asked him/her that on bugtraq.
> 
> 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
> ==========================================================================
> 
> 
> 
> 
> ---------------------------(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

  12. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

    Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2002-08-21T01:49:57Z

    > Should someone from the core team perhaps get in contact with this guy
> and ask if he could get in contact with the development team before
> publicizing any further security holes? AFAIK that is standard
> operating procedure in most cases...
>
> Second, it might be worth pushing a 7.2.2 release containing the fix
> for this bug, as well as the datetime problem. If that sounds
> reasonable to the people who have to do the most work on a new release
> (e.g. Marc), I can volunteer to backport a fix for the datetime
> problem.

It'd be better to contact the dude and get all his bugs out of him, fix them
all and issue a 7.2.2 with all the fixes.

I think this is now essential - people will be using 7.2 series for ages
even after the 7.3 release...

Chris

  13. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Gavin Sherry <swm@linuxworld.com.au> — 2002-08-21T02:15:51Z

    On Wed, 21 Aug 2002, Christopher Kings-Lynne wrote:

> > Should someone from the core team perhaps get in contact with this guy
> > and ask if he could get in contact with the development team before
> > publicizing any further security holes? AFAIK that is standard
> > operating procedure in most cases...
> >
> > Second, it might be worth pushing a 7.2.2 release containing the fix
> > for this bug, as well as the datetime problem. If that sounds
> > reasonable to the people who have to do the most work on a new release
> > (e.g. Marc), I can volunteer to backport a fix for the datetime
> > problem.
> 
> It'd be better to contact the dude and get all his bugs out of him, fix them
> all and issue a 7.2.2 with all the fixes.

That wouldn't work because it seems he is making advisories at the
time he discovers a bug/flaw. That is, he is not directly interested in
the robustness of Postgres -- rather, another poster put it, his
reputation on bugtraq. That's fine but it doesn't mesh well with the
co-ordinated effort you describe.

I still do not see this as being a serious security problem unless you are
providing access to postgres to untrusted users. The advisory's
recommendation of killing the postmaster as a solution to these bugs is
akin to saying 'kill ssh if there's a libc bug'. If you are providing
access to untrusted users, that advice is worthwhile. But if your users
are trusted and could produce the same effect in any other number of
reasons, the advice is useless.

As for making a 7.2.2 release for the sake of form and for those users who
do provide access to untrusted users (universities, ISPs, say) this would
be pointless without the changes to opaque which Tom has put forward and
may/may not work on before 7.3 beta. I'm not sure that the core guys would
be too happy doing that *and* requiring an initdb for a minor release (as 
I presume Tom's changes will require one).

Gavin

  14. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Neil Conway <neilc@samurai.com> — 2002-08-21T03:34:53Z

    Gavin Sherry <swm@linuxworld.com.au> writes:
> As for making a 7.2.2 release for the sake of form and for those
> users who do provide access to untrusted users (universities, ISPs,
> say) this would be pointless without the changes to opaque which Tom
> has put forward and may/may not work on before 7.3 beta.

I don't think that releasing 7.2.2 without the opaque changes would be
pointless. For one thing, the opaque-related security problems are
comparatively minor: the cracker must be able to execute arbitrary SQL
commands against the database, and by that stage of the game, a DoS
attack is already trivial (e.g. disable GEQO and execute a 15 table
join query).

Also, from skimming the discussion on fixing the opaque problems,
there will be at least some degree of backwards incompatibility. That
is definitely undesirable for a stable point release -- as is an
initdb, as you point out. This amount of pain to fix a minor security
hole is *not* worth it, IMHO.

So I think that fixing the opaque problems in 7.2.x is simply
impossible. Given that, the question is whether we should make a 7.2.2
release with fixes for the other security holes (lpad(), rpad(),
reverse(), and the datetime overruns). IMHO, we should.

The datetime hole is fairly serious: it's not unreasonable for
developers to accept datetime input from the user without limiting
it's length. So it's quite likely that there are 7.2 systems in
production that have a sane security policy (e.g. hidden behind a
firewall, validate user input, etc.) that are still vulnerable.

The alternative seems unattractive: if we require that users wait for
7.3 to come out, it may be months before the 7.3.0 release. And even
then, upgrading to 7.3 is non-trivial: it requires an initdb and
reload, as well as testing to ensure that the user's applications run
smoothly on 7.3. Therefore, it may be several months before many
production sites upgrade to 7.3; leaving them in the cold for that
period isn't something I think we should do, if we can avoid it.

That said, there's only a limited amount that I can do. I think we
should make a 7.2.2 release, and to that end I've posted patches
against REL7_2_STABLE for all four of the security holes. The rest of
the work that goes into making a release needs to be done by others
(Marc, Vince, Bruce, etc.) -- if there's anything I can do to help,
let me know.

Cheers,

Neil

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

  15. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    lockhart@fourpalms.org — 2002-08-21T04:09:58Z

    ...
> So I think that fixing the opaque problems in 7.2.x is simply
> impossible. Given that, the question is whether we should make a 7.2.2
> release with fixes for the other security holes (lpad(), rpad(),
> reverse(), and the datetime overruns). IMHO, we should.

Just a minor point: can someone actually show a symptom with date/time
problems in 7.2.x?

                  - Thomas

  16. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Gavin Sherry <swm@linuxworld.com.au> — 2002-08-21T06:13:22Z

    On Tue, 20 Aug 2002, Thomas Lockhart wrote:

> ...
> > So I think that fixing the opaque problems in 7.2.x is simply
> > impossible. Given that, the question is whether we should make a 7.2.2
> > release with fixes for the other security holes (lpad(), rpad(),
> > reverse(), and the datetime overruns). IMHO, we should.
> 
> Just a minor point: can someone actually show a symptom with date/time
> problems in 7.2.x?

template1=# select version();
                           version
-------------------------------------------------------------
 PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC 2.96
(1 row)

template1=# select
'1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111'::date
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.
!#

ParseDateTime() isn't checking that str < MAXDATELEN -- which is the
problem you solved in the datetime.c fixes.

Gavin

  17. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Marc Fournier <scrappy@hub.org> — 2002-08-21T06:41:32Z

    On 20 Aug 2002, Neil Conway wrote:

> Vince Vielhaber <vev@michvhf.com> writes:
> > Here's yet another.
>
> Should someone from the core team perhaps get in contact with this guy
> and ask if he could get in contact with the development team before
> publicizing any further security holes? AFAIK that is standard
> operating procedure in most cases...
>
> Second, it might be worth pushing a 7.2.2 release containing the fix
> for this bug, as well as the datetime problem. If that sounds
> reasonable to the people who have to do the most work on a new release
> (e.g. Marc), I can volunteer to backport a fix for the datetime
> problem.

I have no problems doing a v7.2.2 release for something like this ...

  18. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Robert Treat <xzilla@users.sourceforge.net> — 2002-08-21T15:43:20Z

    On Tue, 2002-08-20 at 23:34, Neil Conway wrote:
> Gavin Sherry <swm@linuxworld.com.au> writes:
> > As for making a 7.2.2 release for the sake of form and for those
> > users who do provide access to untrusted users (universities, ISPs,
> > say) this would be pointless without the changes to opaque which Tom
> > has put forward and may/may not work on before 7.3 beta.
> 
> I don't think that releasing 7.2.2 without the opaque changes would be
> pointless. For one thing, the opaque-related security problems are
> comparatively minor: the cracker must be able to execute arbitrary SQL
> commands against the database, and by that stage of the game, a DoS
> attack is already trivial (e.g. disable GEQO and execute a 15 table
> join query).
> 
> Also, from skimming the discussion on fixing the opaque problems,
> there will be at least some degree of backwards incompatibility. That
> is definitely undesirable for a stable point release -- as is an
> initdb, as you point out. This amount of pain to fix a minor security
> hole is *not* worth it, IMHO.
> 
> So I think that fixing the opaque problems in 7.2.x is simply
> impossible. Given that, the question is whether we should make a 7.2.2
> release with fixes for the other security holes (lpad(), rpad(),
> reverse(), and the datetime overruns). IMHO, we should.
> 
> The datetime hole is fairly serious: it's not unreasonable for
> developers to accept datetime input from the user without limiting
> it's length. So it's quite likely that there are 7.2 systems in
> production that have a sane security policy (e.g. hidden behind a
> firewall, validate user input, etc.) that are still vulnerable.
> 
> The alternative seems unattractive: if we require that users wait for
> 7.3 to come out, it may be months before the 7.3.0 release. And even
> then, upgrading to 7.3 is non-trivial: it requires an initdb and
> reload, as well as testing to ensure that the user's applications run
> smoothly on 7.3. Therefore, it may be several months before many
> production sites upgrade to 7.3; leaving them in the cold for that
> period isn't something I think we should do, if we can avoid it.
> 
> That said, there's only a limited amount that I can do. I think we
> should make a 7.2.2 release, and to that end I've posted patches
> against REL7_2_STABLE for all four of the security holes. The rest of
> the work that goes into making a release needs to be done by others
> (Marc, Vince, Bruce, etc.) -- if there's anything I can do to help,
> let me know.
> 
> Cheers,
> 
> Neil
> 

Assuming that we do go ahead with a 7.2.2 release, can we get some kind
of unofficial statement on pushing back the 7.3 beta? I know Tom was
hoping to start it by sept 1 but that seems rushed to me. Furthermore,
between schema support and now more backward incompatibility in regards
to functions/opaque, should we open some discussion on 7.3 really being
8.0? 

Robert Treat

  19. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Justin Clift <justin@postgresql.org> — 2002-08-21T16:13:08Z

    Robert Treat wrote:
<snip>
> 
> Assuming that we do go ahead with a 7.2.2 release, can we get some kind
> of unofficial statement on pushing back the 7.3 beta? I know Tom was
> hoping to start it by sept 1 but that seems rushed to me. Furthermore,
> between schema support and now more backward incompatibility in regards
> to functions/opaque, should we open some discussion on 7.3 really being
> 8.0?

Depending on how far back we push this, we might be able to get Windows
Native support added.  That'd be cool and probably contribute to an 8.0.

:)

Regards and best wishes,

Justin Clift

 
> Robert Treat
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

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

  20. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-08-21T16:25:07Z

    We learned a few lessons from previous releases.  First, don't delay
the beta by days/weeks that drag on.  Delay one month at a time. 
Second, don't decide on a further delay the day before you are going to
go beta.  Multiple short-period delays and delays that happen at the
last minute cause too many stops/starts for developers to be effective,
so...

If we are going to delay beta, we should decide now, not at the end of
August, and the delay should be until the end of September.  The big
question is whether we have enough material to warrant a delay.

---------------------------------------------------------------------------

Justin Clift wrote:
> Robert Treat wrote:
> <snip>
> > 
> > Assuming that we do go ahead with a 7.2.2 release, can we get some kind
> > of unofficial statement on pushing back the 7.3 beta? I know Tom was
> > hoping to start it by sept 1 but that seems rushed to me. Furthermore,
> > between schema support and now more backward incompatibility in regards
> > to functions/opaque, should we open some discussion on 7.3 really being
> > 8.0?
> 
> Depending on how far back we push this, we might be able to get Windows
> Native support added.  That'd be cool and probably contribute to an 8.0.
> 
> :)
> 
> Regards and best wishes,
> 
> Justin Clift
> 
>  
> > Robert Treat
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: you can get off all lists at once with the unregister command
> >     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 
> -- 
> "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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
> 

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

  21. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Justin Clift <justin@postgresql.org> — 2002-08-21T16:42:38Z

    Bruce Momjian wrote:
> 
> We learned a few lessons from previous releases.  First, don't delay
> the beta by days/weeks that drag on.  Delay one month at a time.
> Second, don't decide on a further delay the day before you are going to
> go beta.  Multiple short-period delays and delays that happen at the
> last minute cause too many stops/starts for developers to be effective,
> so...
> 
> If we are going to delay beta, we should decide now, not at the end of
> August, and the delay should be until the end of September.  The big
> question is whether we have enough material to warrant a delay.

Only two things which have the potential to be worth waiting for, from
what I'm aware of.  There may be others:

 - Find out from Sir Mordred if he wants to take a look at the CVS
   version of code and audit in that for a bit, Just In Case he turns
   up something that's serious and requires substantial re-work.
   Although it means he wouldn't have a bunch of "I found this existing
   exploit" type releases, we could instead offer him credit on the
   press release along the lines of "This released has been audited for
   security flaws in its code by Sir Mordred".  Am pretty sure he'd
   do a very thorough job for that, as it means he'd have an official
   "product reputation" he'd need to stand by for it.

 - Patches to the CVS tree which let us have a truly native windows
   version.  This is of huge significance and would *very* much improve
   our growth and adoption by being in this release in comparison to
   being in the release afterwards.  Not in an airy fairy way, but
   quite definitely and solidly.

Of the two, Sir Mordred may or may not be willing, so that's kind of
iffy, whereas the Windows Native port which is in beta testing isn't
in too bad a state at all already.  Have been running preliminary
multi-user AS3AP tests on it (with OSDB) and getting a significant
performance throughput increase in comparison to the cygwin version.

:)

Hope I'm not pushing too strongly for this, as, after all, I can't do
the coding needed here.  :(

Regards and best wishes,

Justin Clift

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

  22. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-08-21T16:59:50Z

    Justin Clift wrote:
> Only two things which have the potential to be worth waiting for, from
> what I'm aware of.  There may be others:
> 
>  - Find out from Sir Mordred if he wants to take a look at the CVS
>    version of code and audit in that for a bit, Just In Case he turns
>    up something that's serious and requires substantial re-work.
>    Although it means he wouldn't have a bunch of "I found this existing
>    exploit" type releases, we could instead offer him credit on the
>    press release along the lines of "This released has been audited for
>    security flaws in its code by Sir Mordred".  Am pretty sure he'd
>    do a very thorough job for that, as it means he'd have an official
>    "product reputation" he'd need to stand by for it.

This is interesting.  He would have a month to do it.

>  - Patches to the CVS tree which let us have a truly native windows
>    version.  This is of huge significance and would *very* much improve
>    our growth and adoption by being in this release in comparison to
>    being in the release afterwards.  Not in an airy fairy way, but
>    quite definitely and solidly.
> 
> Of the two, Sir Mordred may or may not be willing, so that's kind of
> iffy, whereas the Windows Native port which is in beta testing isn't
> in too bad a state at all already.  Have been running preliminary
> multi-user AS3AP tests on it (with OSDB) and getting a significant
> performance throughput increase in comparison to the cygwin version.

OK, now I have to ask, where did this native Windows version come from? 
I don't know anything about it, except that Jan and SRA are both working
on versions.

The other issue is PITR, which I have been told today will not be ready
for a September 1 beta but may be ready for an October 1 beta.

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

  23. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Justin Clift <justin@postgresql.org> — 2002-08-21T17:04:56Z

    Bruce Momjian wrote:
> 
> Justin Clift wrote:
> > Only two things which have the potential to be worth waiting for, from
> > what I'm aware of.  There may be others:
> >
> >  - Find out from Sir Mordred if he wants to take a look at the CVS
> >    version of code and audit in that for a bit, Just In Case he turns
> >    up something that's serious and requires substantial re-work.
> >    Although it means he wouldn't have a bunch of "I found this existing
> >    exploit" type releases, we could instead offer him credit on the
> >    press release along the lines of "This released has been audited for
> >    security flaws in its code by Sir Mordred".  Am pretty sure he'd
> >    do a very thorough job for that, as it means he'd have an official
> >    "product reputation" he'd need to stand by for it.
> 
> This is interesting.  He would have a month to do it.

Reckon it's worth asking him, to find out if he'd be interested in this?
 
> >  - Patches to the CVS tree which let us have a truly native windows
> >    version.  This is of huge significance and would *very* much improve
> >    our growth and adoption by being in this release in comparison to
> >    being in the release afterwards.  Not in an airy fairy way, but
> >    quite definitely and solidly.
> >
> > Of the two, Sir Mordred may or may not be willing, so that's kind of
> > iffy, whereas the Windows Native port which is in beta testing isn't
> > in too bad a state at all already.  Have been running preliminary
> > multi-user AS3AP tests on it (with OSDB) and getting a significant
> > performance throughput increase in comparison to the cygwin version.
> 
> OK, now I have to ask, where did this native Windows version come from?
> I don't know anything about it, except that Jan and SRA are both working
> on versions.

It was kind of quietly let slip out:

http://archives.postgresql.org/pgsql-cygwin/2002-08/msg00012.php

But, it's definitely up and running and functional and pretty decent.

:-)

> The other issue is PITR, which I have been told today will not be ready
> for a September 1 beta but may be ready for an October 1 beta.

Useful, but not sure it's worth delaying even *further* for.

+ Justin

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

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

  24. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-08-21T17:13:27Z

    Justin Clift wrote:
> Bruce Momjian wrote:
> > 
> > Justin Clift wrote:
> > > Only two things which have the potential to be worth waiting for, from
> > > what I'm aware of.  There may be others:
> > >
> > >  - Find out from Sir Mordred if he wants to take a look at the CVS
> > >    version of code and audit in that for a bit, Just In Case he turns
> > >    up something that's serious and requires substantial re-work.
> > >    Although it means he wouldn't have a bunch of "I found this existing
> > >    exploit" type releases, we could instead offer him credit on the
> > >    press release along the lines of "This released has been audited for
> > >    security flaws in its code by Sir Mordred".  Am pretty sure he'd
> > >    do a very thorough job for that, as it means he'd have an official
> > >    "product reputation" he'd need to stand by for it.
> > 
> > This is interesting.  He would have a month to do it.
> 
> Reckon it's worth asking him, to find out if he'd be interested in this?


I wouldn't do it yet until we know if we are going to delay.

> > >  - Patches to the CVS tree which let us have a truly native windows
> > >    version.  This is of huge significance and would *very* much improve
> > >    our growth and adoption by being in this release in comparison to
> > >    being in the release afterwards.  Not in an airy fairy way, but
> > >    quite definitely and solidly.
> > >
> > > Of the two, Sir Mordred may or may not be willing, so that's kind of
> > > iffy, whereas the Windows Native port which is in beta testing isn't
> > > in too bad a state at all already.  Have been running preliminary
> > > multi-user AS3AP tests on it (with OSDB) and getting a significant
> > > performance throughput increase in comparison to the cygwin version.
> > 
> > OK, now I have to ask, where did this native Windows version come from?
> > I don't know anything about it, except that Jan and SRA are both working
> > on versions.
> 
> It was kind of quietly let slip out:
> 
> http://archives.postgresql.org/pgsql-cygwin/2002-08/msg00012.php
> 
> But, it's definitely up and running and functional and pretty decent.

Oh, so it is Jan's group.  Great news;  wish someone would have told me
sooner. I removed the Win32 off the open items list because, with no
info and no one commenting on the item, it seemed dead for 7.3.

> > The other issue is PITR, which I have been told today will not be ready
> > for a September 1 beta but may be ready for an October 1 beta.
> 
> Useful, but not sure it's worth delaying even *further* for.

Well, PITR is a much more desired feature even than Win32;  the big
question is how long PITR will actually take, seeing as we haven't see
any patches yet.

However, we haven't seen any Win32 patches yet either, so they are in
the same boat as far as I am concerned.

We have an open items list that is pretty much ready for 7.3.  The only
open items of significance left is whether schema/DROP COLUMN stuff is
ready in all the interfaces/apps.

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

  25. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-08-21T17:22:13Z

    Your patch has been added to the PostgreSQL unapplied patches list at:

	http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------


Neil Conway wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> > Neil Conway <neilc@samurai.com> writes:
> > > + 	/* Check for integer overflow */
> > > + 	if (tlen / slen != count)
> > > + 		elog(ERROR, "Requested buffer is too large.");
> > 
> > What about slen == 0?
> 
> Good point -- that wouldn't cause incorrect results or a security
> problem, but it would reject input that we should really accept.
> 
> Revised patch is attached.
> 
> Cheers,
> 
> Neil
> 
> -- 
> Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

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

  26. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Rod Taylor <rbt@zort.ca> — 2002-08-21T17:30:04Z

    On Wed, 2002-08-21 at 13:13, Bruce Momjian wrote:
> Justin Clift wrote:
> > Bruce Momjian wrote:
> > > 
> > > Justin Clift wrote:
> > > > Only two things which have the potential to be worth waiting for, from
> > > > what I'm aware of.  There may be others:
> > > >
> > > >  - Find out from Sir Mordred if he wants to take a look at the CVS
> > > >    version of code and audit in that for a bit, Just In Case he turns
> > > >    up something that's serious and requires substantial re-work.
> > > >    Although it means he wouldn't have a bunch of "I found this existing
> > > >    exploit" type releases, we could instead offer him credit on the
> > > >    press release along the lines of "This released has been audited for
> > > >    security flaws in its code by Sir Mordred".  Am pretty sure he'd
> > > >    do a very thorough job for that, as it means he'd have an official
> > > >    "product reputation" he'd need to stand by for it.
> > > 
> > > This is interesting.  He would have a month to do it.
> > 
> > Reckon it's worth asking him, to find out if he'd be interested in this?
> 
> 
> I wouldn't do it yet until we know if we are going to delay.

I'd ask anyway.  99% of the issues he finds will be fairly localized. 
Anything truly new (not on TODO already) will probably require a fair
bit of time to track down, then fix time on top (2 months delay?).

Anyway, these types of discoveries are better in beta than after the
release and would still warrent a mention if there is a fair amount of
ground covered.


Personally, I'd be more interested in whats safe (covered) than whats
broken.  Posting the successful test cases as some proof rowards
stability / security of the new release would realize immediate gains in
settling nervous VPs about the new installation.

  27. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-08-21T17:31:26Z

    Good point;  please ask him.  We have at least on month in beta.

---------------------------------------------------------------------------

Rod Taylor wrote:
> On Wed, 2002-08-21 at 13:13, Bruce Momjian wrote:
> > Justin Clift wrote:
> > > Bruce Momjian wrote:
> > > > 
> > > > Justin Clift wrote:
> > > > > Only two things which have the potential to be worth waiting for, from
> > > > > what I'm aware of.  There may be others:
> > > > >
> > > > >  - Find out from Sir Mordred if he wants to take a look at the CVS
> > > > >    version of code and audit in that for a bit, Just In Case he turns
> > > > >    up something that's serious and requires substantial re-work.
> > > > >    Although it means he wouldn't have a bunch of "I found this existing
> > > > >    exploit" type releases, we could instead offer him credit on the
> > > > >    press release along the lines of "This released has been audited for
> > > > >    security flaws in its code by Sir Mordred".  Am pretty sure he'd
> > > > >    do a very thorough job for that, as it means he'd have an official
> > > > >    "product reputation" he'd need to stand by for it.
> > > > 
> > > > This is interesting.  He would have a month to do it.
> > > 
> > > Reckon it's worth asking him, to find out if he'd be interested in this?
> > 
> > 
> > I wouldn't do it yet until we know if we are going to delay.
> 
> I'd ask anyway.  99% of the issues he finds will be fairly localized. 
> Anything truly new (not on TODO already) will probably require a fair
> bit of time to track down, then fix time on top (2 months delay?).
> 
> Anyway, these types of discoveries are better in beta than after the
> release and would still warrent a mention if there is a fair amount of
> ground covered.
> 
> 
> Personally, I'd be more interested in whats safe (covered) than whats
> broken.  Posting the successful test cases as some proof rowards
> stability / security of the new release would realize immediate gains in
> settling nervous VPs about the new installation.
> 
> 
> 

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

  28. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Marc Fournier <scrappy@hub.org> — 2002-08-21T17:47:26Z

    On 21 Aug 2002, Robert Treat wrote:

> Assuming that we do go ahead with a 7.2.2 release, can we get some kind
> of unofficial statement on pushing back the 7.3 beta? I know Tom was

v7.3 goes beta Sept 1st ... v7.2.2 will be purely a security bugfix
release, with no changes in functionality that should (I hope?) require
anything more then a simple re-install ...

  29. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Marc Fournier <scrappy@hub.org> — 2002-08-21T17:50:36Z

    On Wed, 21 Aug 2002, Bruce Momjian wrote:

>
> We learned a few lessons from previous releases.  First, don't delay
> the beta by days/weeks that drag on.  Delay one month at a time.
> Second, don't decide on a further delay the day before you are going to
> go beta.  Multiple short-period delays and delays that happen at the
> last minute cause too many stops/starts for developers to be effective,
> so...
>
> If we are going to delay beta, we should decide now, not at the end of
> August, and the delay should be until the end of September.  The big
> question is whether we have enough material to warrant a delay.

Beta goes down in 1 week ... if we follow what we had talked about before,
within a short period of time after beta, we should be able to let ppl
dive into working on v7.4 (or 8.0, whatever we decide to call it) ... but
let's try and stick to a timeline for once, else we are going to hit the
same as the last *very* extended release ...

  30. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Marc Fournier <scrappy@hub.org> — 2002-08-21T17:52:27Z

    On Thu, 22 Aug 2002, Justin Clift wrote:

>  - Find out from Sir Mordred if he wants to take a look at the CVS
>    version of code and audit in that for a bit, Just In Case he turns
>    up something that's serious and requires substantial re-work.
>    Although it means he wouldn't have a bunch of "I found this existing
>    exploit" type releases, we could instead offer him credit on the
>    press release along the lines of "This released has been audited for
>    security flaws in its code by Sir Mordred".  Am pretty sure he'd
>    do a very thorough job for that, as it means he'd have an official
>    "product reputation" he'd need to stand by for it.

"Security Relatd Fixed" are applicable for adoption during the beta
period, leading up to release ...

>  - Patches to the CVS tree which let us have a truly native windows
>    version.  This is of huge significance and would *very* much improve
>    our growth and adoption by being in this release in comparison to
>    being in the release afterwards.  Not in an airy fairy way, but
>    quite definitely and solidly.

If they aren't in by now, they should wait until the next dev cycle ...
unless they are *small* changes ...

  31. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Marc Fournier <scrappy@hub.org> — 2002-08-21T17:57:35Z

    On Wed, 21 Aug 2002, Bruce Momjian wrote:

> Justin Clift wrote:
> > Only two things which have the potential to be worth waiting for, from
> > what I'm aware of.  There may be others:
> >
> >  - Find out from Sir Mordred if he wants to take a look at the CVS
> >    version of code and audit in that for a bit, Just In Case he turns
> >    up something that's serious and requires substantial re-work.
> >    Although it means he wouldn't have a bunch of "I found this existing
> >    exploit" type releases, we could instead offer him credit on the
> >    press release along the lines of "This released has been audited for
> >    security flaws in its code by Sir Mordred".  Am pretty sure he'd
> >    do a very thorough job for that, as it means he'd have an official
> >    "product reputation" he'd need to stand by for it.
>
> This is interesting.  He would have a month to do it.

A month in beta, ya ... or more, depending on how beta went ... but a
'Security Audit' shouldn' tlogically be done until the code base is frozen
for Beta anyway, since who knows, if it isn't frozen, whether someone is
going to introduce something else in the mean time ...

> The other issue is PITR, which I have been told today will not be ready
> for a September 1 beta but may be ready for an October 1 beta.

Then it can wait for v7.4 ... period.  Have we not learnt from past
'delays' ... hell, you yourself use "may be ready for", so, what, Oct 1st
rolls around and we delay for, say, another 2 weeks cause it "may be ready
for then"?

No ... if PITR and Native Windows aren't ready for inclusion, then they
can be the foundation for the v7.4 release ...

Sept 1st - 1st Beta ... Oct 1st is the tentative release date ... which
gives Mordred a month to audit the code and report any security bugs
before th release, where there are no substantive changes going into the
code that will invalidate his results ...

  32. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Rod Taylor <rbt@zort.ca> — 2002-08-21T17:57:37Z

    On Wed, 2002-08-21 at 13:50, Marc G. Fournier wrote:
> On Wed, 21 Aug 2002, Bruce Momjian wrote:
> 
> >
> > We learned a few lessons from previous releases.  First, don't delay
> > the beta by days/weeks that drag on.  Delay one month at a time.
> > Second, don't decide on a further delay the day before you are going to
> > go beta.  Multiple short-period delays and delays that happen at the
> > last minute cause too many stops/starts for developers to be effective,
> > so...
> >
> > If we are going to delay beta, we should decide now, not at the end of
> > August, and the delay should be until the end of September.  The big
> > question is whether we have enough material to warrant a delay.
> 
> Beta goes down in 1 week ... if we follow what we had talked about before,
> within a short period of time after beta, we should be able to let ppl
> dive into working on v7.4 (or 8.0, whatever we decide to call it) ... but
> let's try and stick to a timeline for once, else we are going to hit the
> same as the last *very* extended release ...

Agreed.  If patches are applied to the 7.4 branch as fast as normal,
then maybe 7.4 will only be 6 months out with well tested Windows, PIT,
etc. code that gets applied this October.

Whats the intended branchpoint?  Beta with less than 5 patches?  3rd
beta start period?  Less than 100 lines changed between betas?

Where is the reasonable point where double patching isn't as annoying as
waiting to apply new work?

  33. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Marc Fournier <scrappy@hub.org> — 2002-08-21T18:02:59Z

    On Wed, 21 Aug 2002, Bruce Momjian wrote:

> Justin Clift wrote:
> > Reckon it's worth asking him, to find out if he'd be interested in this?
>
>
> I wouldn't do it yet until we know if we are going to delay.

Any security audit of the code should *not* be done while the code is in
flux, and if we delay, the code would be in flux since the delay would be
to throw in a load of other code that would invalidate the audit results
...

> Oh, so it is Jan's group.  Great news;  wish someone would have told me
> sooner. I removed the Win32 off the open items list because, with no
> info and no one commenting on the item, it seemed dead for 7.3.

And it should be ... we can put the Win32 patches up on the ftp site for
ppl to play with if they want, but to include it at this late a date would
be irresponsible ...

> Well, PITR is a much more desired feature even than Win32;  the big
> question is how long PITR will actually take, seeing as we haven't see
> any patches yet.
>
> However, we haven't seen any Win32 patches yet either, so they are in
> the same boat as far as I am concerned.
>
> We have an open items list that is pretty much ready for 7.3.  The only
> open items of significance left is whether schema/DROP COLUMN stuff is
> ready in all the interfaces/apps.

We set a timeline for beta ... this time, let's stick to it ... its not
like we didn't advertise when we were going into beta ... hell, even when
the patches are presented for PITR support, who knows whether they will be
accepted, or what kinda bugs they are going to throw into the mix, or ...

  34. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Marc Fournier <scrappy@hub.org> — 2002-08-21T18:05:07Z

    On 21 Aug 2002, Rod Taylor wrote:

> Agreed.  If patches are applied to the 7.4 branch as fast as normal,
> then maybe 7.4 will only be 6 months out with well tested Windows, PIT,
> etc. code that gets applied this October.
>
> Whats the intended branchpoint?  Beta with less than 5 patches?  3rd
> beta start period?  Less than 100 lines changed between betas?

Actually, I believe the agreement on branchpoint for this release was
release date ... with the normal having been a few weeks *after* release
in previous releases ...

  35. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-08-21T18:06:29Z

    OK, beta starts on time, September 1.  I agree we should keep the
agreed-upon date, and that the propsed features aren't ready, but I had
to let the discussion happen so people felt their opinions where being
heard.

---------------------------------------------------------------------------

Marc G. Fournier wrote:
> On Wed, 21 Aug 2002, Bruce Momjian wrote:
> 
> > Justin Clift wrote:
> > > Reckon it's worth asking him, to find out if he'd be interested in this?
> >
> >
> > I wouldn't do it yet until we know if we are going to delay.
> 
> Any security audit of the code should *not* be done while the code is in
> flux, and if we delay, the code would be in flux since the delay would be
> to throw in a load of other code that would invalidate the audit results
> ...
> 
> > Oh, so it is Jan's group.  Great news;  wish someone would have told me
> > sooner. I removed the Win32 off the open items list because, with no
> > info and no one commenting on the item, it seemed dead for 7.3.
> 
> And it should be ... we can put the Win32 patches up on the ftp site for
> ppl to play with if they want, but to include it at this late a date would
> be irresponsible ...
> 
> > Well, PITR is a much more desired feature even than Win32;  the big
> > question is how long PITR will actually take, seeing as we haven't see
> > any patches yet.
> >
> > However, we haven't seen any Win32 patches yet either, so they are in
> > the same boat as far as I am concerned.
> >
> > We have an open items list that is pretty much ready for 7.3.  The only
> > open items of significance left is whether schema/DROP COLUMN stuff is
> > ready in all the interfaces/apps.
> 
> We set a timeline for beta ... this time, let's stick to it ... its not
> like we didn't advertise when we were going into beta ... hell, even when
> the patches are presented for PITR support, who knows whether they will be
> accepted, or what kinda bugs they are going to throw into the mix, or ...
> 
> 

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

  36. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-08-21T18:08:09Z

    Marc G. Fournier wrote:
> On 21 Aug 2002, Rod Taylor wrote:
> 
> > Agreed.  If patches are applied to the 7.4 branch as fast as normal,
> > then maybe 7.4 will only be 6 months out with well tested Windows, PIT,
> > etc. code that gets applied this October.
> >
> > Whats the intended branchpoint?  Beta with less than 5 patches?  3rd
> > beta start period?  Less than 100 lines changed between betas?
> 
> Actually, I believe the agreement on branchpoint for this release was
> release date ... with the normal having been a few weeks *after* release
> in previous releases ...

Actually, you proposed beta2 as the branch time for this release, and no
one objected.  I think we will have to be flexible and see how heavy the
patching is during beta, but I think the latest would be on release
date.  Our releases are very solid now, so we have very little patching
after release, and now that I and Tom are fulltime, we can handle the
load of double-patching better.

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

  37. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Robert Treat <xzilla@users.sourceforge.net> — 2002-08-21T18:19:19Z

    Let me see if I have my "release dates" straight:

A 7.2.2 release in the next week or so that fixes the bugtraq buffer
overflows and timestamp issues

A 7.3 beta on Sept 1st that has all the new schema jazz and also the
fixes for opaque (as well as other stuff from todo) during which time we
get more security auditing

Hopefully an official 7.3 release on October 1.

7.4/8.0 development will start and native windows and PITR patches can
start being submitted for that?

Robert Treat

On Wed, 2002-08-21 at 14:06, Bruce Momjian wrote:
> 
> OK, beta starts on time, September 1.  I agree we should keep the
> agreed-upon date, and that the propsed features aren't ready, but I had
> to let the discussion happen so people felt their opinions where being
> heard.
> 
> ---------------------------------------------------------------------------
> 
> Marc G. Fournier wrote:
> > On Wed, 21 Aug 2002, Bruce Momjian wrote:
> > 
> > > Justin Clift wrote:
> > > > Reckon it's worth asking him, to find out if he'd be interested in this?
> > >
> > >
> > > I wouldn't do it yet until we know if we are going to delay.
> > 
> > Any security audit of the code should *not* be done while the code is in
> > flux, and if we delay, the code would be in flux since the delay would be
> > to throw in a load of other code that would invalidate the audit results
> > ...
> > 
> > > Oh, so it is Jan's group.  Great news;  wish someone would have told me
> > > sooner. I removed the Win32 off the open items list because, with no
> > > info and no one commenting on the item, it seemed dead for 7.3.
> > 
> > And it should be ... we can put the Win32 patches up on the ftp site for
> > ppl to play with if they want, but to include it at this late a date would
> > be irresponsible ...
> > 
> > > Well, PITR is a much more desired feature even than Win32;  the big
> > > question is how long PITR will actually take, seeing as we haven't see
> > > any patches yet.
> > >
> > > However, we haven't seen any Win32 patches yet either, so they are in
> > > the same boat as far as I am concerned.
> > >
> > > We have an open items list that is pretty much ready for 7.3.  The only
> > > open items of significance left is whether schema/DROP COLUMN stuff is
> > > ready in all the interfaces/apps.
> > 
> > We set a timeline for beta ... this time, let's stick to it ... its not
> > like we didn't advertise when we were going into beta ... hell, even when
> > the patches are presented for PITR support, who knows whether they will be
> > accepted, or what kinda bugs they are going to throw into the mix, or ...
> > 
> > 
> 
> -- 
>   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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly

  38. Branch Date (Was: Re: @(#)Mordred Labs advisory 0...)

    Marc Fournier <scrappy@hub.org> — 2002-08-21T18:19:22Z

    On Wed, 21 Aug 2002, Bruce Momjian wrote:

> Marc G. Fournier wrote:
> > On 21 Aug 2002, Rod Taylor wrote:
> >
> > > Agreed.  If patches are applied to the 7.4 branch as fast as normal,
> > > then maybe 7.4 will only be 6 months out with well tested Windows, PIT,
> > > etc. code that gets applied this October.
> > >
> > > Whats the intended branchpoint?  Beta with less than 5 patches?  3rd
> > > beta start period?  Less than 100 lines changed between betas?
> >
> > Actually, I believe the agreement on branchpoint for this release was
> > release date ... with the normal having been a few weeks *after* release
> > in previous releases ...
>
> Actually, you proposed beta2 as the branch time for this release, and no
> one objected.  I think we will have to be flexible and see how heavy the
> patching is during beta, but I think the latest would be on release
> date.  Our releases are very solid now, so we have very little patching
> after release, and now that I and Tom are fulltime, we can handle the
> load of double-patching better.

Oh, even better :)  I didn't think I had succeeded in getting it brought
*that* far forward :)

  39. Dev Cycles (Was: Re: @(#)Mordred Labs advisory 0x...)

    Marc Fournier <scrappy@hub.org> — 2002-08-21T18:28:16Z

    On 21 Aug 2002, Robert Treat wrote:

> Let me see if I have my "release dates" straight:
>
> A 7.2.2 release in the next week or so that fixes the bugtraq buffer
> overflows and timestamp issues
>
> A 7.3 beta on Sept 1st that has all the new schema jazz and also the
> fixes for opaque (as well as other stuff from todo) during which time we
> get more security auditing
>
> Hopefully an official 7.3 release on October 1.
>
> 7.4/8.0 development will start and native windows and PITR patches can
> start being submitted for that?

Correct ... and, if all goes well, patches for the v7.4 branch should be
acceptable sometime mid-Sept ...



>
> Robert Treat
>
> On Wed, 2002-08-21 at 14:06, Bruce Momjian wrote:
> >
> > OK, beta starts on time, September 1.  I agree we should keep the
> > agreed-upon date, and that the propsed features aren't ready, but I had
> > to let the discussion happen so people felt their opinions where being
> > heard.
> >
> > ---------------------------------------------------------------------------
> >
> > Marc G. Fournier wrote:
> > > On Wed, 21 Aug 2002, Bruce Momjian wrote:
> > >
> > > > Justin Clift wrote:
> > > > > Reckon it's worth asking him, to find out if he'd be interested in this?
> > > >
> > > >
> > > > I wouldn't do it yet until we know if we are going to delay.
> > >
> > > Any security audit of the code should *not* be done while the code is in
> > > flux, and if we delay, the code would be in flux since the delay would be
> > > to throw in a load of other code that would invalidate the audit results
> > > ...
> > >
> > > > Oh, so it is Jan's group.  Great news;  wish someone would have told me
> > > > sooner. I removed the Win32 off the open items list because, with no
> > > > info and no one commenting on the item, it seemed dead for 7.3.
> > >
> > > And it should be ... we can put the Win32 patches up on the ftp site for
> > > ppl to play with if they want, but to include it at this late a date would
> > > be irresponsible ...
> > >
> > > > Well, PITR is a much more desired feature even than Win32;  the big
> > > > question is how long PITR will actually take, seeing as we haven't see
> > > > any patches yet.
> > > >
> > > > However, we haven't seen any Win32 patches yet either, so they are in
> > > > the same boat as far as I am concerned.
> > > >
> > > > We have an open items list that is pretty much ready for 7.3.  The only
> > > > open items of significance left is whether schema/DROP COLUMN stuff is
> > > > ready in all the interfaces/apps.
> > >
> > > We set a timeline for beta ... this time, let's stick to it ... its not
> > > like we didn't advertise when we were going into beta ... hell, even when
> > > the patches are presented for PITR support, who knows whether they will be
> > > accepted, or what kinda bugs they are going to throw into the mix, or ...
> > >
> > >
> >
> > --
> >   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
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo@postgresql.org so that your
> > message can get through to the mailing list cleanly
>
>
>

  40. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

    Neil Conway <neilc@samurai.com> — 2002-08-21T21:04:22Z

    Neil Conway <neilc@samurai.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> 
> > Vince Vielhaber <vev@michvhf.com> writes:
> > > Here's yet another.  He claims malicious code can be run on the server
> > > with this one.
> > 
> > regression=# select repeat('xxx',1431655765);
> > server closed the connection unexpectedly
> > 
> > This is probably caused by integer overflow in calculating the size of
> > the repeat's result buffer.  It'd take some considerable doing to create
> > an arbitrary-code exploit, but perhaps could be done.  Anyone want to
> > investigate a patch?
> 
> This seems to fix the problem:

No, no it does not :-)

Tom pointed out some obvious braindamage in my previous patch. I've
attached a revised version.

Cheers,

Neil

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

  41. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-08-21T21:05:01Z

    Yep, that's the plan!

---------------------------------------------------------------------------

Robert Treat wrote:
> Let me see if I have my "release dates" straight:
> 
> A 7.2.2 release in the next week or so that fixes the bugtraq buffer
> overflows and timestamp issues
> 
> A 7.3 beta on Sept 1st that has all the new schema jazz and also the
> fixes for opaque (as well as other stuff from todo) during which time we
> get more security auditing
> 
> Hopefully an official 7.3 release on October 1.
> 
> 7.4/8.0 development will start and native windows and PITR patches can
> start being submitted for that?
> 
> Robert Treat
> 
> On Wed, 2002-08-21 at 14:06, Bruce Momjian wrote:
> > 
> > OK, beta starts on time, September 1.  I agree we should keep the
> > agreed-upon date, and that the propsed features aren't ready, but I had
> > to let the discussion happen so people felt their opinions where being
> > heard.
> > 
> > ---------------------------------------------------------------------------
> > 
> > Marc G. Fournier wrote:
> > > On Wed, 21 Aug 2002, Bruce Momjian wrote:
> > > 
> > > > Justin Clift wrote:
> > > > > Reckon it's worth asking him, to find out if he'd be interested in this?
> > > >
> > > >
> > > > I wouldn't do it yet until we know if we are going to delay.
> > > 
> > > Any security audit of the code should *not* be done while the code is in
> > > flux, and if we delay, the code would be in flux since the delay would be
> > > to throw in a load of other code that would invalidate the audit results
> > > ...
> > > 
> > > > Oh, so it is Jan's group.  Great news;  wish someone would have told me
> > > > sooner. I removed the Win32 off the open items list because, with no
> > > > info and no one commenting on the item, it seemed dead for 7.3.
> > > 
> > > And it should be ... we can put the Win32 patches up on the ftp site for
> > > ppl to play with if they want, but to include it at this late a date would
> > > be irresponsible ...
> > > 
> > > > Well, PITR is a much more desired feature even than Win32;  the big
> > > > question is how long PITR will actually take, seeing as we haven't see
> > > > any patches yet.
> > > >
> > > > However, we haven't seen any Win32 patches yet either, so they are in
> > > > the same boat as far as I am concerned.
> > > >
> > > > We have an open items list that is pretty much ready for 7.3.  The only
> > > > open items of significance left is whether schema/DROP COLUMN stuff is
> > > > ready in all the interfaces/apps.
> > > 
> > > We set a timeline for beta ... this time, let's stick to it ... its not
> > > like we didn't advertise when we were going into beta ... hell, even when
> > > the patches are presented for PITR support, who knows whether they will be
> > > accepted, or what kinda bugs they are going to throw into the mix, or ...
> > > 
> > > 
> > 
> > -- 
> >   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
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo@postgresql.org so that your
> > message can get through to the mailing list cleanly
> 
> 
> 

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

  42. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Gavin Sherry <swm@linuxworld.com.au> — 2002-08-22T01:39:58Z

    On Wed, 21 Aug 2002, Gavin Sherry wrote:

> On Tue, 20 Aug 2002, Thomas Lockhart wrote:
> 
> > ...
> > > So I think that fixing the opaque problems in 7.2.x is simply
> > > impossible. Given that, the question is whether we should make a 7.2.2
> > > release with fixes for the other security holes (lpad(), rpad(),
> > > reverse(), and the datetime overruns). IMHO, we should.
> > 
> > Just a minor point: can someone actually show a symptom with date/time
> > problems in 7.2.x?
> 

[snip]

> 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.
> !#
> 
> ParseDateTime() isn't checking that str < MAXDATELEN -- which is the
> problem you solved in the datetime.c fixes.

I had a look at this code on the train. There does not appear to be any
way on conventional hardware manipulate this bug to smash the stack. This
is due to the fact that ParseDateTime() returns to the caller if it
encounters a non-printable character. It would be perhaps one of the most
impressive hacks ever if someone could dream machine code to put in the
overrun which consisted entirely of printable characters.

As such, it is remarkably unlikely that someone could exploit this bug to
execute arbitary code.

Gavin

  43. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2002-08-22T01:48:04Z

    > > If we are going to delay beta, we should decide now, not at the end of
> > August, and the delay should be until the end of September.  The big
> > question is whether we have enough material to warrant a delay.
>
> Beta goes down in 1 week ... if we follow what we had talked about before,
> within a short period of time after beta, we should be able to let ppl
> dive into working on v7.4 (or 8.0, whatever we decide to call it) ... but
> let's try and stick to a timeline for once, else we are going to hit the
> same as the last *very* extended release ...

I'd much rather see 7.3 as-is then an 8.0 not so later on with win32 native
and PITR _properly_tested_.

Chris

  44. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-08-22T04:54:28Z

    Patch applied.  Thanks.

---------------------------------------------------------------------------


Neil Conway wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> > Neil Conway <neilc@samurai.com> writes:
> > > + 	/* Check for integer overflow */
> > > + 	if (tlen / slen != count)
> > > + 		elog(ERROR, "Requested buffer is too large.");
> > 
> > What about slen == 0?
> 
> Good point -- that wouldn't cause incorrect results or a security
> problem, but it would reject input that we should really accept.
> 
> Revised patch is attached.
> 
> Cheers,
> 
> Neil
> 
> -- 
> Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

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

  45. Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

    Florian Weimer <weimer@cert.uni-stuttgart.de> — 2002-08-22T11:30:19Z

    Gavin Sherry <swm@linuxworld.com.au> writes:

> It would be perhaps one of the most impressive hacks ever if someone
> could dream machine code to put in the overrun which consisted
> entirely of printable characters.

At least for the x86 architecture, working ASCII-only shell code
exists (even shell code which consists just of letters!).  See for
example:

http://cert.uni-stuttgart.de/archive/vuln-dev/2000/10/msg00200.html

ASCII-only shellcode for RISC platforms is even harder and might be
impossible.

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          fax +49-711-685-5898