[development] How to report a security issue
Khalid Baheyeldin
kb at 2bits.com
Wed Jan 23 14:52:35 UTC 2008
(Changing the subject, so we do not pollute the original thread)
On Jan 23, 2008 9:33 AM, Ivan Sergio Borgonovo <mail at webthatworks.it> wrote:
> On Wed, 23 Jan 2008 11:47:34 +0000
> "Stephane Corlosquet" <scorlosquet at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080123/413ac1cb/attachment.htm
More information about the development
mailing list