I'm sure we'll start seeing exploit attempts soon - and we will be actively monitoring logs (looking for interesting query string patterns) to see what we find. So we'll keep our suspicions of where the issue lies to ourselves for the time being. Drupal releases use the semantic versioning scheme to indicate whether a release is a major, minor or patch release. The composer lockfile and core metapackages change with every release, and security releases are created directly off the last release tag (rather than HEAD). Because for now, it's probably most helpful for the Drupal community to avoid helping the bad guys zero in on the exploit details until we've allowed time for the majority of people to sort out their sites. Last updated FebruSite Administration Now in Drupal, core development has successfully transitioned to a regular release cycle. The instructions below assume the previous patch release of 9.0.x was 9.0.8, and so a security release will be created as 9.0.9. The patch is definitely more of a workaround (removing the offending keys) rather than actually changing the code that is causing those keys to be a security issue, which right now makes it difficult to see where the actual exploit lies. Obviously, there is nothing intrinsically insecure about a query string key starting with a '#', so there must be something more fundamental going on. So, the issue must be something pretty deep in Drupal. The contents of request-sanitizer.inc boil down to simply stripping all query string keys that start with a '#'. That made for a generally quick and easy update (always a blessing when updating multiple sites at 8pm!). The patch itself is pretty straightforward for Drupal 7 there's a new include file "request-sanitizer.inc" which is called into action early in the Drupal bootstrap. The good news, it was a relatively easy fix, some manic patching later and all our clients are safe. What privilege level is required for an exploit to be successful? None (all/anonymous users).ĭoes this vulnerability cause non-public data to be accessible? All non-public data is accessible.Ĭan this exploit allow system data (or data handled by the system) to be compromised? All data can be modified or deleted. How difficult is it for the attacker to leverage the vulnerability? None (user visits page). Whatever we call it, it's here and it is every bit as scary as everyone had feared - the key lines from the update : No one seems quite sure what to call SA-CORE-2018-002, although there does seem to be a trend towards drupalgeddon2.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |