« Surfing the big wave goodbye | Main | Sitting on the bleeding edge »

Wednesday, September 01, 2004

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.

September 1, 2004 | Permalink


TrackBack URL for this entry:

Listed below are links to weblogs that reference Why full disclosure is bad:


- Make sure you keep your software on your home computer and website as up to date as you can -

And make sure you make (external) backups at least once every day

Posted by: Franklin | Sep 1, 2004 5:04:43 PM

"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."

While it might not have been quite as bad with MySQL v3, one could still do a great deal via SQL injection. There was a run of the mill SQL injection vulnerability in phpBB's private messaging system a couple months ago. The affected query was always supposed to return one row -- if zero rows were returned, phpBB caught this anomaly and issued a HTTP 302 redirect to send the user back to his inbox. It was quite simple to tack on an AND clause to the query so that the single row would be returned only if the character at a certain position of the user's password hash was equal to a certain character. If the character at a certain position of the password hash was not equal to a certain character, zero rows would be returned and the 302 would be issued. You simply executed a few hundred HTTP requests, testing if $hash[0] == '0', $hash[1] == '1', all the way up to $hash[31] == 'f', and testing for a 200 OK or 302 redirect on each request. If a 200 was issued, you know the query returned one row, and you knew exactly what one character of the user's password hash was. Granted, it took a little more work than a simple UNION, but the end result was still the user's full password hash.

Preventing SQL injection simply requires that the programmer move to using a prepare/execute combo to build his queries, rather than placing user-defined variables right into the query. I understand that this functionality is available in MySQL 4.1, but for versions prior, it must be emulated. The easiest way to do this is to move it into one's DB layer. Rather than building queries manually outside the DB layer, you tell the layer what variable needs to be put in the query, what type of variable it is (integer, string, boolean, etc etc -- this determines what kind of filtering the DB layer does), and where exactly in the query each variable must go. The DB layer then filters appropriately -- casting integers via intval(), escaping strings using mysql_escape_string(), so on and so forth. As long as you stick to using this method for each query throughout the application, you have made SQL injection virtually impossible.

Killing XSS isn't difficult, either. I try and use the Smarty templating engine for all my projects. When using Smarty, all that is necessary to prevent XSS is to write a small wrapper class that escapes all variables passed into the template via htmlspecialchars(). Obviously, this kills some flexibility, but it is certainly possible to define "trusted" variables where no filtering is done (like those that the administrator provides).

If all PHP programmers took a little time and learned about these two simple measures, the number of vulnerabilites in PHP scripts reported on BUGTRAQ would drop by 90% overnight. Security is definitely not rocket surgery!

Posted by: Micand | Sep 2, 2004 10:10:50 AM

Absolutely agree.

Sloppy programming has no excuse and I've been as guilty as others for giving crackers a foot in the door. My problem is that this problem is magnified when the exploit is published on a mailing list. I don't doubt their intentions were honourable but the script kiddies that will use their work for thier own mischief isn't.

>The DB layer then filters appropriately -- casting integers via intval(),
>escaping strings using mysql_escape_string(), so on and so forth.

That's pretty much what I do now. XSS is a big problem. I have limited it somewhat by converting all HTML to their entity form and putting the sanitized get/post data into my own array but there are still occasions where one uses url_decode without thinking which allows for a possible vulnerability.

It's the programmers responsiblity to code defensively and I'm not making excuses for that.

Posted by: Matt | Sep 2, 2004 10:37:03 AM

Nice page! I really like it! When is the next update? 1269158523

Posted by: myspace | Aug 2, 2007 4:01:09 PM

The point of Full Disclosure is to force vendors, and web masters, even PC users, to fix their code and also keep their stuff up to date.

By not posting a PoC you say it keeps skiddies away, but do those who have the expertise to create the exploits themselves have any more of a right to use it? but I think you mean, non-skids usually have little interest in doing so.

At the end of the day, only a skid will deface hundreds of web sites a day in some sort of power trip( this is what makes them skids, they want to deface a site, any site, not interested in anything else). And so they present the main pressure for fixes to be published and applied.

Posted by: Ali | Nov 29, 2009 3:01:21 PM

The comments to this entry are closed.