Is DoS a vulnerability?

The latest round of Microsoft Word 2007 issues has triggered one of my rants… namely, is denial of service (DoS) a vulnerability?

Let me begin by stating that DoS is not a vulnerability — it is a result; it is an effect of an underlying issue. The fact that a DoS occurs may be an indication of a vulnerability. A long input string leading to a crash may stem from a failed buffer overflow that is exploitable under the correct conditions. Malformed TCP packets that cause the network interface to lock up, may be caused by an invalid memory allocation or a NULL pointer dereference, either of which may be exploitable.

Now, back to the Word 2007 DoS 0day claims. The so-called MS security-guru David LeBlanc touts these claims as “security features”. Word crashed due to a protection mechanism that causes a crash instead of allowing for a possible exploit. Nobody is going to argue that a crash is much preferred over an exploit, but people, such as myself and ComputerWorld’s Frank Hayes, will argue that DoS should be classified as a security concern.

LeBlanc claims that crashes and DoS conditions fall into one of three categories:

1. “Your code blew up, and you’re about to get 0wn3d. Yup, it’s exploitable, and the customers are not going to be happy.
2. Your code blew up, and maybe it is exploitable, maybe not.
3. Your code blew up, and you meant it to blow up, and it’s clearly not exploitable.”

And states that 0days fall into the third category and are unexploitable.

Hayes points out that a crash could lead to further, systemic issues. For example, researchers have found exploits (e.g., CVE-2006-3648) regarding the exception handling in other MS products (see Exploiting the Otherwise Non-exploitable on Windows). So, just because a bug (or “feature” in MS lingo) isn’t exploitable, it still may have a security impact.

Also, I would like to call into account Microsoft’s own history regarding “unexploitable crashes”. For example, the Javascript window() issue in IE was publicly reported as a DoS in May 2005 and was ignored by MS, until being reported as exploitable in November 2005. It was finally patched in MS05-054 in December 2005.

Finally, in a comment to MS, exactly how are researchers suppose to know the exploitability of your code? With everything being closed source, we cannot tell if such issues are anything beyond a denial of service.

PHP == “mainstream” security issue

After reading Bill O’Reilly’s Radar that PHP has now entered the mainstream as shown by evidence of the increased sale of beginner PHP books, I can only say that I am frightened.

Coming from the security and vulnerability space, PHP is the worst offender of security. PHP is easy to use, but hard to use securely. Stefan Esser’s Hardened PHP project goes to show how much more improving PHP needs. Giving the PHP development some credit, they have starting taking some steps to improving security, like finally disabling the register_globals and allow_url_fopen options by default. However, this is too little too late.

You can tell a language is a threat, when the vulnerability researchers have to come up with new classes of vulnerabilities just to describe the language’s security deficiencies — PHP Remote File Inclusion and Dynamic Variable Evaluation come to mind. Let’s see, how many hundred (thousands?) of websites have been compromised due to PHP’s mainstream exposure and “ease-of-use”. All of that in addition to the increased XSS threat from global variables and multiple problems with CSRF and session handling.

Even the PHP language (and Zend Engine) has had its share of critical issues: CVE-2006-3017 and CVE-2006-5465. According to NVD’s CVE data, in 2006 and 2007, PHP has had 90 reported vulnerabilities (quite a few of which were from Esser’s recent Month of PHP Bugs (MoPB)). [Sorry, I can't find a way to link to the NVD search results.]

At least people other than O’Reilly can profit off of PHP’s mainstream recognition.