[VIM] Confirmation (source inspection) of various r0t-discovered
jericho at attrition.org
Sun Nov 27 03:24:41 EST 2005
: I've taken a small interest in observing r0t (r0t3d3Vil) since he's done
: a whole lot of reports in the past couple of days in software that
: hasn't been reported vulnerable before... plus his blog profile says
: he's 14.
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.
: Most of his analyses are of for-purchase products, so I couldn't check
: those. At least one demo site for one vendor had been tested by him, as
: his leftover XSS attempts indicated :-/ so some of his results might be
: coming from tests of vendor demo sites.
: Anyway, for some products with source available, I was able to confirm -
: by source inspection only - several recent issues.
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.
: 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. 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
More information about the VIM