The input sanitation vulnerability, an oversight that allows for arbitrary code execution, was patched on Wednesday by Drupal developers.
Building a slide deck, pitch, or presentation? Here are the big takeaways:
- An oversight that led to inputs not being sanitized was patched on Wednesday by Drupal.
- The vulnerability is extremely trivial to exploit, making patching active installations critical.
A failure to sanitize inputs prompted a round of emergency patching for Drupal on Wednesday. The patch was announced a week in advance to give administrators time to prepare due to concerns that exploits "might be developed within hours or days" of the release of the patch.
The vulnerability relates to a conflict between how PHP handles arrays in parameters, and Drupal's use of the hash (#) at the beginning of array keys to signify special keys that typically result in further computation, leading to the ability to inject code arbitrarily, according to Drupal's security advisory. Exploiting this vulnerability does not require any authentication, only visiting a page with a maliciously-crafted URL is necessary.
SEE: System update policy (Tech Pro Research)
As a result, the patch does nothing more than add a sanitation check to /includes/bootstrap.inc in the Drupal installation. Patches were supplied for the 8.5.x and 7.x branches, as well as the otherwise unsupported 8.4.x, 8.3.x, and 6.x branches of the software, the advisory said. According to Drupal's usage statistics page, the software powers about 1.1 million websites.
While there is no known exploit in the wild when the patch was released, according to Drupal, the vulnerability was given a severity score of 21 out of 25. It was originally discovered by Druid researcher Jasper Mattsson, and is assigned the ID CVE-2018-7600 by MITRE, SA-CORE-2018-002 by Drupal, and "Drupalgeddon 2: Electric Hashaloo" by noted programmer Scott Arciszewski, among other members of the Drupal community.
The importance of software updates
In the case of Drupal, the original "Drupalgeddon" vulnerability from 2014 has been viewed as a significant part of how the "Panama Papers" documents relating to the now-defunct law firm Mossack Fonseca were exfiltrated from the organization. The Panama Papers was a release of 11.5 million documents—totaling 2.6 terabytes of data—detailing attorney-client information for over 200,000 offshore entities, some of which were established as tax avoidance schemes.
The client portal operated by Mossack Fonseca was found to be using Drupal 7.23, released in August 2013, when the story broke in April 2016. Drupal was running on Oracle's fork of Apache 2.2.15, from March 6, 2010. The default settings in Oracle Apache web server allow viewing the directory structure. As Drupal files use the .module file extension, which is not executed by default in Apache, any user is able to view the source of the module files as plain text, as well as view the directory in which module files are placed. This led to the discovery of the "portfolio" module which was seemingly intended to allow clients to view their files.
- 10 signs that you aren't cut out to be a telecommuter (free PDF) (TechRepublic)
- AVCrypt ransomware attempts to eradicate your antivirus (ZDNet)
- Chaos Engineering: A cheat sheet (TechRepublic)
- Most IT pros fear IoT cyber attacks. Few are doing anything about it. (ZDNet)
- Total Meltdown: How Microsoft's Meltdown patch created an even bigger flaw for hackers (TechRepublic)