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

[Iñaki Lopez]

Just somw thoughts..

- Everyone "watching/monitoring" cvs for security holes doesn't wait
for a "security" release to be published.  It happends in a
coordinated release as the SA flow, or in not really coordinated
releases.

- Doing a coordinate release will close the time window for those
monitoring only drupal security releases, what is good in any case.
The people doing extensive monitoring will not be stopped even in a
coordinated release, as not every people can update their sites, nor
even know about the security release tags.

- Note: despite about hackers looking for site ownage.. there's
already paying services to simply get as stealthly as possible a list
of real live email addresses. This is a more real worry than a
"hacker" trying to do a php worm to deface any drupal site. It
happends also in joomla, wordpress and any other web application,
where the more close to a community is the application, bigger is the
fee..  Some email addresses can be sold for $1 each if they deserve.


 Drupal users/administrators should be encouraged to know about the
security relevant information of drupal, I don't know, maybe while
they wait the download process to finish. I know a few people hearing
how good drupal is, downloading, testing, and using their site.. after
a year they realized they did nothing about site security, or module
updates. Some of this sites are still published as they were
installed.


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

For sure I can tell you this is happening outsite of drupal scope.

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

These hackers do not have to be sad people.. everybody is free to have
it's own hobby.. IT's true also, that some scripts can do almost 90%
of the job in automated vulnerabilities finding, and more than 90% if
the scope of code is well defined: for example, drupal scope including
drupal API.

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

The cvs is already being monitored, I know (I'm not saying they are
friends in any case) some people doing it, not only in drupal, but in
many many cvs svn or even websites. I myself have spent sometime
monitoring www.debian.org website. In the front page of that site, new
security updates about debian packages are being published. It's one
of many resources being used to track and pick vulns. Also, the tools
they use to program, these named "automated test/tools" are of course,
tools to better find vulns in cvs diffs, between others..


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

Tagging a release only "security", and including only the security
patch code makes finding the vuln very very easy. Here DragonWize has
some kind of reason.. Even if you tag the update as security, just to
keep update_status tracking the new release, the diff of the two
versions can make a little difficult to really find the security code
before many sites could be patched.


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

I agree with Derek here. If fix a security bug, you probably comment
the code with the security information, or update an issue post. This
may advise a group of "monitoring" people about the flaw, even if
others may have found it time ago. The security tag should go close to
the release of the SA from drupal.


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

The only way to get this working is doing a coordinated release.

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

The cvs server is a powerfull tool, and can help to automate many
process on commit, as check some security basic tests on each file, or
even launch audit processes..

I agree again here. If drupal sec team is (or feels) in somehow
resposible of the contribs module's security status, should start
monitoring them as others do.

Sorry if I bother you, it's just an oppinion :)