<div dir="ltr">Isn't the point that programmers should know by now that these kinds of user-based <div>injections errors have no business being present?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><br><br><br>--------------------------------------------------------------<br> Roger Federer Fanatic Extraordinaire :-)</div></div>
<br><div class="gmail_quote">On Thu, Mar 29, 2018 at 12:15 PM, Khalid Baheyeldin <span dir="ltr"><<a href="mailto:kb@2bits.com" target="_blank">kb@2bits.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="auto">Bob,<br><br>Piling on OK. We all learn from discussions like this one.<br><div dir="auto"><br></div><div dir="auto">My response was to the stance of: 'X has a vulnerability, so I will never use X'. As I pointed out, there are vulnerabilities in many other popular programs, and now even CPUs. If one was to take this stance seriously and consistently, there will be little left that is of use.<br><br></div><div dir="auto">The security team being vague about the specifics of HOW to exploit the vulnerability is to buy sites time to upgrade, not to prevent exploits being developed. They will be developed eventually, it is just a matter of when.<br><br></div><div>As for full disclosure, this was done already for this SA, though using industry acronyms.<br><br>The FAQ for the issue expands on what these mean. See the 'How Dangerous' section.<br><br><a href="https://groups.drupal.org/security/faq-2018-002" target="_blank">https://groups.drupal.org/<wbr>security/faq-2018-002</a><br><br></div><div>It is basically remote code execution that can be done by anyone (no need to login), provided they specially craft their request.<br><br></div><div>So, to exploit this, one has to craft a request that does SQL Injection.<br><br><a href="https://en.wikipedia.org/wiki/SQL_injection" target="_blank">https://en.wikipedia.org/wiki/<wbr>SQL_injection</a><br><br></div><div>This injection is prevented by sanitizing the input, which what the patched version does.<br><br></div>Once SQLI is done, one inserts a row in the menu_router table, and that fetches a remote script from a remote server.<br><br></div><div>A similar technique was used in 2014 to exploit sites that did not patch Drupal 7.x in time for Drupalgeddon. That vulnerability was straight SQL non-sanitization. The one from yesterday is different in that it is more involved.<br><br></div><div>Here is someone who reverse engineered how his site was hacked in 2014. Look at exploit.php to see how this is done. A different starting point is needed now, but once SQLI is achieved it should be the same. <br></div><div><br></div><div dir="auto"><div dir="auto"><a href="https://github.com/MKorostoff/drupalgeddon" target="_blank">https://github.com/MKorostoff/<wbr>drupalgeddon</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mar 28, 2018 22:53, "Bob Jonkman" <<a href="mailto:bjonkman@sobac.com" target="_blank">bjonkman@sobac.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Khalid wrote:<br>
> The FAQ is intentionally vague to make it hard(er) for exploiters.<br>
<br>
Not meaning to pile on Khalid, but that hardly seems like "full<br>
disclosure" to me.<br>
<br>
A commercial software vendor whose software I SysAdminned released a<br>
patch with the same sort of urgent vagueness: "Really important!"<br>
What is it? "Ain't saying!"<br>
<br>
Their software was fragile, to put it nicely. Used for a<br>
mission-critical application, and needed to go through at least some<br>
in-house testing before being allowed in production. But we didn't<br>
know what the problem was, which modules were affected, the financial<br>
risk of not patching, vs. the cost of downtime for patching (and the<br>
additional cost of the patch breaking things, resulting in more<br>
downtime). After chewing out our software rep (to no avail) we ended<br>
up patching, spending a weekend updating some 25 servers (by hand,<br>
those servers were all snowflakes) and trying to keep the databases in<br>
sync.<br>
<br>
A few years later I was working somewhere else with someone who said<br>
"Oh yeah, I discovered that vulnerability! It was (blah, blah blah)."<br>
Of course, the flaw existed in none of the servers we had patched,<br>
since we didn't run the affected modules. So, lots of cost and<br>
downtime, for no good purpose. And no way to hold that software vendor<br>
accountable for lost time and money.<br>
<br>
- --Bob, who much prefers *real* full disclosure.<br>
</blockquote></div></div>
</div>
<br>______________________________<wbr>_________________<br>
kwlug-disc mailing list<br>
<a href="mailto:kwlug-disc@kwlug.org">kwlug-disc@kwlug.org</a><br>
<a href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org" rel="noreferrer" target="_blank">http://kwlug.org/mailman/<wbr>listinfo/kwlug-disc_kwlug.org</a><br>
<br></blockquote></div><br></div>