[VIM] Confirmation (source inspection) of various r0t-discovered issues

[Steven M. Christey]

On Sun, 27 Nov 2005, security curmudgeon wrote:

> Yep, we've been curious about this. 99% of his finds are simple cut/paste
> XSS or single back tick SQL injection testing, so it isn't surprising on
> one hand. The volume of products is interesting though. It made me wonder
> if someone had finally scripted something out to wget, untar, configure,
> make, make install and auto-paros (or the equiv) the software.

It definitely isn't source inspection.  Assuming his findings are
generally accurate, there were a couple places where he found attacks that
don't have surface-level vulnerable points in the code, e.g. one script
used callback functions that were initialized deep in an include file.

One of these days when I write down my thoughts on vulnerability
complexity, I'm gonna talk about how some vulns with complex execution
paths in the code - not findable by code analysis tools - can be subject
to the most obvious attacks, indicating the lack of basic testing.  A
"complex" vuln should have complex code paths *and* complex attacks, but I
digress.

> One of the finds had what I took to be vendor confirmation. There was a
> freshmeat announce for a new version of software that fixed XSS and SQL
> Injections. It was released a day after r0t's mail to us and secunia (not
> sure who else he is mailing), was the next logical version, etc.

I've been burned once or twice by this assumption, so I don't call it
vendor confirmation unless the original disclosure claimed vendor
coordination, which is still slightly tenuous, but I think I'm more anal
about this than most.  Coincidences are rare, but they happen.

> : For CVE-2005-3833 - Tunez "songinfo.php?song_id=[SQL]" SQL injection -
> : source code inspection of songinfo.php suggests that an addslashes() is
> : performed on the song_id parameter, so this report might be incorrect or
> : associated with a different type of issue, e.g. a SQL error from a query
> : with a non-numeric value.
>
> See above. I'm guessing based on volume alone, that he is doing no real
> testing beyond single backticks.

One of his XSS examples was hex-encoded, but I wonder if that was just
coincidence.

> So far I don't believe any of his
> vulnerability reports include working examples other than a few of the
> XSS issues. All the SQL injections are left as =[SQL] with no working
> exploit.

Yes, the lack of working examples is interesting - sometimes he doesn't
even include a simple demo URL, although he frequently abstracts them out
to the relevant scripts and parameters.  I like the "[SQL]"  and other
shorthands when researchers use them, but on the other hand it hides
whether they *really* found SQL injection or if they just provided an
invalid value that caused a non-injectable SQL error.

- Steve