MIT Debuts Integer Overflow Debugger 40
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.
Re: (Score:3)
Re: (Score:3)
What flag is that then?
On an X86, "V".
Not that checking it after every add instruction is really that practical. It would be better to have trapping and non-trapping versions of integer arithmetic, and to have languages with semantics which expose that choice to the programmer.
Re: (Score:2, Interesting)
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
Re: (Score:2)
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.
The different flow of execution triggered by an overflow trap should almost always be a simple call to "abort()". At this point, your program has already failed and should be stopped.
I disagree with your premise. Garbage input values should be checked and rejected in software before the overflow ever occurs. The hardware overflow check should be a last resort to enforce this at every instruction step, and in the worst case it converts privilege exploits into less serious DOS attacks.
Allowing "garbage output
Re: (Score:2)
Overflow isn't always wrong. Two's complement arithmetic DEPENDS on ignoring an overflow AND underflow to 'just work', for example.
Re: (Score:2)
Umm, that's why I originally said that languages should explicitly support both trapping and non-trapping versions.
Re: (Score:2)
I'm pointing out that a sufficiently large number of ops will be using the non-trapping versions that it probably makes more sense for the compiler to add a check of the flags in the cases where it would be helpful.
I mosly agree with you... (Score:2)
The first big problem with integers is that they are really badly defined in C, so just like you I try to use unsigned as much as possible:
Any underflow turns into a big overflow, so it can be tested for at the same time as the overflow test, and the semantics of power-of-two sized wraparound is pretty solid on all platforms and implementations.
OTOH I don't agree that having proper overflow handling would mostly be a new source of bugs, i.e. on the new Mill cpu architecture we have a full orthogonal set of
Re: (Score:1)
That was the way it used to work, and in C at least the way it's exposed is the unsigned type.
Re: (Score:2)
Not that checking it after every add instruction is really that practical. It would be better to have trapping and non-trapping versions of integer arithmetic, and to have languages with semantics which expose that choice to the programmer.
Swift does exactly that. Every instruction is checked for overflow. Not sure how clever the compiler is in proving that certain instructions cannot overflow.
Re: (Score:1)
> Not that checking it after every add instruction is really that practical.
It's entirely practical, it's just that few compilers offer the option. And they C compilers can't offer the option for unsigned arithmetic which is defined to wrap silently.
Beyond the increase in code size (the x86 INTO instruction was one byte, but unfortunately x86-64 doesn't have it), it shouldn't even affect execution speed, as the check doesn't access memory or modify a register.
Integer overflow handling is one of the first
Re: (Score:3)
What flag is that then?
It's the Evil Bit [wikipedia.org]
Re: (Score:2)
Re: (Score:2)
The only language I know of that does checking for integer overflows is actually Swift, surprisingly enough.
Re: (Score:2)
Visual Basic.NET has it. It's on by default you can turn it off though for a project.
C# also has it, but its off by default. It also has keywords to selectively turn it on and off in specific code blocks.
Re: (Score:2)
Python dodges the question by using long when necessary. A Python long is what C would call a bignum.
Re: (Score:2)
Too bad it's not generally checked for. That's where the tool comes in.
I hate to think how many lurk in my own code (Score:2)
(int)0xFFFF... with a bunch more F's
Flawed (Score:5, Funny)
The one problem with their method is that it can only detect overflows in one direction.
Re: (Score:2)
The one problem with their method is that it can only detect overflows in one direction.
No need to worry about that anymore. Zayn Malik has left in order to fix that.
Re: (Score:2)
The one problem with their method is that it can only detect overflows in one direction.
Harry Styles just had an overflow...
Re: (Score:2)
and that one of the modules has already dropped out.
Done before (Score:3)
see also (Score:2)
gcc -ftrapv
gcc -fsanitize=undefined
Re: (Score:2)
-ftrapv hasn't worked since at least 2008. [gnu.org]
clang -fsanitize=undefined, since signed integer overflow is formally undefined.
Re: (Score:2)
Okay, research paid for with my tax dollars. Where can I download it?
You can't. The title should have read "MIT Publishes Paper Discussing Alleged Integer Overflow Debugger That You'll Never Be Able to Get Your Hands On".
(Incidentally, this isn't the first paper on a tool like this. None of the tools have ever been released for general use, although you can occasionally find buggy, research-prototype level code somewhere. I played with one a year or two ago, after several hours of rewriting their code to try and get it working on something other than the one specific confi
Mel Kaye (Score:1)
Oh man thanks so much! (Score:1)
In other news... (Score:1)
India gives up nuclear weapons. [tvtropes.org]