Planet Drupal
Lazy loading: hook_hook_info is for hook owners only.
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.
From bug to exploit - Bakery SSO
Heine —Mon, 2013/02/18 - 12:59
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.
Explaining the Drupal < 7.16 Installer vulnerability
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).
Bounties: What to do with a high impact Drupal vulnerability?
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.
In doubt? Read the specs!
Heine —Tue, 2011/03/29 - 23:54
Specifications should be a major part of the foundation we built on. Unfortunately, we're a bit loose with our adherence to specs. (Writer is guilty too).
While this was written before, I've decided to use it as a short illustration to #1109854 - Overly aggressive transliteration in drupal_clean_css_identifier on the difference between HTML and CSS with regards to 'allowed' characters.
Best to skip if you don't care about specifications ;)
About the Webform SA
Heine —Mon, 2011/01/10 - 17:14
Today we released a security announcement about a Webform SQL Injection vulnerability outside of the normal release schedule on Wednesday.
I chose to release today with a minimal fix instead of waiting until January 12th for a combination of reasons:
- The vulnerability was made public.
- The injection requires no permissions at all.
- High impact; easy uid 1 access.
- No other user interaction required.
- Webform was under high scrutiny last week due to the Geenstijl shockblog.
- We received news today that the hole was being actively exploited.
This combination could turn out to be very damaging for a lot of Drupal sites should we have waited longer.
Versions
To clear up any confusion regarding the affected supported branches; only Webform 6.x-3.x is affected. Users of Webform 6.x.3.x should upgrade to Webform 6.x-3.5.
The Webform 6.x-2.x versions are not affected by this vulnerability. As long as you use 6.x-2.8, 6.x-2.9 or 6.x-2.10 you're good. Older versions of the Webform 6.x-2.x branch have different vulnerabilities that were already announced.
Webform for Drupal 5.x and the 7.x betas are not supported by the security team.
Unserializing user-supplied data, a bad idea
Heine —Wed, 2010/08/25 - 20:59
Apart from PHP bugs and Denial of Service attacks, there's another reason why calling unserialize on user-supplied data (cookies, hidden form fields) is a bad idea.
ZeroDayScan - Full path disclosure bug in Drupal 6.16 (0day)
Heine —Wed, 2010/04/28 - 22:01
We recently received a report by "ZeroDayScan", about a "Full path disclosure bug in Drupal 6.16".
You can read the story @ http://blog.zerodayscan.com/2010/04/full-path-disclosure-bug-in-drupal-616.html. As my short comment was removed from the post, I have to resort to a blogpost. My apologies for polluting the Planet.
Summary of the issue: If you set error reporting to the default value "Write errors to the log and to the screen", the installation path is displayed on the ...*drumroll*... screen.
Which is of course the point.
Upgraded, but Drupal still displays an old version?
Heine —Wed, 2010/01/13 - 23:37
Is your recent Drupal update not taking effect? Drupal still claims to be the old version?
It is probably correct! There's at least one module on your system that claims it is 1) a core module and 2) old. How did this happen? Common scenarios are:
- You accidentally restored the old modules folder from a backup.
- You tried to overwrite the older install, but this failed for some reason (common on ftp).
- You made a backup of core modules inside the modules or sites folder.
- You copied a core module to sites/default/modules or sites/[site]/modules to override a core module.
- You are looking at the wrong server (embarrassing, but it happens).
Remember, Drupal prefers core files in sites/all/modules or sites/[site]/modules over those in modules when it finds copies.
To identify the actual files in use, check the filename and info columns for core modules in the system table. If you don't like touching your database, install the Update: DOH! module. It will give you a list of filenames and their versions.
