>The "count" provided to the counted string functions is of type size_t,
>which is (on my machines) unsigned. This means that passing strncpy a
>negative number results in a "count" parameter that effectively means
>"infinity". I've seen at least one piece of code that had an exploitable
>overrun because of a coding mistake involving pointer arithmatic that
>resulted in strncpy() receiving a "count" of -1.
Along the same lines, I've seen the following occur:
while(bytes = recv(sock, buf, bufsize, 0))
write(fd, buf, bytes);
Normally, recv fails with a 0, but if things go wrong, it will fail with a
-1. The third argument to write is UNSIGNED. If that occurs, we'll start
at the addr of buf, and attempt to write 4GB to the fd. This is just one
example of why I do not consider signed-unsigned mismatch warnings to be
inconsequential.
Let's face it - clean, solid code is normally more secure.
David LeBlanc |Why would you want to have your desktop user,
dleblanc@mindspring.com |your mere mortals, messing around with a 32-bit
|minicomputer-class computing environment?
|Scott McNealy