Thread: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
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 atPop4 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
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
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
atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com
http://www.unknown-artists.com
==========================================================================
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
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
Attachment
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
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
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 atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
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, Pennsylvania19073
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
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, Pennsylvania19073
Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
From
"Christopher Kings-Lynne"
Date:
> 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
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
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
...
> 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
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 whileprocessing 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
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 ...
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
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
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, Pennsylvania19073
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 Casehe 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 linesof "This released has been audited for security flaws in its code by Sir Mordred". Am pretty sure he'd do a verythorough 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
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, Pennsylvania19073
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
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 P O S T G R E S Q L 7 . 3 O P E N I T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Source Code Changes ------------------- Schema handling - ready? interfaces? client apps? Drop column handling - ready for all clients, apps? have pg_dumpall dump out db privilege and per-user/db settings fix implicit type coercions that are worse Prepared statements - to be reviewed (Tom) improve macros in new tuple header code (Tom) integrate or move to gborg libpqxx, Pg:DBD Allow PL/PgSQL functions to return sets (Neil) Allow easy display of usernames in a group (pg_hba.conf uses groups now) fix BeOS and QNX4 ports On Hold ------- Point-in-time recovery - status? (J.R., Richard) Win32 port Security audit Documentation Changes --------------------- Mention foreign keys and SERIAL dependencies will not be in 7.2 loaded tables Document need to add permissions to loaded functions and languages
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, Pennsylvania19073
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.
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, Pennsylvania19073
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 ...
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 ...
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 ...
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?
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 ...
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 ...
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 ...
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, Pennsylvania19073
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, Pennsylvania19073
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 :)
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
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 > > >
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
Attachment
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, Pennsylvania19073
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
> > 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
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, Pennsylvania19073
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