[development] Think there's a security problem in your module? Here's what to do.

[Ivan Sergio Borgonovo]

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.
- 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.
- 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...
- 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

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