"This is a lot worse than Heartbleed, Poodle and others."
There are many security vulnerabilities that have permitted full machine takeovers in an automated fashion for a long time now. Generally speaking though such attacks only work against very small fractions of the Internet, and, no matter how big Drupal may be in absolute terms, in relative terms, it is not that large. Heartbleed was so bad because it was so widespread. So many things use OpenSSL. That you could lose private keys was just icing on the cake; the arbitrary memory read was bad enough on its own, and the difficulty of detecting it also factored into its high rating. So, yes, I'd still rate Heartbleed far, far above this. Or the Ruby YAML attack.
(POODLE was by contrast well-named; annoying, yappy, ultimately not significant enough to warrant its own entry in the Great Security Vulnerability list. Enough to worry about and mitigate and it if helps bury SSLv3, hey, great, but not a thing for universal panic the way Heartbleed or Shellshock were.)
You have a good point, but I was looking at these two points:
1- Extent of the damage
2- Number of points vulnerable
Heartbleed had (has) a lot more servers vulnerable, but the impact is a lot lower and it is a lot harder to exploit to extract valuable data. In fact, I doubt you will see a compromise or a major issue because of heartbleed (despite the mass drama).
Compared to this problem with Drupal, that is used by the many of the top sites online, the overall damage can be a lot bigger.
I disagree, the type of information that was potentially leaked by services that use openssl is much more critical than the assets you can obtain by hacking servers via the Drupal vulnerability.
My reasoning is that it's obvious (at leas I hope it is!) to your system admin that the system has been compromised when he's actively looking for indicators of compromise. This is not the case with heartbleed, so yes you can steal keys if you hack the cms and you control the server for a brief while. But this is obvious, the keys are going to rescinded, the users are going to be alerted and your access to the server is going to be severed again.
In contrast the consequences of heartbleed may not be completely known even now. What if the private keys of a linux kernel dev were compromised? The attack surface was huge, and the sensitive information covers more than only cryptographic keys. There could have been all kinds of stuff in the memory of the vulnerable servers.
Drupal (in many/most setups) executes code out of its database. These machines could be told to hack internal networks and act as botnets as the result of a single POST. Definitely wormable.
"""The Drupal Security Team was informed of this issue in the third week of September of 2014. Given the severity of the issue, we debated about releasing it early. Our main concern was when people would have the time to perform the upgrade. Drupalcon Amsterdam started on September 29th meaning that many of our community members were busy preparing for that event. The week after Drupalcon is typically busy catching up from being at Drupalcon and then October 15th was the first regularly planned security release Wednesday. We felt that it would be better to use the regularly scheduled date which also happened to be the first date when the Drupal community would be likely to have time to focus on the upgrade."""
We didn't want to disrupt the busy schedule of Drupalcon Attendees attended Drupalcon, a event to engage in discussion of the platform we, the organisers, know currently has a critical vulnerability.
We also assume attendees are uninterested in critical vulnerabilities while attending Drupalcon.
We assume attendees will be unable to return to their regular roles due to the excitement / insight / general awesomeness / other affairs unrelated to Drupal for a full week after attending out event.
Non-attendees implicitly missed out on our fun
We have now issued a fix, which is one line of code altering a database query string. Please be noted in our security advisory that you have almost no way to know whether your site was compromised and if it remains compromised.
---
It is more than terrible. It is arrogant, negligent and contempt.
"More common" might be a bit tricky, because it's always been a race once patches go out. But modern systems can hit every IP address and quite a ridiculous number of domains extremely easily. There are more targets, so while it might be just as easy to get N% of vulnerable machines, the rewards for a hacker doing that are much higher, so the incentives put you at substantially more risk.
There's also greater danger and incentive for attackers now that more websites are run by primarily non-technical people, as they are less likely to patch immediately.
I'm sure there are also indexers out there who catalogue known Drupal/Wordpress/RoR/etc sites in anticipation of quickly hitting them with an exploit once a new one is released.
It depends on the complexity of the attack. This Drupal one took our team less than an hour to have a working proof of concept (just based on the diffs).
The exploit is very simple, and doesn't require any interaction with the remote site. Explaining why they started on it very fast.
On other more complex exploits, we generally see days (if not weeks), before the attacks start.
4. Fairly robust exploit (doesn't crash the target or require version specific offsets, magic numbers, etc.)
And yes, when similar bug happens that meet these characteristics, mass scale exploitation will follow quickly after for various purpose (spamming, google ranking scam, DDOS, etc.)
If I were an attacker, I'd fingerprint sites. It should be pretty straightforward to maintain a relatively up-to-date database of web server + version, and app stack + version. Then, when a vuln hits, you know exactly whom to attack...
http://blog.sucuri.net/2014/10/drupal-sql-injection-attempts...
This is a lot worse than Heartbleed, Poodle and others. Full database / server take over for 700,000+ sites that use Drupal.