Don’t catch exceptions

A long time ago, the developer of a competing product to my own WFTPD Pro decided that he was going to do something about GPFs in his software.

He released a new version, and declared that you would never see another GPF from his software.

How did he achieve this?

His entire main processing loop was wrapped in a massive “try { … } catch” clause, which basically ignored all GPFs, so that the program could carry on running.

At the time, I knew this was a bad idea, and resolved that I would respond to all my users who asked with a clear statement that it is better to take the GPF hit and know that something needs fixing, than to ignore the GPF, and thus ignore the error that caused it.

Today brings a nice reminder of why you should always take your GPFs with pride.

Determina posted an analysis of the latest bug in ANI processing on Windows (ANIs are animated cursors – like the hourglass, or the spinning hypno-wheel designed to make you ignore the fact that time is passing slowly).

The part that really spoke to my ideas about exception catching is as follows:

In addition to the missing /GS check, the vulnerable code in USER32.DLL is wrapped in an exception handler that can recover from access violations. If the exploit is unsuccessful, for example due to the Vista ASLR, the process will not terminate and the attacker can simply try again. This gives the attacker an easy way to bypass the ASLR protection and increase the reliability of the exploit.

In case the long technical words and acronyms caught you by surprise, that means simply that if you catch and ignore all exceptions, then the attacker can keep trying to attack your application until he gets in to your system – the application doesn’t stop and warn you that something might be wrong.

Remember, it’s the cardinal rule of programming in an unreliable world:

Don’t catch errors that you can’t fix, and don’t fix errors that you can’t catch.

[“Unreliable” includes “unsecure” as a subset.]

This is one of the reasons I dislike exception-based programming – the developer is ‘programmed’ to expect exceptions, and to treat them as a normal part of programming. Expected actions, to my mind, should be indicated by return values or returned arguments – that’s true even for error returns from functions. Exceptions should be reserved for truly exceptional circumstances – such as an attempt to execute data, or code outside of your ownership. And those exceptions should get handled by the operating system, not the application.

Obviously, if you’re programming against an API that uses exceptions as a means of communicating, you should catch those exceptions and handle them – but don’t forget to pass all other exceptions up to higher levels than you, so your program doesn’t become a paragon of reliability for your attackers.

In other words, find and fix true code errors, don’t mask and ignore them.

3 thoughts on “Don’t catch exceptions”

  1. Yes – and that’s the point, really, don’t catch exceptions unless they’re expected.
    To my mind, an exception is something unexpected. If it’s an ordinary part of operation, it’s a return value, not an exception.

Leave a Reply

Your email address will not be published. Required fields are marked *