Thread

1. Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in

   Neil Conway <neilc@samurai.com> — 2002-08-20T05:47:35Z

   "Dann Corbit" <DCorbit@connx.com> writes:
   > I read (in some other message) that this buffer overrun problem has been
   > known for a very, very long time.
   
   No, the problem you're referring to (cash_out() and friends) is *not*
   a buffer overrun.
   
   Cheers,
   
   Neil
   
   -- 
   Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
   
   
   

2. Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in

   Dann Corbit <dcorbit@connx.com> — 2002-08-20T05:49:05Z

   > -----Original Message-----
   > From: Neil Conway [mailto:neilc@samurai.com] 
   > Sent: Monday, August 19, 2002 10:42 PM
   > To: Dann Corbit
   > Cc: Neil Conway; Mark Pritchard; Justin Clift; Tom Lane; 
   > Christopher Kings-Lynne; pgsql-hackers@postgresql.org
   > Subject: Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: 
   > Buffer overflow in
   > 
   > 
   > "Dann Corbit" <DCorbit@connx.com> writes:
   > > If you *know* of a buffer overrun, and simply decide not to fix it, 
   > > that sounds very negligent to me.
   > 
   > *sigh*, no one is doing that, and it is pure negligence on 
   > your part for replying to a thread that you clearly have not read.
   
   I read (in some other message) that this buffer overrun problem has been
   known for a very, very long time.
   
   To simply decide not to fix it means:
   "It's on the todo list"
   For generation after generation after generation.
   
   It does not mean that "Someday, we hope to fix this."
   
   What I am saying is that there is nothing that could possibly be more
   important than fixing this, except some other known problem that could
   also cause billions of dollars worth of damage.  Are there any such
   problems besides the buffer overrun problems?
   
   

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

   lockhart@fourpalms.org — 2002-08-20T06:21:06Z

   > To simply decide not to fix it means:
   <snip>
   > What I am saying is that there is nothing that could possibly be more
   > important than fixing this, except some other known problem that could
   > also cause billions of dollars worth of damage.  Are there any such
   > problems besides the buffer overrun problems?
   
   This is an open source project. If you, or others with similar strong
   feelings about what is important to you, would like to submit patches in
   those areas I'm sure that they would be looked on favorably.
   
   To simply insist that everyone else have the same priorities on any
   topic is a bit unrealistic. However, I'd hope that if there are folks
   who look at this particular issue with your PoV they would speak up and
   think about helping out. If you didn't state a strong opinion on the
   topic then others might never catch on that there is a potential issue,
   let alone that they could contribute to a solution...
   
                        - Thomas
   
   

4. Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in

   Jan Wieck <janwieck@yahoo.com> — 2002-08-20T13:53:47Z

   Dann Corbit wrote:
   > [...]
   > 
   > What I am saying is that there is nothing that could possibly be more
   > important than fixing this, except some other known problem that could
   > also cause billions of dollars worth of damage.  Are there any such
   > problems besides the buffer overrun problems?
   
   And what others tried to tell you is, that there are different types of
   systems and levels of vulnerability. A software that by nature needs to
   be exposed to the internet (like an SMTP, HTTP or SSH server) is in high
   danger and needs to be fixed immediately. But software that by nature
   needs to be well protected from uncontrolled access (like a database, a
   backup management system or a logical volume manager) does not.
   
   The matter of the fact is, that if you grant someone access to your
   database that gives him the power to execute the statement that triggers
   this bug, you're lost anyway. Whatever constraints you have set up, an
   empty database is usually very consistent but not neccessarily useful.
   
   
   Jan
   
   -- 
   
   #======================================================================#
   # It's easier to get forgiveness for being wrong than for being right. #
   # Let's break this rule - forgive me.                                  #
   #================================================== JanWieck@Yahoo.com #