Re: No need for AV tools on Linux, eh?

On 14 February 2011 21:54, Rick Stevens <ricks@xxxxxxxx> wrote:
On 02/14/2011 11:23 AM, Joe Zeff wrote:
On 02/14/2011 10:03 AM, James Mckenzie wrote:
I've found very obvious buffer overflow conditions and failures to enforce changes of variable types in publically available code bases.

It's been years since I did any C programming, and my memory of it is
dusty (as Ziva David once phrased it) but I do remember that there are
two, very similar functions for copying strings.  One copies as many
bytes as you give it, the other copies only as many as you specify if
there are "too many" given.  Just using the second instead of the first
would prevent most of the easier buffer overflow exploits, if not all.
By now, I'd think that would be automatic, but then, I'm not a
programmer any more.

You're talking about "strcpy()" (copy until you see the NULL) and
"strncpy()" (copy until you see the NULL, but no more than N bytes).

To derail discussion slightly, this doesn't really fix the problem,
just shifts it to a different place (keeping track of lengths and
dynamically handling data), the problem being that people for whatever
reason, be it laziness or time pressure or something else) make poor
assumptions about the data combined with the traditional C string
handling not being great.

There are a few GNU extensions which make life much simpler, I spent a
while some time ago fixing some code which made heavy and buggy use of
static buffers for strings with a liberal application of stuff like
getline and asprintf, which is easy to do and reduces your potential
problems to memory leaks (which on most systems will die when your
application does). If you have licensing problems with glibc or need
to work on a non-gnu platform then these are pretty easily implemented
from their specs. While C hasn't moved as far as C++ or modern
languages (you have to work at allowing a buffer overrun in Python),
James Mckenzie is right, this shouldn't happen any more. Unfortunately
it still does.

--
imalone
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Relevant Pages

  • Re: Why is it dangerous?
    ... fingerd's special nature is that it used an auto buffer ... count to indexto deal with unterminated strings. ... which Paul proudly allows the programmer to ... Learning a new programming language ...
    (comp.lang.c)
  • Re: Parsing CSV files
    ... the best of mediocre programming of thirty years ago. ... libraries for strings; in the intervening years, I moved to strsafe.h, and then to CString ... failure to pass in buffer lengths, and required massive rewrites to pass buffer lengths ... very first example a programmer sees of how to do character arrays DOES ...
    (microsoft.public.vc.mfc)
  • Re: How to fix this structure?
    ... >>Who cares what the rest of the memory buffer has in it when you are ... > they build strings by themselves. ... Then they have programming error. ...
    (comp.lang.c)
  • Re: Performance of lists vs. list comprehensions
    ... dynamically-expanding buffer as I suggested. ... memory use is about the same (you just expanded the buffer using a 2x ... expansion rule then you hit the last item). ... strings are immutable (unlike lists and dicts, ...
    (comp.lang.python)
  • Re: Alternative to C for system programming
    ... be blocks of memory that are GC and nonGC, ... to call it a systems programming language with GC. ... Just make sure your disk buffer or whatever is ... allocation of memory: I/O module thinks it will need more memory ...
    (comp.programming)