Security
Other vectors for SA-CORE-2014-005?
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.
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.
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.
Google Friendconnect Drupal module not recommended (yet)
Heine —Tue, 2010/01/12 - 16:01
The Friendconnect module on code.google.com is not suitable for use on production sites. My message to the 36 people who've already downloaded the module:
Test on a local site only!
I'd rather have posted this as a comments on Bertboerland's Friendconnect story, but his server ran out of steam.
Using <embed> for XSS
Heine —Fri, 2009/10/30 - 18:38
I see a lot less stray <script> tags in the "Allowed HTML tags:" of the HTML filter these days. The <embed> tag is something I still see a lot in misconfigured formats.
It's rather easy to exploit such formats to execute JavaScript with a little bit of ActionScript:
