(Changing the subject, so we do not pollute the original thread) On Jan 23, 2008 9:33 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
On Wed, 23 Jan 2008 11:47:34 +0000 "Stephane Corlosquet" <scorlosquet@gmail.com> wrote:
As some pointed out, the one who reports a security issue and the module maintainer(s) should be more involved in the fixing process: 1- better communication and transparency between reporters, maintainers and sec team
This sentence got my attention.
Recently I had to deal with the sec team and the experience was not that satisfying.
I'm very sorry to be missing the time for superior diplomacy because I'm very short on time so I'll go straight to the point.
I'm referring to http://drupal.org/node/198162
My experience... There may be a bit difference in details to what actually happened, without changing the substance of the experience, I've no time to go through email and IRC logs to make a precise chronological report.
- I tried to intercept people on IRC asking what to do. - nobody was able to point me to guideline to how to report a security issue, I had the impression no one was responsible for sec issues.
It is here http://drupal.org/node/101494
- people even laughed at me when I said the problem may be deep into core - when I said that I thought that SQL injection could be exploited just on Postgresql, I received even more laugh. Later Heine[1] found a way to do privilege escalation with MySQL too. - even if I submitted a quick patch nearly contextually to the sec report there was a long lag between the public SA - security@drupal.org doesn't even send an automatic reply. That's terrible... I had to go to IRC to ask if the message was received.
We get a lot of spam on that mailing list, so it is moderated.
- after the sec team was informed I didn't get any news back, I had to insist to get an idea about when a SA was going to be issued, how they were planning to deal with the vulnerability etc...
The team is entirely volunteer driven, and the amount of work is very large for it to handle. We recently asked for more volunteers and got maybe 3 responses total.
- missing transparency, having a patch ready it was really uncomfortable to decide if it was the right moment to disclose the problem autonomously or wait for an official response
The process mentioned above spells it out. You should coordinate with security and only commit when the SA is ready.
I tend to be forgiving in things related to personal character of people. I don't mind people to be opinionated or even rude, just as things get done the proper way.
I tried to play nice even when I had to deal with these issues and behave the best I could considering the information I had. Insisting that the vulnerability was important (several high profile sites exposed) and trying to sync with sec team even if there was no official response. I even did some further autonomous research to see if other module could be involved. Some of the people I had to deal with absolutely didn't deal with the issue in a way that promoted responsible disclosure.
I may had behaved like an asshole (I don't think so) but still, as I calmed down and manage the stuff at my best passing over "personal" opinions so I'd expect the same from the people on the other side.
Transparency and a honest communication channel are vital to this kind of issues.
It may had been a chance, bad luck, I don't want to point fingers to anyone. I'd just like to point to problems so that things may get better... and this should also say something about serious Postgresql support and DB knowledge.
As a side note I think that due to the success of Drupal and its larger community of developers this policy is not anymore suitable for the project: The Drupal philosophy - Escape or filter when appropriate http://drupal.org/node/101495 on a larger and larger code base, with many newcomers "when appropriate" is a slimy concept and relying on db_query didn't show to be a "catch all" solution (not to mention XSS and other kind of niceness. Drupal API is its most valuable asset. Encapsulation makes an API more valuable. If people have to discover "when it is appropriate" the API becomes less valuable. If people can't understand when it is appropriate, it is risky [2].
[1] Heine did a great job and I hope he understood I really didn't enjoy to put pressure on him, but he was the only reasonable communication point I had with sec, and I had to communicate through his personal email address since nothing ever came back from security@ I couldn't even think if he was replying in the name of the sec team or not.
[2] waiting for prepared statement since I love to pass nulls to the DB
-- Ivan Sergio Borgonovo http://www.webthatworks.it
-- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.