Slashdot Mirror
MIT Debuts Integer Overflow Debugger
msm1267 writes Students from M.I.T. have devised a new and more efficient way to scour raw code for integer overflows, the troublesome programming bugs that serve as a popular exploit vector for attackers and often lead to the crashing of systems. Researchers from the school's Computer Science and Artificial Intelligence Laboratory (CSAIL) last week debuted the platform dubbed DIODE, short for Directed Integer Overflow Detection. As part of an experiment, the researchers tested DIODE on code from five different open source applications. While the system was able to generate inputs that triggered three integer overflows that were previously known, the system also found 11 new errors. Four of the 11 overflows the team found are apparently still lingering in the wild, but the developers of those apps have been informed and CSAIL is awaiting confirmation of fixes.
You're thinking too low level.
Integer overflows are only problematic when you use externally-controlled values to manipulate your internal data structures. If an attacker overflows a simple counter that I'm only going to echo back to him, it's not that big of deal. Garbage in is garbage out. It's only when I use that counter in an expression which, e.g., will malloc memory. I don't want _his_ garbage to taint the state of my program.
If you want safer behavior, then in the vast majority of of cases you don't need language semantics. At most you just need a better API. E.g. OpenBSD's new reallocarray(3) routine, which checks for multiplicative overflow when allocating an array of objects.
In fact, adding language semantics might be worse. Arithmetic overflow has become a popular vector for attack, but someday exploiting bugs in programs related to exception handling will become popular. And adding low-level language semantics which throws on overflow will only exacerbate those problems by providing more opportunities to tickle program bugs.
You don't want a program that can detect every attempt at exploitation. That just creates noise. You want robust algorithms and applications that isolate garbage values. If an attacker sends garbage, you return garbage. If his garbage causes you take take a different flow of execution, however, that provides him a way to reach bugs in the little-used parts of your code.
That's why I used unsigned values as much as possible in C. Unsigned overflow is well defined. Furthermore, it's second nature to check whether a value is beyond the _upper_ bounds of some object. But having to check for negative values (and underflow) requires twice the amount of effort and code. Plus, even better than checking for overflow is simply rolling with the punches. If you're indexing an array, sometimes it's safer to clamp the value to the range of the array, rather than adding a condition which takes an exceptional code path. You may end up with garbage output, but that's fine as long as it's because you received garbage input. Just don't let the garbage taint any other state, and don't allow it to change the flow of execution in your program unnecessarily.