Heine

This is intended a comment on Acquia's Learning from hackers a week after the Drupal SQL Injection announcement, but mollom prevents me from posting it there. In it, scor asks:

An open question is whether the SQL injection vulnerability was exploitable via some vector other than via the user login form.

I've recently seen some recommendations to use hook_hook_info to provide "groups" to core-provided hooks so you can move your module's implementations of those hooks to $module.$group.inc. A poor-mans autoloader if you will.

Doing this can lead to unexpected results.

I recently evaluated the Bakery Single Sign-On System aka Bakery SSO aka Bakery on behalf of clients. This article describes how I moved from finding a small weakness in version 2.x-alpha-3 to an exploit.

If you haven't updated all your sites to Bakery 2.0-alpha4 (6.x, 7.x), go and do so now.

If you get bogus dates back from MSSQL, make sure PHP is compiled against the FreeTDS libary that's currently in use. If not, recompile PHP.

SA-CORE-2012-003 fixes an issue in the Drupal installer that enables an attacker to cause the site to use a different attacker-controlled database.

The installer vulnerability was found while preparing my DrupalJam presentation (NL) on security audits and reported via the (awesome!) SecuriTeam Secure Disclosure program. As promised on IRC & Reddit, here's some additional information on the root cause(s).