Re: Buffer Overflow Patch in GDB/TCL Interface code. (fwd)

Re: Buffer Overflow Patch in GDB/TCL Interface code. (fwd)

[Mike A. Harris]

Oops, my reply didn't go to the list..  



----------------------------------------------------------------------
      Mike A. Harris  -  Linux advocate  -  Open source advocate
              Computer Consultant - Capslock Consulting
                 Copyright 2000 all rights reserved
----------------------------------------------------------------------


---------- Forwarded message ----------
Date: Fri, 20 Oct 2000 01:28:12 -0400 (EDT)
From: Mike A. Harris <mharris@opensourceadvocate.org>
To: Steven Johnson <sbjohnson@ozemail.com.au>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: Buffer Overflow Patch in GDB/TCL Interface code.

On Fri, 20 Oct 2000, Steven Johnson wrote:

>> >Date: Thu, 19 Oct 2000 09:20:54 -0700
>> >From: Syd Polk <spolk@redhat.com>
>> >To: Fernando Nasser <fnasser@cygnus.com>
>> >Cc: insight@sources.redhat.com
>> >Content-Type: text/plain; charset=us-ascii
>> >Subject: Re: Buffer Overflow Patch in GDB/TCL Interface code.
>> >
>> >My only concern is whether this call, asprintf, is available on all platforms.
>> >
>> 
>> IMHO, calls to any functions such as this, are just oddball
>> memleak situations waiting to happen.  I've never heard of
>> asprintf before myself..  Shouldn't it also be asnprintf() to
>> avoid a potential overflow?  Sorry if not, as I haven't looked at
>> the actual usage in the code.  Just some thoughts to share..
>> 
>
>I had the same "concerns" but it seemed to be the cleanest way around the
>problem. It is generally very easy to ensure that no memleak situations occur,
>because the sprintf's in question had a very specific and localized access to a
>temporary buffer. It was very easy to ensure there was an unambiguous matching
>free. It wasn't like the buffer was created and in some function somewhere else
>it was cleaned up. The code in 99% of the cases was like this:
>
>char *buf;
>
>asprintf(&buf,"Hello %s %s %s %s %s",p1,p2,p3,p4,p5);
>
>execute_tcl_command(buf);
>
>free(buf);
[SNIP]
>If you can suggest a better way to do it, without requiring fixed buffer sizes
>of enormous size, and without re-inventing the wheel (ie, re-implementing
>asprintf) Then i'd be more than willing to change my submission.
>
>This problem is real, it causes insight to segfault, and it would be a shame if
>it went unfixed due to an unfounded memleak concern.

No, sounds like it is ok.  I was just voicing a possibility for
others to consider.  Looks like you've covered the bases
though.  I'm just leary of functions that internally malloc and
expect a manual free() from someone else..  They tend to create
hard to find bugs.

Take care!
TTYL


----------------------------------------------------------------------
      Mike A. Harris  -  Linux advocate  -  Open source advocate
              Computer Consultant - Capslock Consulting
                 Copyright 2000 all rights reserved
----------------------------------------------------------------------

"A Firewall is really much like a sophisticated traffic cop; it detects and
stops unauthorized or suspicious movement in or out of the network. But
security is more than a Firewall; it's a process. You can't just put in a
Firewall and think you're secure."

[Quote: Linus Torvalds - Aug 27, 2000 - linux-kernel mailing list]
"And I'm right.  I'm always right, but in this case I'm just a bit more
right than I usually am." -- Linus Torvalds