What provides best buffer overflow protection?

Ok, I know this is a tough one to prevent, and most apps that do provide protection are not able to protect you from every type of buffer overflow, but what would you guys say provides the best protection? Prevx1, CyberHawk, maybe Wehntrust ? Or perhaps some other app or combination of apps? Thanks.

 

Surprising, no replies. I would have thought buffer overflows would be something well known at a security forum like Wilders. From what I've heard, it is quite a hot topic with the hacker community.

Also considering most hips and other security program have little to no defense against them, one would tend to think it would be a topic of high interest here at WSF.

Maybe it's just a matter of no one knows what is best or how to stop them?

 

there have been threads on buffer overflows such as this one. its rather old though but maybe it will help you.

 

Here's an uneducated guess: use well written software and a fully patched O/S, especially if it's Windoze

 

Here's a little food for thought...

There are basically three situations where buffer overflow attacks can occur:

1. You have an application providing a network service on your machine - like a web server. In this case an attack has to come through a network connection, and the vulnerability being exploited has to be in the application providing the network service. The first course of action to limit buffer overflow attacks against such a service is to ensure it is traditional firewalling. If the service is not providing a "public" service ensure you have a NAT-enabled firewall or router between the box and your internet connection and block all inbound ports except the ones needed to provide "public" services. This limits the scope for attacks to "public" services and to other PCs already behind your NAT-enabled firewall/router - i.e. on your LAN. Any application running a "public" service must be configured to run in a dedicated non-admin user account. That was if a buffer overflow attack does occur, it is contained within that user account.

2. A "reverse" buffer overflow against a network client, such as a web browser. In this case, a rogue public server (e.g. a web-site) exploits a vulnerability in the client application by sending it too-much data. Internet Explorer has had a large number of such vulnerabilities in recent years. The most obvious defence here is to not browse the web from an admin account and keep your apps that make outbount network connections patched.

3. A local attack that passes data from one application on your PC to another - usually to elevate permissions. Bear in mind in this situation, your PC is already compromised at a low-user level before this can occur...

So, from a "protection" perspective when should you "block" a buffer overflow attack and how should you block it. Let's assume for the moment that such at attack can actually be detected. If you're a HIPS vendor and you detct such an attack, what should you do? You could drop drop the network connection, but that doesn't stop it happening again and if its UDP-based its too late for that anyway. You could kill the thread where the attack was detected, but what if that thread had resources locked, you could crash the application or deadlock it. You could terminate the process, but if its a critical system process (LSASS.EXE springs to mind here) it might cause the box to reboot, it will certainly disrupt the work going on on the PC and could introduce instability and/or data corruption. If you're really clever, you could intecept the API and system calls that the attack is making and fake returns and make it think its working when it isn't. But, at the end of the day your stack or heap have been corrupted by that attack and at some point your will get system instability or corruption.

Basically, if a buffer overflow attack occurs there is not a lot you can do from a traditional "protection" standpoint. However, there is a lot you can do to maintain the integrity of the PC. One important question to consider is why has the attacker launched this attack:

1. It could be an interactive hacker, wanting to spawn a shell.
2. It could be an automated worm, wanting to copy itself and spread.
3. It could be a Denial of Service attack.

If it's an interactive hacker, they will be causing processes to be created from the compromised application that wouldn't normally be created by that application. If the HIPS knows what is "normal" such activity could be blocked. Of course, your HIPS needs to know what is "normal" for the application so a lot of intelligence needs to be gathered about all applications "just-in-case" they get compromised.

If its an automated worm, it will need to download its payload and execute it. So again, if the HIPS knows what is "normal" behaviour for the application and creating excutables and executing them is not part of that "normal" behaviour then such files could be blocked. Again, a lot of intelligence needs to be gathered about all applications "just-in-case" they get compromised.

If its a denial of service, its probably already happened though an illegal instruction etc.

In summary, if a HIPS actually "prevents" a buffer overflow you will get system instability sooner or later and it won't prevent the overflow from happening again. The only thing that prevents it safely is patching the vulnerability. A globally-aware HIPS has a chance of blocking the overflow before it takes hold if it has an "attack signature" to look for in inbound network packets, but in order to gain this the attack needs to conform to a known vulnerabilty (so patching would block it anyway) or the packets need to be gathered, collated and commonality or attack source identified dynamically - pretty hard on one PC and logistically difficult globally.

The "best" thing a HIPS can do in response to a buffer overflow attack is monitor the activity that occurs from it, and classify new files created by it as likely-malware (taking account of existing known white and black lists). That is, its job is gathering intelligence about the attack, its behaviour and its payload and informing other PC's protected by the same HIPS about what is likely-malware.

If it works well, the application that got hit keeps running and provides the service it was designed to do, but any dropped files are blocked and system integrity is maintained. Technically the box has been "compromised" as unaithorised code has run on it, but in most cases the buffer overflow code has a very simple job, download and run the "real payload" which the HIPS will have identified and locked-down.

ghiser1

 

BufferZone and Sandboxie of course as everything is virtualised (contrary to other sandboxes).