Heine Fri, 2014/10/31 - 21:57
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.
Heine Tue, 2013/07/30 - 22:38
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.
Heine Mon, 2013/02/18 - 12:59
Heine Thu, 2012/11/29 - 19:24
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.
Heine Wed, 2012/10/24 - 11:24
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).
Heine Mon, 2012/06/11 - 10:31
The security landscape is changing. There's been on and off talk about bounties for security vulnerabilities and some firms already buy vulnerabilities (SecuriTeam, ZDI). This also causes me to re-evaluate the value of a vulnerability.
Suppose I've recently found an arbitrary code execution vulnerability that could very likely be exploited on a large fraction of 400K+ Drupal sites.
What do you think I should do with it?
For the comments: What's your opinion on a security vulnerability bounty program?
Update: I've reported the vulnerability via SecuriTeam. It has been fixed with the release of Drupal 7.16. See SA-CORE-2012-003 for details.