DragonFly kernel List (threaded) for 2003-07
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: Buffer overflow?
:..
:Seriously, if anyone could explain to me (a non-professional programmer)
:how it came to pass that buffer overflow is a non-trivial problem I would
:be truly grateful, since I've asked this before in several forums and I
:never got a real answer (that I could understand).
:
:Since this project seems primarily concerned with kernel design, are
:there any thoughts on how security could be designed into the kernel
:and isolated as much as possible from userland?
:
:This is a big topic, but the beginning of a project seems like a better
:place to consider security than at the other end.
It's all historical. The original C language library had functions
like sprintf(), strcpy(), strcat()... none of which are bounded
functions. Hundreds of thousands of programmers grew up on those
functions and they are all now microsoft employees :-).
Seriously, though, the C lib has new functions, e.g. snprintf(), and
the only way to avoid most buffer overflow problems is to use these
bounded functions and never, ever use the unbounded functions, even
if you *know* a particular use will not overflow a buffer.
The second type of buffer overflow is an array index overflow, where
an array index is incorrectly calculated or incorrectly bounded. For
example, consider the age-old misuse of malloc() where beginning
programmers would do something like: str2 = malloc(strlen(str1)),
which doesn't account for the \0 terminating the string, or programmers
who check the high side but forget that they are using a signed index
variable which could very well be negative.
If just these two problem areas were cleaned up 99% of all buffer
overflow issues would disappear.
-Matt
Matthew Dillon
<dillon@xxxxxxxxxxxxx>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]