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

[Khalid Baheyeldin]

On Jan 16, 2008 12:13 PM, DragonWize <dragonwize at gmail.com> wrote:

> 1. non-upgraded sites are at risk otherwise there would be need to change.
>
> 2. making commit doesn't advertise anything unless you put a
> description saying what the security flaw is and how to exploit it.
> hopefully it is obvious to not ever do that, no matter when you commit
> it.
>
> 3. Unless you quietly found the hole by yourself it probably has been
> published somewhere (issue queue, etc).
>
> 4. committing code give you and others the chance to fix the issue
> with out publishing the code.
>
> Given this, I think I am still missing the point.
>
> On 1/16/08, Neil Drumm <drumm at delocalizedham.com> wrote:
> > As soon as you commit code you have publicly published the
> > vulnerability and put non-upgraded sites at risk.
> >
> > On Jan 15, 2008 11:58 PM, DragonWize <dragonwize at gmail.com> wrote:
> > > I get why you have to wait to create a security node. But why do you
> > > have to wait to commit code? I assume there is a point I am missing
> > > because we do use a VERSION control system.
> > >
> > >
> > > On 1/16/08, Derek Wright <drupal at dwwright.net> wrote:
> > > > Perhaps the docs are too detailed, confusing, hard to find, or
> > > > obscure.  I'd like to try in short, plain english to explain what to
> > > > do when you think you've found a security problem in your module:
> > > >
> > > > a) Either you think you find a potential security problem in your
> > > > module or a user reports a vulnerability to you.
> > > >
> > > > b) You *immediately* send email to security at drupal.org about it to
> > > > let us know.
> > > >
> > > > c) You try to analyze the vulnerability to the best of your
> > > > abilities, and if possible produce a patch that fixes it.
> > > >
> > > > d) DO NOT COMMIT YOUR PATCH YET.
> > > >
> > > > e) DO NOT MAKE A RELEASE YET.
> > > >
> > > > f) DO NOT MARK YOUR RELEASE AS A "SECURITY UPDATE" YET.
> > > >
> > > > g) Send your patch to security at drupal.org.
> > > >
> > > > h) Wait for the security team to reply.
> > > >
> > > > i) Do what the security team advises you to do.
> > > >
> > > > j) If/when the security team thinks your vulnerability is real, the
> > > > fix is complete, and a security announcement (SA) is ready to go
> out,
> > > > we'll tell you.
> > > >
> > > > k) Only once an SA is ready for your vulnerability and the security
> > > > team is ready to coordinate a release, THEN (and only then) do you
> > > > commit your patch to all relevant branches, tag new releases, create
> > > > release nodes, and mark them as "Security update" releases.
> > > >
> > > > l) The security team can then publish your release nodes (which
> > > > doesn't happen automatically if they're flagged as a "Security
> > > > update") and send out the SA, at which point your users will know
> > > > they need to upgrade (both via the security announcement email lists
> > > > and RSS feeds, and via the update_status module).
> > > >
> > > >
> > > > Make sense?
> > > > Do you really understand the process?
> > > > Should I explain why any of these steps are like this?
> > > > What else could be done, either via docs or project* UI, to make
> this
> > > > clear?
> > > >
> > > > Relevant issue:
> > > > http://drupal.org/node/210497
> > > > "add extra validation to release node form for security update
> releases"
> > > >
> > > > Relevant handbook docs:
> > > > http://drupal.org/security-team
> > > >
> > > > Thanks,
> > > > -Derek (dww)
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Alan Doucette
> > > Koi Technology, LLC
> > > www.KoiTech.net
> > >
> > >
> >
> >
> >
> > --
> > Neil Drumm
> > http://delocalizedham.com
> >
>
>
> --
> Alan Doucette
> Koi Technology, LLC
> www.KoiTech.net
>

Alan

There is an RSS feed here http://drupal.org/cvs

It has all the commits that went to the repository. Also cvs.drupal.org has
all the info too.

You can bet that black hat hackers are monitoring this (and other popular
projects) for exploits.

If you are a maintainer for a project and commit something here saying:
"Fixed large SQL injection hole in module", with no announcement or
release for it, then it is an invitation for an exploit.

This is why it has to be coordinated with the SA.

Yes, not all sites will upgrade the minute the release comes out, but
there is nothing that can be done about that beyond the responsible
disclosure process we are doing.
-- 
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/20080116/e7423a06/attachment.htm