61–70 of 83 posts
Earlier quoted context omitted.
That's impressive given the exploit is a day old.
FTFA: > Disclosure Timeline: > 16. Sep. 2014 - Notified the Drupal devs via security contact form > 15. Okt. 2014 - Relase of Bugfix by Drupal core Developers
IMHO this is the direct result of conflating arrays/list and hashes/dictionaries into a single thing on the programming language level. Sure, careful programming would have avoided that, but if the two concept were fundamentally different types, this bug would be impossible.
Earlier quoted context omitted.
FTFA: > Disclosure Timeline: > 16. Sep. 2014 - Notified the Drupal devs via security contact form > 15. Okt. 2014 - Relase of Bugfix by Drupal core Developers
Ah, must have overlooked the months. Makes me wonder why they left this in the wild for a month and now suddenly put thousands of installations at risk.
There's a solution that goes with the advisory. You cannot provide a patch without putting sites at risk.
Furthermore, the vulnerability was present since the Drupal 7.0 release, several years ago. There were no exploits seen in the wild. What are a few weeks then?
The team decided that speed to patch sites asap _after_ release of the information was critical. This is the reason why it was released after a pre-announcement and after a conference tying up most stakeholders.
16. Sep. 2014 - Notified the Drupal devs via security contact form 15. Okt. 2014 - Relase of Bugfix by Drupal core Developers I know it's open source volunteers & all, but that seems like a rather slow reaction to such a critical vulnerability with a simple fix, doesn't it?
This was a pretty critical part of Drupal core, so it would be irresponsible to rush out a patch without proper testing and analysis. Could it have been done quicker? Maybe. But I don't think this is a completely unreasonable period of time.
The patch adds array_values() which basically just resets the array to a 0..n index instead of whatever alpha/numeric mix it might've been before.
This means an array with a particular key can cause injection. Doesn't that seem a bit of an obscure thing to have to protect? Do people who're new to the project know about that?
Does someone understand something I don't? Even looking at the patch only, from a conceptual perspective, how does the usage of that array and its keys even make sense in a context where a certain key can allow injection?
16. Sep. 2014 - Notified the Drupal devs via security contact form 15. Okt. 2014 - Relase of Bugfix by Drupal core Developers I know it's open source volunteers & all, but that seems like a rather slow reaction to such a critical vulnerability with a simple fix, doesn't it?
Drupalcon happened during this time.
Earlier quoted context omitted.
Drupalcon happened during this time.
I really don't think that is a valid excuse for taking a month to make a one-line critical security patch.
Does anyone else think that this portion of code needs revising? The patch adds array_values() which basically just resets the array to a 0..n index instead of whatever alpha/numeric mix it might've been before. This means an array with a particular key can cause injection. Doesn't that seem a bit of an obscure thing to have to protect? Do people who're new to the project know about that? Does someone understand some…
However, arrays can have non numerical keys. This results in "placeholder_KEY", "placeholder_KEY2".
If Key is a SQL query fragment, that ends up verbatim in the placeholders section.
Suppose you pass $_GET['foo'] as a query argument. An attacker can (simplified) supply ?foo[EXPLOIT] and poof, $_GET['foo'] is an array with 'EXPLOIT' among the keys that suddenly gets into the query verbatim.
Earlier quoted context omitted.
I really don't think that is a valid excuse for taking a month to make a one-line critical security patch.
Absolutely, and also considering that the window is once a week (I believe), this should have happened ASAP.
Earlier quoted context omitted.
Drupalcon happened during this time.
I really don't think that is a valid excuse for taking a month to make a one-line critical security patch.
Coordinating a flawless release by a) not doing it during a major distraction event (DrupalCon) and b) allowing an embargo period for people within the security community to prepare is MUCH more important than rushing out the fix a few weeks earlier.
The response here is indicative of the professionalism of the Drupal security group IMHO.