How many programmers does it take to create a security vulnerability?

December 12th, 2005

One uncomfortable fact that the recent [tag]SonyBMG[/tag] [tag]DRM[/tag] story has uncovered is that programmers aren't taking the necessary care to protect the end user from security vulnerabilities resulting from the use of their code.  I mean, how else can you explain the whole fiasco – both [tag]First4Internet[/tag] and [tag]SunnComm[/tag] (rival companies making [tag]copy-protection[/tag] software) released software to SonyBMG for use on audio CDs that had very serious security implications for those that installed the software installed.  First4Internet then later released an uninstaller that was even more dangerous that the original software. 


Just as the story seems to be coming to an end, SunnComm released an update to their [tag]MediaMax[/tag] copy-protection software that oddly enough seems to contain the same vulnerabilities as the original software package did.  This is a pretty sorry catalog of programming blunders that have affected literally millions of user and that will probably cost the companies involved a lot of cash, both in clearing up the mess and in future sales.


It's pretty clear that there's a serious problem somewhere – if we just concentrate on the copy-protection software used by SonyBMG we see two applications from two rival companies that contain serious flaws and both companies find difficult to either fix or come up with a safe and secure uninstaller.


It's hard to draw a single conclusion from all this but I can make a few guesses as to possible causes:


  • The applications were developed with a single goal in mind (so a copy-protection application only needs to prevent the disc being copied).
  • Security through obscurity – the idea being that no one would think of looking for security vulnerabilities in copy-protection software.
  • No thought is given to security during development.
  • The programmers aren't skilled enough to produce secure code either the first or second time around.

We can never be certain of the truth but I suspect that it is likely that there are several contributing factors at work rather than just one simple cause – after all, is a problem has a simple cause then it's easier to solve.


The next logical question to ask is how many other applications are harboring potentially dangerous vulnerabilities?  The truth is that without actively looking it's hard to tell and this raises serious concerns about the software that we all install on your systems.  It may be that PCs are literally filled with code that's insecure and waiting to be exploited.  So far the main areas of concern have been the big core applications – operating systems, office suites and browser – that have a wide install base but as this code gets tighter and more secure it is likely that hackers and those with criminal intentions will look to other applications for weaknesses they can exploit.  And if that's not enough, it doesn't seem that Open Source projects are more secure either – as Firefox has demonstrated, the more popular an application becomes, the more pressure is put on it by those looking for vulnerabilities.  It's quite possible that we have dozens of applications loaded onto our PCs that contain vulnerabilities waiting to be exploited.


So what's the answer?  It's simple – programmers have to put security at the core of applications.  Threats have grown in sophistication so that now antivirus and firewall software cannot be relied on to provide full protection and there is now a responsibility on those writing code to make sure that it is safe and secure and the testing phase has to include taking a serious look for anything that might be exploitable.


Want a good incentive to write secure code – just think about it, it might be you, your product or company at the center of the next big vulnerability story!

This entry was posted on Monday, December 12th, 2005 at 14:26 and is filed under PC Doctor Programming, PC Doctor's Thoughts, Stay Secure. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

Comments are closed.