From: Steven M. Christey (coley @ mitre.org)
To: bugtraq @ securityfocus.com
Date: Tue, 4 Oct 2005 17:11:51 -0400 (EDT)
Subject: A common researcher diagnosis error: misreading error messages
I am seeing increasing numbers of reports by researchers who make the same diagnostic error that you just highlighted. They throw some input for one vuln type at an application (say, XSS manipulations), get an error that shows “XSS,” and completely miss the fact that the error message shows a more serious problem at play, such as SQL injection or directory traversal. The XSS is “resultant” from these other “primary” errors.
Similarly, just because you throw a long input at a program and the program fails, it doesn’t necessarily mean that you found a buffer overflow. You could have triggered a memory allocation error; or the program didn’t recognize the argument as a valid argument; or it spotted the long input and returned a null pointer, but forgot to check and led toa null dereference; or multiple other reasons.
For those researchers who care about quality of information, make sure that you interpret error messages correctly, especially if you’re using some generic attack program that throws a lot of junk at an application. Error messages are important clues, but not the whole story.
Vulnerability information analysts – e.g. for vulnerability databases and scanning tools – should be vigilant for these common diagnostic errors.
In this particular instance, it doesn’t help that PHP’s error message generators don’t seem to quote the error messages that are generated, so a lot of “XSS-as-symptom-but-not-cause” problems are reported for PHP apps. Whether this is a problem with PHP itself or not is a separate question.