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

[Khalid Baheyeldin]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20180329/38c0525f/attachment.htm>