Aaron Thompson writes: > the question shouldn't be: "Did it have a hole?". > it should be: "Was it fixed (properly)? and how quickly?". You need to determine why it had a hole and what design and implementation practices allowed that to happen. Doing so will allow you to determine the likelihood of more security holes in the future. With poorly designed and implemented software like BIND, Sendmail, WU-FTPD, ProFTPd, etc., you can't think you found all the security holes with any amount of confidence. You don't make software secure by removing the bugs. You make it secure by not writing them in the first place. Buffer overflows and the standard C library are a great example, both because they nicely illustrate the point and because they are likely the biggest problem area for secure software. It is difficult to manipulate strings in C using the standard library, due to a number of issues: - a pointer to a buffer tells you nothing about the size of the buffer - strings are not binary safe - absence of the terminator almost guarantees memory corruption - strncpy() does not guarantee termination - strncat() is not intuitive to use and is used differently than strncpy() and snprintf() (The OpenBSD strlcpy() and strlcat() functions fix the brain-dead design of strncpy() and strncat(), but unfortunately, most programs don't use them. While they help avoid the problem of not terminating a string, they cannot fix the size or binary data issues.) Given these issues, any programs manipulating strings using the standard string functions will be potentially vulnerable to a buffer overflow, unless the programmer was very careful to do things correctly everywhere. A programmer will usually make at least one mistake. Thus, a single vulnerability of this class means that there are likely to be other vulnerabilities, given that other places in the program have similar conditions. Looking at it from a different viewpoint shows that using a safer string handling technique can almost completely eliminate buffer overflows. The key issue here is to solve the problem instead of simply treating the symptoms. Bugs are a symptom of a bad design and implementation. -- David Phillips <david at acz.org> http://david.acz.org/ _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota http://www.mn-linux.org tclug-list at mn-linux.org https://mailman.real-time.com/mailman/listinfo/tclug-list