Posted by greggles on October 1, 2009 at 7:00pm
It's ok to disclose immediately after the SA is released
44% (8 votes)
Wait some period of time (like 2 weeks)
28% (5 votes)
Wait until usage of the module falls off
0% (0 votes)
We should never go out of our way to disclose the real details
28% (5 votes)
Total votes: 18
Comments
The motivation for the poll
Several times people have suggested that, for educational purposes, the security team should show explanations behind the weaknesses and code changes for a vulnerability.
We also have the occasional problem where a module is marked as being abandoned because the maintainer refuses to fix the security problem and when someone asks to take it over the security team should ideally post the problem as a public issue so that a new maintainer can fix it and provide a patch publicly (the private workflow of the security team is not optimal, the more we can push public the better).
So, how long should we wait after an SA to reveal the details behind an exploit.
Some extremists would say that the proof of concept should be disclosed immediately, after all the cvs commits on a module are enough for most would-be-crackers to let them know how to exploit a vulnerability.
A more moderate approach might be after some time, like 2 weeks or 1 month.
Another possibility is to wait for the project usage to drop off significantly (below 100? below 1000? below 10?, to 10% of whatever it was originally?)
A more extreme approach on the other side is never - we could say that educating people on how to take advantage of these weaknesses which makes Drupal more likely to get attacked.
What are your thoughts?
knaddison blog | Morris Animal Foundation
I think it's better to wait...
I think it's better if the security team wait before showing the way you can take advantage from an exploit.
Every web agency or software house using Drupal starts the upgrade from the most trafficated website, if the patch is released on friday you can have websites that are not upgraded until tuesday.
I think the SA are detailed enough to understand where is the problem, and there're no reasons to put detailed information on the hand of the first script kiddie.
That's because i voted for: We should never go out of our way to disclose the real details.
Just my two cents.
Ingo86
Not publishing whatever info
Not publishing whatever info we have is just another form of security through obscurity, and opposed to the spirit of open-source, in my personal opinion.
A short delay to give people time to update is appropriate, but it should be minimal. 2 weeks might even be too long, so I voted for right away, but I don't necessarily mean same day.
A special case might be if the same information is available elsewhere. For example, if the reporter of the issue blogs about it, we should make sure the same details are available in the drupal.org issue queue where drupal users would expect to find it.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
0-2 weeks sounds fine, but how?
0-2 weeks sounds fine, but I'd want to make sure any additional disclosures don't increase the workload on the security team. Perhaps we'd just make the security.drupal.org issue public following the SA?
Not a bad idea, as long as
Not a bad idea, as long as it's announced that this will happen in the SA, so regular users no where to find it. I think the additional transparency about the Security team process is a good thing.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Best to publish immediately
It is probably best to immediately publish details including the code at fault and how it could be exploited. The reality is that the data is going to get out there. I publish stuff like this in my website all the time. The reality is that it's going to get out on the web one way or another and it would be much better for Drupal to control the message. It also serves as complete transparency and helps to educate users. Part of what I do at work is train people to do Drupal code reviews and module evaluations for security contexts. Having resources handy helps to train new people (developers and security people alike) on how to spot (and fix) security related flaws. There's no sense in sending people to gray or black hat websites for this information - why not go to the source. This makes Drupal.org the authoritative source for vulnerability information and it shows that Drupal is taking security seriously. It might also help new people get involved in Drupal security research, which can only benefit the community. Anything Drupal can do to invite the assistance of independent security researchers is a win in my book.
http://www.MadIrish.net