The numerous APIs (have a look at, for example, ntifs.h) that accept null terminated buffers with nary a buffer size argument in sight, or that accept buffers of such buffers (terminated by another null) would seem to invite problems over time. I would argue that when we see alteration in these APIs so that buffer size can be tracked internally, then we have evidence that someone is thinking about a system whose internals are MAINTAINABLY not subject to overflow errors. Yes, you can find many overflow problems at a point in time, but changing the APIs to include the necessary checking information (and of course using it in the code) will keep problems from creeping in whenever internals tweaks are made.

This is not to denigrate the excellent suggestions in the article; I agree with those. This is just another proof point.

[ reply ]

Link to this comment: http://www.securityfocus.com/comments/articles/315/10087#10087