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

[Derek Wright]

On Jan 16, 2008, at 11:47 AM, DragonWize wrote:

> I appreciate everyone trying patiently trying to explain this to me  
> and as everyone thinks that I am the only person to ever question  
> this, I will not continue the thread any further.

No one assumes you're the only one who questions this.

> I was only responding to Derek's ask for unclear parts of the process.

I'm *SO* glad you did.  It means my thread wasn't in vain, since it  
produced some more awareness and interest in the process.  Hopefully  
the thread will lead to some clarification of the reasons, or perhaps  
changes in the process itself.  No matter what, I hope this thread  
encourages some aspiring contributor to help improve the  
documentation about the process in the d.o handbooks.

> For all of our sake's, I hope that no one else has the issue of  
> this being unclear.

Of course other people have the issue of this being unclear. ;)


Ultimately, I think the debate in this thread boils down to 3 things:

1) Clarity on the threats this process is trying to protect us from.

I think Greg's email best summed it up.  We're worried about  
potential hackers finding out about security vulnerabilities before  
Drupal site maintainers have a way to plug the holes.  It's one of  
the few downsides of a fully open source project -- everyone, friend  
or foe, can see what's happening with the source all the time.


2) Disagreement on how actively hackers monitor Drupal's CVS repository.

We have no way to know this for sure, only speculation (on all  
sides).  Given that we're operating completely in the dark on this,  
in the interest of caution/safety, we should probably assume that  
hackers are paying more attention here, not less.  Certainly, they're  
going to be sad hackers if all they do is wait around for commits  
that are patching vulnerabilities.  Presumably, they're doing other  
things: their own audits, automated tests/tools, whatever.  However,  
for the sake of argument, let's assume they're *also* watching the  
commits at some level.  Agreed?


3) Disagreement about how much it helps to obfuscate the commit  
message regarding security patches.  DragonWize, you're not being  
consistent here:


On Jan 16, 2008, at 11:34 AM, DragonWize wrote:
> My point is that it is not obscurity.

On Jan 16, 2008, at 11:47 AM, DragonWize wrote:
> I advocate not marking cvc commits as security.

Which is it? ;)  Either you grant that hackers are potentially  
watching commits (in which case you claim it's better to obscure the  
reason behind the commit), or they're not (in which case it's not  
security through obscurity at all).  In both cases, I think you're  
wrong. :)

The problem is not whether the commit says it's a vulnerability or  
not.  As killes eloquently pointed out "any halfwit" can figure it  
out (side note: he wasn't calling you a halfwit, he was calling the  
potential hackers halfwits, so don't take it personally).  No matter  
if the commit happened minutes or weeks before the release goes out,  
any hacker with the faintest clue about what they're doing would do  
"cvs diff -r DRUPAL-5--1-2 -r DRUPAL-5--1-3" and see all the changes  
that happened between version 5.x-1.2 and 5.x-1.3 to narrow down  
their search for what vulnerability was fixed in 5.x-1.3.

Really, your claims about "not putting a line number for the exploit  
in the SA" boil down to security through obscurity.  The problem is  
that if the fix goes into CVS days or weeks before an official  
release goes out and a security announcement is published, that  
interested readers (hackers) will (potentially) know about the  
problem long before users can defend themselves against it.


The security team's goal with this policy can be summarized as:

"Try not to disclose *anything* about a vulnerability until there's  
an official release available that fixes it."

Committing a fix to CVS days or weeks before the releases + SA go out  
violates this goal.

Note: our goal is specifically *not*: "try to fool hackers so they  
can't figure out what the vulnerability is even once it's been  
disclosed."  That's pure folly.  Really, the only point of the  
obfuscated commit message is to attempt this foolery, and I think  
it's a joke.

So long as the commit is happening basically simultaneously with the  
release being tagged and the SA being published, I'd *rather* the  
commit message explains what it's for.  Obscurity doesn't help us  
here at all (hackers will see right through it), and in fact, some  
legitimate users of the module might actually see the commit faster  
(and realize they need to update) that way than waiting for the SA  
emails to go out, etc.

Really, once the SA happens, it's just a race to try to get everyone  
to upgrade before hackers have much of a chance to exploit it.  All  
we can do to help that race is try to make sure everyone's on the  
security announcement list, everyone's running update_status.module,  
everyone's subscribed to the security RSS feed, and make it easier  
and easier for people to upgrade their site.  The point is when does  
the clock start ticking for both parties in the race?  We'd rather  
start everyone at the same time and give them a fair chance, than  
ever give the hackers a head start in any way.

Can I get an 'amen'? ;)

Anyway, thanks for keeping an important thread alive... I don't claim  
to have all the answers here, and certainly myself and the rest of  
the security team welcome feedback on this process.  However, I think  
we have pretty reasonable justifications for the current policy, even  
if everything isn't as clearly explained and documented as it could be.

Cheers,
-Derek (dww)

p.s. Note: no one on the security team has any illusions that this  
process, alone, leads to complete  security for all of Drupal.  Of  
course there are many vulnerabilities in contrib, and probably still  
some in core, and it's entirely likely that hackers know about these  
and we don't.  That's a completely separate question from the  
situation of how we handle it when we *do* find out about a  
vulnerability. The solutions to the former problem are getting more  
security experts involved on the security team, better automated  
tools/tests for our side, more general awareness and concern about  
security in the Drupal community (both users and developers), etc,  
etc.  All of that is worthy, and on-going, and we always need more  
help.  But, that's off topic from the point of this particular thread.