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

[DragonWize]

Khalid said:
"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 completely my point:

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.

Even after the SA has been released you should never commit a message
saying you fixed a security hole. That would be like putting the line
# of the hole in the SA. You don't say what the hole is, where it is,
or how to exploit it. This goes true for any commit you ever do.
Because then they have to find, which they had to find it anyway so
there is no difference between committing and not committing. In fact
if you coordinate the commit with the SA you are just making it that
much easier for them to find it.

I am sorry Khalid. I am not trying to be difficult or argumentative. I
truly don't see what change is made be not committing.

Alan

On 1/16/08, Khalid Baheyeldin <kb at 2bits.com> wrote:
> 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.


-- 
Alan Doucette
Koi Technology, LLC
www.KoiTech.net