2007-05May-18

Secure error handling

Recently I reviewed a Visual FoxPro application for security issues. This application was using a popular file encryption DLL to transparently encrypt all tables. That's actually a good thing because unencrypted DBF files allow hackers to inject code into a VFP application. Breaking encryption algorithms is a futile exercise for all standard encryption algorithms.

Yet, it was very easy to decrypt all files, because this particular application wasn't protecting the start up process properly. What I did was to rename the encryption DLL. The application failed with an error message, because it couldn't load the DLL. Unfortunately, the error dialog was one of the standard dialogs that offer Cancel and Ignore. After hitting ignore, the next error message was something like "Crypt_Register.PRG not found".

The DLL that defined this function hasn't been loaded. When Visual FoxPro resolves a procedure name, at last it looks for an external PRG file in the current directory. Being equipped with the name of the procedure, I created a small PRG file that merely receives a number of parameters and displays each parameter in a message box. After copying the PRG to the program directory, I launched the application again. Sure enough, one of the parameters was the password.

The lesson to learn from this is that you should never allow the user to continue after an error occurred, unless you can guarantee that the program returns to a safe point. There usually is no such point until you reached READ EVENTS. If an error happens before you got to the READ EVENTS, terminate the application immediately.