How Integer Errors are

 
 
By Larry Seltzer  |  Posted 2004-03-11 Print this article Print
 
 
 
 
 
 
 


Exploited"> The code above shows how integer errors are not directly exploitable. Attackers need to look for consequences of the integer error, in this case a buffer overflow or underflow, that themselves are exploitable. Its the same principle when the results of a comparison are reversed because one value is very large instead of very small. Who, even just a few years ago, would have thought that a program could be remotely exploitable because of how it added two numbers together? But some of the most serious recent vulnerabilities are in this class.
Consider the Integer overflow in the Sun RPC XDR library. This nasty vulnerability had multiple exploitable buffer overflows and, even though it was originally Sun code, it made its way in to libc and glibc, and just about every other *NIX out in the world.
A bug in Microsofts Javascript implementation, JScript, is another great example. As explained in the CVE (common vulnerability and exposure) entry on the bug: an "Integer overflow in JsArrayFunctionHeapSort function used by Windows Script Engine for JScript (JScript.dll) on various Windows operating system allows remote attackers to execute arbitrary code via a malicious Web page or HTML e-mail that uses a large array index value that enables a heap-based buffer overflow attack." This is one of those promotion issues. Jscript needs to create a buffer to store some data in order to sort it. When it calculates the size of the buffer to allocate, Jscript multiples two numbers and can, in some circumstances, come up with a value greater than 32 bits. It then uses a 32-bit value to store this number, chopping off the high bits, and creating a buffer far smaller than it should be. No error is generated, so the program then goes on to write more data than there is room for in the buffer. There are many other examples. An integer overflow in the Apache Web server led to buffer busting and reports of a worm. There are similar reports on FreeBSD and OpenSSH. Its hard enough for developers to write good software for users without having to consider that people will attack a program to find bizarre behaviors. In the long term, problems such as over-and underflows will be prevented to some extent by virtual machines. Yet until the day that programmers become perfect, or that no code is released unless its been tested for years, these vulnerabilities will always be with us. Its just too darn hard to avoid them. Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. More from Larry Seltzer Check out eWEEK.coms Security Center at http://security.eweek.com for security news, views and analysis. Be sure to add our eWEEK.com security news feed to your RSS newsreader or My Yahoo page:  


 
 
 
 
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel