What do you do with firefighters when they aren’t actively putting out fires?

IT security firms have a similar issue – what do you do with highly trained, highly paid security analysts when they aren’t responding to a 999 call from a client about a possible computer virus? The answer for some companies is to have them perform ‘static code analysis’ – laboriously looking through computer programs, hoping to spot a programming error that might be exploitable by a malicious programmer. Any errors that they find are logged and reported in confidence to the software developers. It’s an industry rule that developers are bound to respond as soon as possible and get a new version out to users before the bad guys strike.

So, the software developers get an error identified for free. The security firm gets public recognition for finding the error – which they can use to boost their credentials. Journalists take delight in publicising the activity: “Major security flaws fixed in product xyz”. The message is reinforced that users should never open files unless they are totally convinced they know who sent them. Everybody wins.

Or do they? how big a threat do these vulnerabilities actually cause, and what is the impact of fixing them?

Now, I don’t want to try and defend sloppy programming. If it says on the tin that program xyz opens files created by some long-dead software package, then it should do so. Even if a malicious user creates a file that breaks all the rules about what should be in the file, program xyz should handle it. If the bad file causes program xyz to crash, or program xyz then causes the computer to crash, then it needs fixing.

However, discovering a piece of code that won’t handle malformed files is one thing. Creating a malformed file to prove it is a bit harder. Creating a malformed file that doesn’t just crash the program, but tricks it into doing something malicious – e.g. deleting all the users’ files – is actually pretty damn hard, and in many cases impossible. Getting these malformed files into general circulation and persuading people to open them before they get spotted is also tricky (especially if the file formats are so old that PCs won’t recognise them automatically).

So, when a programming error is discovered, the risks posed are purely theoretical, with a lot of hard work required to turn them into a real life threat. However, industry practice is for software companies treat them as high priority problems, and drop all other development to fix them. Unfortunately, any software change needs testing. If a company has just completed months of testing and is on the verge of a new release, then it either has to repeat all the testing (ideal situation) or take a chance that fixing the vulnerability hasn’t broken anything else. Alternatively, it may be tempted just to drop support for older file format altogether.

So, I’m not saying that vulnerabilities shouldn’t be fixed quickly. However, I do believe that we have allowed security companies to over-inflate the potential risk they cause. This is good for their business, but not necessarily good for users, who may feel pressured into upgrading, or have to wait longer for new releases,  or end up with less thoroughly-tested software, or lose functionality from the software.

If we allowed firefighters to set building standards, we’d all be living in asbestos houses.

This entry was posted on Thursday, November 1st, 2007 at 10:18 pm and is filed under Open-source. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.