41–50 of 83 posts
Earlier quoted context omitted.
900k+ sites with Drupal, including many government sites. This is a pretty major exploit - any site running unpatched can be shelled.
Isn't this just a Drupal 7 issue? Still will affect a lot, but I know plenty Drupal installations from that 900k+ figure that are on 5 and 6.
Hmm, my install is not saying there is a core update... Normally it does this.
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?
For those who don't want to do a full core update, you can apply a one line patch by the looks of it. http://www.reddit.com/r/drupal/comments/2jbuiz/drupal_732_fi...
Why don't people see the pattern?
Poorly coded software results in security holes.
And IN statements are stupid with prepared statement. If you can leverage a «hit or miss» cache effect with a IN statement, you don't need the IN, elsewhise it is inefficient.
Good solution is when you can do it: replace IN with join avoiding the shameful pit of Mysql poor performances in subqueries.
The other solution is to avoid IN statement because it cannot be protected with the bind trick.
And Stackoverflow has the same solutions proposed everywhere, and since people have no critical sense, this bug is everywhere where people are using IN with prepared statement.
http://stackoverflow.com/questions/920353/can-i-bind-an-arra... http://stackoverflow.com/questions/1586587/pdo-binding-value... http://stackoverflow.com/questions/589284/imploding-a-list-f... http://stackoverflow.com/questions/3703180/a-prepared-statem...
For those who don't want to do a full core update, you can apply a one line patch by the looks of it. http://www.reddit.com/r/drupal/comments/2jbuiz/drupal_732_fi...
7.32 is a one line change btw, so the patch is same difference.
Drupal like GnuTLS, like openSSL, like joomla, and like a lot of code out there as always been recognized poor quality unreadable code by my own eyes. (Like some parts of the linux kernel) Why don't people see the pattern? Poorly coded software results in security holes. And IN statements are stupid with prepared statement. If you can leverage a «hit or miss» cache effect with a IN statement, you don't need the IN, e…
If you use MSSQL you can use IN just fine: use a table valued parameter to feed in values to look for. It's only one parameter so you get plan caching for 1, 2 ... n rows in your table valued parameter. (Although plan re-use is not always a good thing: the plan generated for 1 parameter = 1 row is necessarily the plan best suited to 1 parameter = 10,000 rows.)
Earlier quoted context omitted.
Isn't this just a Drupal 7 issue? Still will affect a lot, but I know plenty Drupal installations from that 900k+ figure that are on 5 and 6.
The 900k+ number is from the official statistics and includes only Drupal 7 installations ( https://www.drupal.org/project/usage/drupal ).
Thanks.
Drupal uses prepared statements in all its SQL queries. There's this common misconception "just use prepared statements and they'll completely prevent SQL injection" floating around. Good to see (yet another) counterexample of that. Prepared statements and parameters are only strategies that can help, but they don't replace an understanding of where the characters in the query are coming from and how they're being us…
These aren't prepared statements. This wouldn't be an issue if they were actual RDBMS prepared statements. These are the bullshit fake prepared statements that PDO emulates by default to achieve cross-database compatibility to offer things like named-parameters (oracle, postgresql support) for databases that only offer positional parameters (mysql, mssql). It's quite simply shoddy string substitution that's not doing…
Something between PHP and MSSQL must not support named parameters, because MSSQL supports them just fine.
Drupal like GnuTLS, like openSSL, like joomla, and like a lot of code out there as always been recognized poor quality unreadable code by my own eyes. (Like some parts of the linux kernel) Why don't people see the pattern? Poorly coded software results in security holes. And IN statements are stupid with prepared statement. If you can leverage a «hit or miss» cache effect with a IN statement, you don't need the IN, e…