If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Buffer overflow protection

Buffer Overflows. You here about them all the time. Ever since the internet worm by rtm that exploited a buffer overflow in fingerd, they have been on the rise. So what can you do about them? Software patches come out all the time fixing these problems, but how can you protect yourself from 0-day exploits. Well, there are a few different ways.

1> Language
If you are writing your own programs, use something like Java, Python, or Perl. They have automatic bounds checking, so there is no worry about an overflow. If you do need to use C/C++, then use a library that contains bounds checking, like string and libmib. For an even more simple solution, don't use functions that are known to be dangerous. Instead of strcpy, use strncpy. Replace sprintf with snprintf.

But what if you are running someone else's program, and you don't have access to the source code. Then you can install libsafe. It watches the vulnerable functions, and makes sure that the return isn't overwritten.

2> Source Code
Source Code tools will analyze your source code, and check if there is anything that appears to be dangerous. The tools available today are not great, but they will help. its4 is one example of a static analysis tool. purify is a dynamic tool. The difference is that its4 works a lot like grep, searching for dangerous function calls. purify is more like a debugger, in that it watches the memory usage in a test run.

3> Compiler
If you have the source code, which is most likely the case in a *nix system, you can use a compiler tool. This will put protection into the program when you compile it. There are a few different ways to do this.
a. bounds checking... There have been a couple of patches written for gcc that add bounds checking to all buffers. The biggest problem with this is that your code size and execution time increase a lot.
b. move return address... If you move the return address to a "safe place" then you don't have to worry about it being written. StackShield is a program that attempts to do this.
c. canary... A "canary" value can be added to the stack every time a function is called, and ends up between the variables and the return address. Then, when the function exits, it checks to make sure the canary value hasn't been modified before returning. StackGuard does this quite well.

4> Operating System
If you make the stack non-executable, then you don't have to worry about a buffer overflow either. There are 2 problems with this approach. First, there are still ways to get the same effect, just doing things a little different. Also, there are a few (not many, but a few) legitimate programs that actually do execute things on the stack. These programs would no longer work.

5> Sandbox
One of the nice things about Java is the JVM. The JVM runs in a "sandbox" so that anything that happens in the program, can't affect the rest of your machine. janus attempts to do this for any untrusted program. It is nice, because you could run some program that you dl off the internet but don't know what it is, and not have to worry about it installing a trojan or a virus. If a buffer overflow occurs, nothing is affected, because the program is "jailed" in the sandbox. The only real problem is that Janus is still in the alpha stages....

Re: Buffer overflow protection

Originally posted here by souleman 1> Language
If you are writing your own programs, use something like Java, Python, or Perl. They have automatic bounds checking, so there is no worry about an overflow.

Just thought I'd say, QBasic does as well, if you might that of any interest.