Gavin Sherry [EMAIL PROTECTED] 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
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
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
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.
I think the implicit casts todo should be adressed soon,
not sure there is enough time
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
Neil Conway [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Vince Vielhaber [EMAIL PROTECTED] 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
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
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(),
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
Patch applied. Thanks.
---
Neil Conway wrote:
Tom Lane [EMAIL PROTECTED] writes:
Neil Conway [EMAIL PROTECTED] writes:
+ /* Check for integer overflow */
+ if (tlen / slen != count)
+
Here's yet another. He claims malicious code can be run on the server
with this one.
Vince.
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
56K Nationwide Dialup from $16.00/mo
Vince Vielhaber [EMAIL PROTECTED] 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
On Tue, 20 Aug 2002, Tom Lane wrote:
Vince Vielhaber [EMAIL PROTECTED] 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
Vince Vielhaber [EMAIL PROTECTED] 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
Tom Lane [EMAIL PROTECTED] writes:
Vince Vielhaber [EMAIL PROTECTED] 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
Neil Conway [EMAIL PROTECTED] writes:
+ /* Check for integer overflow */
+ if (tlen / slen != count)
+ elog(ERROR, Requested buffer is too large.);
What about slen == 0?
regards, tom lane
---(end of
Vince Vielhaber [EMAIL PROTECTED] 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
-Original Message-
From: Neil Conway [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 20, 2002 1:44 PM
To: Vince Vielhaber
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0003:
Buffer overflow in PostgreSQL (fwd)
Vince Vielhaber [EMAIL PROTECTED
On 20 Aug 2002, Neil Conway wrote:
Vince Vielhaber [EMAIL PROTECTED] 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
Tom Lane [EMAIL PROTECTED] writes:
Neil Conway [EMAIL PROTECTED] 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
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
Dann Corbit wrote:
-Original Message-
From: Neil Conway [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 20, 2002 1:44 PM
To: Vince Vielhaber
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0003:
Buffer overflow in PostgreSQL (fwd)
Vince
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
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
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
Gavin Sherry [EMAIL PROTECTED] 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
...
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
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).
42 matches
Mail list logo
