From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mike A. Harris" To: insight@sources.redhat.com Subject: Re: Buffer Overflow Patch in GDB/TCL Interface code. (fwd) Date: Thu, 19 Oct 2000 22:30:00 -0000 Message-id: X-SW-Source: 2000-q4/msg00092.html 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 To: Steven Johnson 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 >> >To: Fernando Nasser >> >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