[kwlug-disc] Drupal core - Highly critical - Remote Code Execution - SA-CORE-2018-002

Federer Fanatic nafdef at gmail.com
Thu Mar 29 12:28:25 EDT 2018


Isn't the point that programmers should know by now that these kinds of
user-based
injections errors have no business being present?




--------------------------------------------------------------
 Roger Federer Fanatic Extraordinaire :-)

On Thu, Mar 29, 2018 at 12:15 PM, Khalid Baheyeldin <kb at 2bits.com> wrote:

> Bob,
>
> Piling on OK. We all learn from discussions like this one.
>
> 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.
>
> 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.
>
> As for full disclosure, this was done already for this SA, though using
> industry acronyms.
>
> The FAQ for the issue expands on what these mean. See the 'How Dangerous'
> section.
>
> https://groups.drupal.org/security/faq-2018-002
>
> It is basically remote code execution that can be done by anyone (no need
> to login), provided they specially craft their request.
>
> So, to exploit this, one has to craft a request that does SQL Injection.
>
> https://en.wikipedia.org/wiki/SQL_injection
>
> This injection is prevented by sanitizing the input, which what the
> patched version does.
>
> Once SQLI is done, one inserts a row in the menu_router table, and that
> fetches a remote script from a remote server.
>
> 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.
>
> 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.
>
> https://github.com/MKorostoff/drupalgeddon
>
> On Mar 28, 2018 22:53, "Bob Jonkman" <bjonkman at sobac.com> wrote:
>
>>
>> Khalid wrote:
>> > The FAQ is intentionally vague to make it hard(er) for exploiters.
>>
>> Not meaning to pile on Khalid, but that hardly seems like "full
>> disclosure" to me.
>>
>> A commercial software vendor whose software I SysAdminned released a
>> patch with the same sort of urgent vagueness: "Really important!"
>> What is it? "Ain't saying!"
>>
>> Their software was fragile, to put it nicely. Used for a
>> mission-critical application, and needed to go through at least some
>> in-house testing before being allowed in production. But we didn't
>> know what the problem was, which modules were affected, the financial
>> risk of not patching, vs. the cost of downtime for patching (and the
>> additional cost of the patch breaking things, resulting in more
>> downtime). After chewing out our software rep (to no avail) we ended
>> up patching, spending a weekend updating some 25 servers (by hand,
>> those servers were all snowflakes) and trying to keep the databases in
>> sync.
>>
>> A few years later I was working somewhere else with someone who said
>> "Oh yeah, I discovered that vulnerability! It was (blah, blah blah)."
>> Of course, the flaw existed in none of the servers we had patched,
>> since we didn't run the affected modules. So, lots of cost and
>> downtime, for no good purpose. And no way to hold that software vendor
>> accountable for lost time and money.
>>
>> - --Bob, who much prefers *real* full disclosure.
>>
>
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20180329/ba0ccc79/attachment.htm>


More information about the kwlug-disc mailing list