For the wordpress project it’s said: If you find a bug, report it. That’s the same if it is security related. For those who feel – for whatever reason – uncomfortable to publicize it in trac directly, can shoot an email to security@wordpress.org. So trac is not the only option. But it is one.
But do not think that if you report a security related bug, that it will get fixed sooner or later. For example, the bug related to last years wordpress worm was open for a very long time. Even after it has been reported for months (and from what I’ve read in the sourcecode this bug must have been known for even longer). A patch had been provided but it took about four month or so after it finally got committed. That was a public report. If I remember correctly, no correct credits were given for the report and fix. A full report on that issue is still missing, I might write about it in a blog-post on it’s own.
But there is no need to go back into the past for such a long period. See the latest fix that resulted in the release of 2.9.2, it’s out fresh. On the blog on wordpress.org it was stated yesterday on february 15th 2010:
Thomas Mackenzie alerted us to a problem where logged in users can peek at trashed posts belonging to other authors.
I do not doubt that that guy alerted them – but so did other reporters long ago my memory reminded me. A quick search in wordpress trac revealed a bugreport that is perfectly the same issue: #11236: Trashed pages can still be opened when logged in. Reported about 3 months ago!
Is it the reporter’s responsibility to reference the earlier report and reporter? Well, in respect of prior art, he should have better done to not look like a blunder. I mean, it just might be the case that Mckenzie had read the ticket and created his “genuine” report afterwards, right? Not that I want to accuse him that he did, but who knows? How to deal with the doubts here? You can’t so it’s always better to reference and give credits – in case you are aware.
Is it the wordpress.org’s blog poster responsibility to reference the earlier report and credit the reporter? I must admit that this looks even more blunderish, because core developers have reviewed that original report long time ago. No offence to Ryan here who normally does a great job coding, but wordpress.org is only referencing Mr. Mackenzie in the blog post. Just a missing information here or lack of research prior to publishing? In a rush for a fix?
Just to say it here now, the issue was reported by caesarsgrunt / Caesar’s Grunt. WordPress.Org should update the blogpost for correctness sake. If only. Something has gone wrong.
References:
- Ticket #11236 (Nov. 23, 2009; by caesarsgrunt) – the original report
- Ticket #11401 (Dec. 11, 2009; by Denis De Bernardy) – a second report
- WordPress >= 2.9 Failure to Restrict URL Access (Feb. 13, 2010; by Thomas Mackenzie) – report by Thomas MacKenzie
- WordPress 2.9.2 (Feb. 15, 2010; by Ryan Boren) – Official WordPress 2.9.2 release blog post
- All Changes in WordPress 2.9.2 – Trac query
hakre on wordpress 
Hey.
If I am 100% honest with you here I didn’t know this existed, reason being is that the problem wasn’t named how I myself would name it.
In regards to what you have written here I understand if your upset that this was fixed under my name etc and not the name of the original finder. However the reason I think it was is that I spent a long time going over my finding, I wrote the advisory and also got help from Ryan to write the PoC. I took screenshots of the problem, and I emailed them instead of releasing it on trac.
Again I am sorry if in your eye me getting the credit was wrong. However I am sure you can appreciate that I didn’t realise that anyone had found it, and I put a lot of hours in trying to emulate the problem on local networks and VM’s so that I could prove and get WP to understand the problem.
Hey, I do not think that it is your problem what was litereally written on wordpress.org nor that the information was unavailable upfront. It’s just hard to tell afterwards, that’s all. And you clarified it now so I do not think that this is a “real” problem.
When I remember the discussions months ago correctly I think mainly it was argumented that the bug is not that “bold” that it needs a fix. So this is more or less a problem with the people behind wordpress security and not you (I need to include myself in there as well because I did not analyze the issue 100% correct in the original ticket while commenting it).
If you and ryan put efforts into it to get it covered and fixed now then it’s every user who has to thank you both for doing some work as well as to thank the original reporter. I know there are a lot of issues reported in trac and it is not easy to find out if something has been already reported or not. Not everybody writing in there has English as first language to say at least.
I have also wrote a small blog post of my own here – http://tmacuk.co.uk/?p=197 – regarding this here post.
thanks again.
Well I am glad that has got cleared up. i am sorry for any confusion that this all may have coursed, like I have said I have written a blog post on my website about the original founder of the bug and really that is all I can do.
Thanks for the quick reply Hakre, and I will be sure to keep checking out your blog and put it in my RSS.
Pingback: WordPress 2.9.2 aneb tak trochu „zbytečná“ bezpečnostní aktualizace | Separatista
Pingback: WordPress Thrashing Authorisation Bypass
From reading the ticket, it doesn’t appear to have been seen as a security issue at the time. Which is why it was worded the way it was.
I do not want to blame the original reporter for doing the actual bug report. I won’t say you do either but the line is thin in that argumentation, if you take the following into account:
From reading the blog post and the Mackenzie report, it doesn’t appear that it would have been too hard for wordpress security to search/browse core-trac for trash/Component prior to announcing.
I mean there might be multiple causes why it happened what happened. The questions should be, are we able to deal with the deficiencies like Thomas, and how can we do better next time?
Let’s see who they credit when worms related to #12416 creep up. 🙂
Spoken in the way-of-escaping-sense, maybe WP in 3.0 will move from kindergarten to preschool. Let’s see how much backwards compat the big ball is going to take until it breaks. [13357] only to have it in here.