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

[Khalid Baheyeldin]

I should also mention that just like the 2014 Drupalgeddon, this
vulnerability was not discovered as an active exploit in the wild. Both
were discovered by a security researcher, probably using scanning or
fuzzing tools. They both became active exploits AFTER being fixed and
disclosed.

Here is an interesting statistic: Drupal 6.x was released in 2008, and the
fix applies to that 10 year old release! So the theoretical vulnerability
was there all along, and never exploited until discovered and fix released.

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.
>>
>


-- 
Khalid M. Baheyeldin
2bits.com, Inc.
Fast Reliable Drupal
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra
Simplicity is the ultimate sophistication. -- anonymous
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20180329/24da47cb/attachment.htm>