[This was originally posted to the OSVDB blog.]
Yichen Xie and other Stanford researchers posted to bugtraq announcing “99 potential security vulnerabilities”, all SQL injections. Five issues/comments/questions come to mind:
1. This sounds impressive, but even by OSVDB’s level of abstraction (significantly higher than other VDBs), this is far from 99 vulnerabilities. Looking at the phpWebThings SQL injections announced, we see:
ERROR: ./forum.php:@main: _GET#g[“direction”]
ERROR: ./forum.php:@main: _POST#g[“direction”]ERROR: ./forum.php:@main: _GET#g[“sforum”]
ERROR: ./forum.php:@main: _POST#g[“sforum”]ERROR: ./forum.php:@main: _REQUEST#g[“msg”]
ERROR: ./forum.php:@main: _GET#g[“msg”]ERROR: ./forum.php:@main: _REQUEST#g[“forum”]
ERROR: ./forum.php:@main: _GET#g[“forum”]
By OSVDB standards, this is a single vulnerability (forum.php Multiple Variable SQL Injection). Even going one more level of abstraction and breaking it out by variable, we see that eight of these vulnerabilities are really four, just using different HTTP request methods. If any VDB were to break out such vulnerabilities, it would be interesting to see how it applied to the hundreds (thousands?) of previously disclosed SQL injections. Do researchers even check the different methods? In some cases, yes, but I have a feeling it is fairly rare.
Utopia NewsPro – 8 claimed – 5 actual
e107 – 16 claimed – 4 actual
myBloggie – 16 claimed – 11 actual (1 previously disclosed)
PHP Webthings – 20 claimed – 7 actual
DCP Portal – 39 claimed – 16 actual (5 previously disclosed)
Total – 99 claimed – 33 actual (6 previously disclosed) = 27 new vulns
2. Some of the issues disclosed have already been reported. Of specific interest is the myBloggie login.php username Variable SQL Injection which was originally reported Sep 5, 2005, supposedly fixed, and found to still be vulnerable using a NULL character method. So, does Stanford’s PHP-CHECKER look for such variations, or is this a case of a false positive triggered due to the incomplete fix implemented?
Why does their tool find DCP Portal POST Method calendar.php year Variable (OSVDB 20494) vulnerable to SQL injection, but not POST Method register.php name Variable (OSVDB 20493) vulnerable? Seems like the vendor would have patched all or nothing, so finding one and not the other is suspicious.
3. Has the research team used it against other packages with a history of SQL injection problems to determine if it finds the same ones? Does it no longer find them on later versions, after vendor fix? In short, how robust and how accurate is this tool?
4. The top of the post says:
More detailed information, including proof of concept exploits (vendor notified, and since patched), about the tool can be obtained from the links below.
However, the DCP Portal vulnerabilities it found were disclosed as far back as Oct 1, 2003. Were they not patched correctly? The Stanford team says they tested 6.1.1, the vendor was notified, and the vulnerabilities patched, yet the vendor download page still shows 6.1.1 as current. PHP Webthings “1.4 patched” was tested, but the vendor download page still shows that as the current version and dated 07/05/2004. They tested e107 “v0.7” but didn’t indicate that 0.7 is “in development, available from CVS”, while 0.6172 is the current stable version. The myBloggie vendor page shows 2.1.3 beta is the current version, dated 15 Jun 2005, and the same version tested by Yichen Xie et al. Only one of the five programs tested (Utopia NewPro) has confirmation of a fixed version in the news update (“UNP 1.1.5 has been released to fix a few very minor security issues.“)
So where are the fixed versions for the rest?
5. Is this tool going to be released? If so, to who? If not, why not? This tool in the right hands could potentially eliminate thousands of SQL injections in countless programs in a matter of weeks.