|
|
Back to UserFriendly Strip Comments Index
|
Question about buffer overflows in MS vs *nix | by romandas | 2004-12-14 06:14:02 |
| Some other considerations, too: |
by tskelton |
2004-12-14 17:58:29 |
Several of the comments prior to mine are spot-on. A "buffer overflow" indeed does happen when a program writing into a storage area in memory continues writing beyond the end of the storage area (called the "buffer"). Depending on what used to be stored next in memory -- where this program erroneously wrote stuff -- results can be unpredictable.
If the machine architecture (read: not Intel) is such that program instructions and data areas are kept separate, then the risks are smaller. Usually, the program just kills itself because data it needed are no longer where they were put.
But if instructions and data are jumbled together in the same address space, it's entirely possible that our program run amok will -- sooner or later -- write over program instructions. This is a Bad Thing. If the garbage you write in there makes no sense when the CPU tries to interpret it as executable instructions, the OS kills the program.
Aside #1: The "buffer" that this program writes past the end of could be any kind of array, a space where a long string of characters is stored, or any other type of variable-length data area. However, the most frequent occurrence is a buffer used to receive data from the outside world -- a communications buffer for example. If the info coming in is longer than the program anticipated, one of two things can happen: the program can refuse the message because it's too long, or the program accepts the message and stores it starting where it was supposed to go, but taking however much memory it takes to store the whole message. If your program reserved 1024 bytes max as the buffer where the message is to be stored, but it receives 1536 bytes, the extra 512 bytes are "overflow" and erase whatever was stored in the next 512 bytes after the end of the space your program reserved for the buffer.
If you know how some program that is susceptible to a buffer overflow works -- because it's open source available on the web, or because somebody hacked the company's web site and got the source, for example -- and you're good, you might be able to send it a message you built just right so that the buffer overflow overwrites code that later gets executed. If you're really really good, the stuff your exploit writes into that area of code that later gets executed does something special for you -- like granting Administrator privilege, for example. That's what code trying to exploit a buffer overflow does.
Aside #2: Some programming languages check for buffer overflows / buffer overruns (basically the same thing). Some don't. If you write in a language that automatically checks for these overflows and prevents them (Ada is one example; there are others), then your code can't have a buffer overflow. But if you write in a programming language that does not check for overflows for you, you need to write the checks into your code. This is more trouble than most programmers take. Unfortunately for most code developers these days, the C language family (C, C++, C#, etc.) do not check for overflows. Most programmers don't check for overflows. Most programs, therefore, are susceptible to buffer overflows.
The solution is to either switch programming languages to something that protects from this exploit (not bloody likely) or to train programmers to anticipate this type of error and prevent it (also not likely to happen in less than geologic time). Or maybe the programmers who wrote any code that is successfully buffer-overflow-exploited should be made to face a firing squad....
|
|
[ Reply ] |
|
|
[Todays Cartoon Discussion]
[News Index]
|
|
