You're doing a good work, Nick. Bug exploiting is not an easy way, and
you've caught quite a lot for the time you've being hunting them.
Personally, i *do* like knowing that. It would be much worse if i knew them
on option 8! I personally understand you wanting to be on such security-risk
mail list ;-)
If i tried to figure out from your reports here where the security hole was,
it'd probably be fixed when i could begin to _see_ it.
"Nick Jenkins" wrote:
[Brion Vibber wrote]:
As I understand it, this was fixed a few hours
ago, and was present for
just a
few hours before that; so if you updated from SVN trunk in the last day,
make
sure you update again. :)
Yes, I hadn't looked at the code at all until after it was fixed, and I
want to say thanks and kudos most especially to Rob Church
for getting the fix in so quickly.
Looking back at what happened, the timeline roughly went like this:
2006-06-23 13:15:59: Bug accidentally introduced by small change.
2006-06-23 19:30:00: Current SVN checked out by me.
2006-06-23 19:45:00: Test script started, and after a few minutes reports
unexpected results.
2006-06-23 20:55:00: Me narrowing down the problem.
2006-06-23 20:05:00: Details sent by me to devs.
2006-06-23 20:13:57: Bug fixed and checked into SVN.
So within 7 hours it was accidentally introduced, found, reported, and
fixed - which I think is an amazingly quick cycle ... and of
these steps, the slowest part of all was me! ;-)
[Tim Starling wrote]:
This sort of thing really doesn't need to be
reported to wikitech-l.
Whoa! Time out for a reality check.
Let me say this very simply: YOU DON'T GET TO MAKE THAT DECISION. The ONLY
person who gets to choose how a bug is reported is THE
PERSON WHO FINDS IT.
If I find a bug, then I, and only I, get to choose what to do with that
information.
Now, there are a very wide variety of responses to finding bugs.
Some of them include:
1) Do nothing. I could find a bug, and just sit on it. I don't have to
tell anybody. (For example, I never bother reporting bugs to
Microsoft any more).
2) Report it to bugzilla.
3) Report it to the developers directly via email.
4) Report it to a technical mailing list about that product, with very
limited or no details.
5) Report it to a technical mailing list about that product, with
Proof-of-Concept code.
6) Mail it straight it to bugtraq, together with Proof-of-Concept code.
7) Post it anonymously on a script-kiddies bulletin-board.
8) Sit on it, and store up exploits until there is critical number (e.g.
10), and then combine them into some kind of MediaWiki-worm
that knows how to attack all 10 exploits + change a few words / numbers in
random articles, and then release it anonymously without
warning at 3 PM on a Wednesday afternoon at peak server load, and then sit
back and watch the resulting car crash.
That's 8 possible responses, from the nice to the incredibly antisocial,
from the indifferent through to the illegal. There are more
responses, and of course some of the responses can be combined. But all of
those responses have one thing in common: None of those
decisions are made by you.
Now, as a general rule I choose to do option 3 (mail the devs) for
non-security related bugs, and option 3 + option 4 (mail the devs
+ mail a heads up to wikitech-l) for security bugs that have a working
Proof-of-Concept attack.
I choose to do this because I think it is most positive and constructive
thing to do with that information. It gives those with the
capacity to fix the problem the details they need in order to know how to
fix it; and it gives those who may be affected by the
problem the information to know that they will probably want to update
shortly and to be wary of exploits, whilst not giving
attackers the details they need to be harmful. In particular, I think
mailing wikitech-l a quick email with details of which
version(s) are affected, the general category of the security bug, but no
specific details, is useful. The reason it is useful is
because if someone chooses to run a particular tree (in spite of
suggestions that they shouldn't), they will know that there is a
particular type of security issue, and then they can update to keep
themselves protected; Also the users of those sites can be aware
of potential exploits until the problem is resolved. Last but not least,
if _I_ was running an affected MediaWiki install, then I
would want to know: so telling people this to me is a case of treating
others how you would have them treat you.
Now, if you or anyone else doesn't like those heads-up notices, then
there's a simple answer: Don't read them! I don't know about
you, but I get hundreds of spam emails per day, and I'm quite capable of
completely ignoring them, and not reading them. So if
heads-up notices about security issues in software you're involved with
bother you, then don't read them. That's YOUR response,
which YOU GET TO CHOOSE.
Of course, in my personal opinion, the best response is probably sending a
reply like this to wikitech-l:
-------------------------------------
Thank you for your MediaWiki bug report. We believe the issue that you
reported has now been fixed in SVN revision 14990
http://mail.wikipedia.org/pipermail/mediawiki-cvs/2006-June/015970.html ).
Updated releases of the stable tree are released periodically as tarballs,
and release announcements are sent to the
MediaWiki-announce mailing list. Current snapshots of the development tree
can be grabbed by doing an svn checkout/update of the
current development source code.
Thank you for your report and for helping us to make MediaWiki even
better.
-------------------------------------
Sending that to wikitech-l in response to a security heads-up on the same
list gets you several things:
1) It acknowledges that you got the original bug report.
2) It confirms that there was a problem.
3) It tells everyone that the problem is now fixed.
4) It sends the clear message that "this software is well maintained and
we respond promptly to security issues".
5) It tells any affected site admins which release / version they need to
update to order to be protected from the problem.
6) It thanks the reporter - because although you mightn't realise it,
finding these types of problems can be hard work, and a little
thanks never goes astray.
[Tim Starling wrote]:
Further to that, I would appreciate it if Nick
would commit his testing
scripts to SVN, and document them fully. It would be easier if we could
do
this testing before we commit, rather than go through all this rigmarole.
I shall be happy to email yourself and Brion an updated version of the
script that I'm using (you'll have to check it in, as I don't
have commit privileges). I'll endeavour to get it you today, but failing
that some time this week. As with all software I'm sure it
can be improved, but it's probably better to have something more current
checked in to the tree than the old version that is there
currently.
Please note however that the script mightn't be quite what you think it
is: For example, I didn't have a test for this specific
IpBlockList problem ready to go just waiting for this exact problem.
Rather I had a script that generates tests, runs those tests,
and if it fails keeps the tests. So I ran it for a few minutes, it
generated a specific IpBlockList test that failed, and then I
took a closer look at the generated test that failed, and said "Oh, that's
interesting". So it's a test generator and runner and
result-checker, not a set of predefined static tests.
As such, as a constructive suggestion, one possibility might be to add a
cronjob similar to how parserTests gets run nightly and the
results are mailed to wikitech-l. Currently the script runs until stopped
with CTRL-C, and it prints out progress information as it
goes. So as a possibility, you could perhaps update it to accept some
command line parameters (such as adding a silent mode that
only prints out real errors to make it less chatty, and adding something
so that you could specify to run for a specific amount of
time [e.g. 1 hour] instead of indefinitely, and maybe also a maximum
number of errors to report). Then the resulting nightly output
could be emailed to wikitech-l, or you could set up a separate private
mail alias if you wanted (I'd be happy to be included on
this, as it may or may not require some explaining at first about what
it's upset about, and it might require a bit of tweaking to
get the right level of information from the script). That way you'd get an
additional different and complementary type of continuous
nightly testing to help catch any regressions or other problems.
All the best,
Nick.