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

[DragonWize]

Revisiting the original issue.

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:

It is apparent through Derek's plea here that module developers are
not following the security teams protocol. I see 2 main reasons why:

1. Education. This will always be a challenge but helps if you have a
marketable version of the information you are trying to get out to
everyone.
2. Getting module developers on board with the process.

As it has been pointed out several times, the point of the process is
to get out important updates and announcements to Site Admins in the
best and safest way possible.

Well let me point out that if you make the process difficult, that
will be a deterrent for developers to follow the process. While
security is very important, you have to be willing to see the end
value and not just the perceived value of the process.

If you have an super secure process but developers don't follow it,
where does that leave the Site Admins? In a much worse position than
if the process was simpler and provided slightly less security
proccess. It is much better to have a 90% secure process that is
followed than a 100% secure process that is NOT followed.

With that in mind I would like to revisit the process:

> a) Either you think you find a potential security problem in your
> module or a user reports a vulnerability to you.

This is a description and doesn't help the marketability of the process.

> b) You *immediately* send email to security at drupal.org about it to
> let us know.

Agreed. This easy to understand, perform and educate. Maybe also have
other ways for developers & users alike to the security team that
doesn't make them have to remember the email address. The more ways to
contact them with important information the better.

> c) You try to analyze the vulnerability to the best of your
> abilities, and if possible produce a patch that fixes it.

More added descriptions that doesn't help the marketability.

> d) DO NOT COMMIT YOUR PATCH YET.

This stops all development and is not friendly to the developer. We
have shown this step provides little to no benefit or possible harm. I
think that no matter what your position on the subject is, this is an
easy step to remove to make the process better.

> e) DO NOT MAKE A RELEASE YET.

This too I think is going over board. I will describe more about what
I propose below.

> f) DO NOT MARK YOUR RELEASE AS A "SECURITY UPDATE" YET.

I think that marking something as a security release should be taken
out of the hands of the developers. Only the security team should be
able to do this. More info below.

> g) Send your patch to security at drupal.org.

This is more work for the developer that can easily be removed by
having the security team use our version control system.

> h) Wait for the security team to reply.

More description.

> i) Do what the security team advises you to do.

More description and slightly unfriendly in the fact is makes you feel
like the security team is your boss. While I know that the security
team is a great bunch of people and this is not true about the process
or how they work with people, this step gives the wrong impression to
those that do not know that.

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

This is a security team process not needed for the developer process.

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

Again, I think that this should be a security team step not a
developer. See below.

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

Agreed.

Now let me propose a modified process:

Developers Process:
1. Contact the security team with information about security holes.
2. Do NOT post security vulnerabilities. The Security team will take
care of that.

That is a very marketable process. In the handbooks and other places
we can elaborate with more information if needed.

Security Team Process:
1. Coordinate with the developer to evaluate the hole and fix.
2. Coordinate with the developer on which revision # is safe to
publish as an Official security release.
3. Publish or mark a release as security update and send out the announcements.

Let me explain these proposed processes a little. Getting knowledge
into the security teams hands is the first and most important thing.
Once the security team has that knowledge they can communicate with
the developer on the problem and fix.

The developer should go about his normal work flow except we need to
educate them that only the security team should announce security
holes or updates. This is to help the security race.

The security team should then coordinate with the developer on what
revision # is safe to mark as a security release. This could be an
already published release or a revision # of one of the branches. The
security team would then, at their discretion, mark or publish a
release as a security release and send out announcements.

I realize that many people may find that this approach is lacking in
certain areas but I honestly believe the final result would be much
more secure even if the the process is not as secure.

We would then educate developers and users by creating a security
report form and linking to it from all appropriate places. On this
form page make it clear to not advertise the security hole or the fix
because the security team will do a coordinated security release and
announcement. It is also very easy to educate developers by just
saying: "Contact the security team". Which is much easier than having
grok man pages and long processes.

This also makes it very easy for the security team to change their
policies or procedures without having to re-educate all developers.

Just my 2 cents. Thoughts?

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