Why full disclosure is bad

This leads on from yesterdays blog and touches on a very sore point for many web developers.

Full Disclosure [This is where] full details of the vulnerability are disclosed to the public, often through Bugtraq or similar means. This must include disclosure of the details of the vulnerability (including how to detect and exploit it). More controversially, it may also involve release of sample code or an executable tool to exploit the problem.

That's how the wonderful WikiPedia describes full disclosure which is a method of alerting developers to bugs and vulnerabilties in their code.

Before we explore why this is bad for web business, lets travel back in time a little. Way back in 1995 the web was a different place. There was growing interest for this new medium but the internet community seemed much more positive. Web sites were run by enthusiasts with a lot of technical knowledge and they relied on few scripts not written by them.
This was a time before PHP and before perl hit the big time so there wasn't the selection of 'upload, CHMOD and play' scripts that we have today. This meant that there were few common components of a website. With no publicly available scripting and relatively crude server operating systems there wasn't a lot to exploit.
Back in those dark days shareware, open source and freeware ruled the roost. Popular programs were managed and developed by hundreds of people with often no clear management or structure. Most exploits were found by enthusiasts who fixed the source code and gave the fix back into the open source pool.

The internet is a very different medium now. The market for pre-written scripts has exploded and nearly every single website will run a piece of software that is publicly available to download and the source code available to read. This makes searching for exploits a game. Rather than simply fix problems you come across these exploits are posted as some kind of trophy. Newsgroups that actively encourage posting of expoits are used by script kiddies to simply cause mischief.

Posting full details of the vulnerabilty and how to exploit vulnerabilties is bad news for everyone. Even when the vendor issues a fix, not everyone applies it immediately so the mischievious script kiddies just have to search for people still running old software - and with powerful search engines such as Google that's not much of a challenge either.

Lets look at a quick example. If a vulnerabilty is found in Windows (the most common operating system of home computer users) that allows one to gain access to the computer - and this vulnerabilty is posted with full details it won't take the average script kiddie long before they're using thousands of computers owned by slow upgraders to launch a full scale DDoS attack on their chosen target.

I have no issue with people posting that they've found a weakness in the script publicly - but I don't see the need to post HOW to exploit it. The open source movement isn't as popular as it was and most popular scripts are owned by a single company with a very clear management structure. I don't see that it's of any value to post a full disclosure report on a vulnerability found in a commercially owned script. The only people that can fix and issue a fix are the software owners. These days most project managers worth their salt take security seriously and won't delay in getting a fix ready so the "scare them into doing something" approach with full disclosure isn't really relevant anymore.

The most common argument I hear is "Well, if you coded properly...". That's a good argument but it's flawed. There are far more people trying to find a weakness in a script than people coding that script so it's just a matter of time. Also, changes in server OS and scripting / database engines will make previously "safe" code unsafe. A good example of this is the recent upgrade in MySQL. SQL injection attacks were fairly rare and relied on very poor programming to work. Now that MySQL 4 supports "UNION" to join queries, suddenly every point at which data is used in an SQL query has to be examined. Software that was written for MySQL 3 didn't have to and as such most programmers weren't anal about ensuring correct data types. There's no excuse for poor programming but you can excuse programmers for not foreseeing the future or not accounting for changes in software outside of their control.

I've seen a lot change with security over the last five years or so. When I started out, all you had to do was make sure that the flat-file database you were using didn't allow anyone to tamper with the path so malicious users couldn't read and write to otherwise unreachable files. Then, with the advances in database technology and the uptake of the popular PHP/MySQL bundle you had to watch out for SQL injections. Now XSS (cross site scripting) is probably the most common form of exploit. This relies on vulnerabilties in the code which allow the attacker to inject HTML into the normal output of a script to catch viewers cookies with then allow them to spoof this information to fool the script into logging them in as another user.

It seems that just as soon as programmers catch up on the latest techniques those pesky crackers are already onto the next method which will spread like wildfire across different software thanks to full disclosure reports.

What can we do about it? If you find an exploit please report the full disclosure privately to the company and then publish a limited disclosure report publicly. There's no need to give script kiddies more material to work with. Make sure you keep your software on your home computer and website as up to date as you can and don't rely on "it won't happen to me" to keep you safe because invariably, it will happen to you. These days any monkey with a 486 and a subscription to Bugtraq has the ability and the tools to have a good go at hacking your website.