September 2019 - Security-news

Gutenberg - Critical - Access bypass - SA-CONTRIB-2019-069
by security-news＠drupal.org 25 Sep '19

25 Sep '19

View online: https://www.drupal.org/sa-contrib-2019-069 Project: Gutenberg [1] Date: 2019-September-25 Security risk: *Critical* 16∕25 AC:Basic/A:None/CI:Some/II:Some/E:Theoretical/TD:All [2] Vulnerability: Access bypass Description: This module provides a new UI experience for node editing - Gutenberg editor. The routes used by the Gutenberg editor lack proper permissions allowing untrusted users to view and modify some content they should not be able to view or modify. Solution: Install the latest version: * If you use the Gutenberg module 8.x-1.x, upgrade to 8.x-1.8 [3] * For roles other than administrator, the Administer Gutenberg permission must be given to handle media files on the Gutenberg editor. Also see the Gutenberg [4] project page. Reported By: * Marco Fernandes [5] * Greg Knaddison [6] of the Drupal Security Team Fixed By: * Marco Fernandes [7] * Thor Andre Gretland [8] * Mariusz Andrzejewski [9] Coordinated By: * Greg Knaddison [10] of the Drupal Security Team [1] https://www.drupal.org/project/gutenberg [2] https://www.drupal.org/security-team/risk-levels [3] https://www.drupal.org/project/gutenberg/releases/8.x-1.8 [4] https://www.drupal.org/project/gutenberg [5] https://www.drupal.org/user/2127558 [6] https://www.drupal.org/user/36762 [7] https://www.drupal.org/user/2127558 [8] https://www.drupal.org/user/223878 [9] https://www.drupal.org/user/3517832 [10] https://www.drupal.org/user/36762

1 0

Permissions by Term - Moderately critical - Access bypass - SA-CONTRIB-2019-068
by security-news＠drupal.org 25 Sep '19

25 Sep '19

View online: https://www.drupal.org/sa-contrib-2019-068 Project: Permissions by Term [1] Version: 8.x-1.x-dev Date: 2019-September-25 Security risk: *Moderately critical* 14∕25 AC:None/A:None/CI:Some/II:None/E:Theoretical/TD:Default [2] Vulnerability: Access bypass Description: This module enables you to control access to content based on taxonomy terms. The module doesn't sufficiently check if a given entity should be access controlled, defaulting to allowing access even to unpublished nodes. The vulnerability is mitigated by the fact that the submodule Permissions by Entity must also be enabled. Solution: Install the latest version: * If you use the Permissions by Term module for Drupal 8.x, upgrade to Permissions by Term 8.x-2.11 [3] Also see the Permissions by Term [4] project page. Reported By: * Jimmy Henderickx [5] Fixed By: * Marc-Oliver Teschke [6] Coordinated By: * Heine [7] of the Drupal Security Team * Ivo Van Geertruyen [8] of the Drupal Security Team [1] https://www.drupal.org/project/permissions_by_term [2] https://www.drupal.org/security-team/risk-levels [3] https://drupal.org/project/permissions_by_term/releases/8.x-2.11 [4] https://www.drupal.org/project/permissions_by_term [5] https://www.drupal.org/user/462700 [6] https://www.drupal.org/user/1529744 [7] https://www.drupal.org/u/heine [8] https://www.drupal.org/u/mrbaileys

1 0

Create user permission - Critical - Access bypass - SA-CONTRIB-2019-066
by security-news＠drupal.org 18 Sep '19

18 Sep '19

View online: https://www.drupal.org/sa-contrib-2019-066 Project: Create user permission [1] Version: 8.x-1.x-dev Date: 2019-September-18 Security risk: *Critical* 15∕25 AC:Basic/A:None/CI:Some/II:Some/E:Theoretical/TD:Default [2] Vulnerability: Access bypass Description: This module enables you to have a separate permission only for creating users. The module doesn't respect Drupal's setting for "Who can register accounts?" when set to "Visitors, but administrator approval is required". When this option is chosen, the module overrides the setting, and makes it possible to register accounts with no approval. This vulnerability can be mitigated by having other settings in place for account registration, such as requiring email verification for new accounts, or permitting account creation for "Administrators only". Solution: Install the latest version: * If you use the create_user_permission module for Drupal 8.x, upgrade to Create user permission 8.x-1.2 [3] Also see the Create user permission [4] project page. Reported By: * jddh [5] Fixed By: * Eirik Morland [6] Coordinated By: * Michael Hess [7] of the Drupal Security Team * Greg Knaddison [8] of the Drupal Security Team * Drew Webber [9] of the Drupal Security Team [1] https://www.drupal.org/project/create_user_permission [2] https://www.drupal.org/security-team/risk-levels [3] https://www.drupal.org/project/create_user_permission/releases/8.x-1.2 [4] https://www.drupal.org/project/create_user_permission [5] https://www.drupal.org/user/509004 [6] https://www.drupal.org/user/1014468 [7] https://www.drupal.org/user/102818 [8] https://www.drupal.org/user/36762 [9] https://www.drupal.org/user/255969

1 0

TableField - Moderately critical - Access bypass - SA-CONTRIB-2019-067
by security-news＠drupal.org 18 Sep '19

18 Sep '19

View online: https://www.drupal.org/sa-contrib-2019-067 Project: TableField [1] Version: 8.x-2.x-dev Date: 2019-September-18 Security risk: *Moderately critical* 12∕25 AC:None/A:User/CI:Some/II:None/E:Theoretical/TD:Default [2] Vulnerability: Access bypass Description: This module allows you to attach tabular data to an entity. There is insufficient access checking for users with the ability to "Export Tablefield Data as CSV". They can export data from unpublished nodes or otherwise inaccessible entities. This vulnerability is mitigated by the fact that an attacker must have a role with the permission "Export Tablefield Data as CSV". Solution: Install the latest version: * If you use the Tablefield module for Drupal 8.x, upgrade to Tablefield 8.x-2.1 [3] Also see the TableField [4] project page. Reported By: * Mitch Portier [5] Fixed By: * Mitch Portier [6] * Jen Lampton [7] * Martin Postma [8] Coordinated By: * Chris McCafferty [9] of the Drupal Security Team * Greg Knaddison [10] of the Drupal Security Team * Drew Webber [11] of the Drupal Security Team [1] https://www.drupal.org/project/tablefield [2] https://www.drupal.org/security-team/risk-levels [3] https://www.drupal.org/project/tablefield/releases/8.x-2.1 [4] https://www.drupal.org/project/tablefield [5] https://www.drupal.org/user/2284182 [6] https://www.drupal.org/user/2284182 [7] https://www.drupal.org/user/85586 [8] https://www.drupal.org/user/210402 [9] https://www.drupal.org/user/1850070 [10] https://www.drupal.org/user/36762 [11] https://www.drupal.org/user/255969

1 0

Various 3rd Party Vulnerabilities - PSA-2019-09-04
by security-news＠drupal.org 04 Sep '19

04 Sep '19

View online: https://www.drupal.org/psa-2019-09-04 Date: 2019-September-04 Vulnerability: Various 3rd Party Vulnerabilities Description: In June of 2011, the Drupal Security Team issued Public Service Advisory PSA-2011-002 - External libraries and plugins [1]. 8 years later that is still the policy of the Drupal Security team. As Drupal core and modules leverage 3rd party code more and more it seems like an important time to remind site owners that they are responsible for monitoring security of 3rd party libraries. Here is the advice from 2011 which is even more relevant today: >Just like there's a need to diligently follow announcements and update >contributed modules downloaded from Drupal.org, there's also a need to >follow announcements by vendors of third-party libraries or plugins that are >required by such modules. > >Drupal's update module has no functionality to alert you to these >announcements. The Drupal security team will not release announcements about >security issues in external libraries and plugins. > -------- CURRENT PHPUNIT/MAILCHIMP LIBRARY EXPLOIT --------------------------- Recently we have become aware of a vulnerability that is being actively exploited on some Drupal sites. The vulnerability is in PHPUnit and has a CVE# CVE-2017-9841. The exploit targets Drupal sites that currently or previously used the Mailchimp or Mailchimp commerce module and still have a vulnerable version of the file sites/all/libraries/mailchimp/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php. See below for details on whether a file is vulnerable or not. The vulnerable file might be at other paths on your individual site, but an automated attack exists that is looking for that specific path. This attack can execute PHP on the server. Solution: Follow release announcements by the vendors of the external libraries and plugins you use. In this specific case, check for the existence of a file named eval-stdin.php and check its contents. If they match the new version in this commit [2] then it is safe. If the file reads from php://input then the codebase is vulnerable. This is not an indication of a site being compromised, just of it being vulnerable. To fix this vulnerability, update your libraries. In particular you should ensure the Mailchimp [3] and Mailchimp Ecommerce [4] modules *and their libraries* are updated. If you discover your site has been compromised, we have a guide of how to remediate a compromised site [5]. Also see the Drupal core [6] project page. Reported By: * Hans Rossel [7] Coordinated By: * Greg Knaddison [8] of the Drupal Security Team [1] https://www.drupal.org/node/1189632 [2] https://github.com/sebastianbergmann/phpunit/commit/284a69fb88a2d0845d23f42… [3] https://www.drupal.org/project/mailchimp/ [4] https://www.drupal.org/project/mailchimp_ecommerce/ [5] https://www.drupal.org/docs/develop/security/your-drupal-site-got-hacked-no… [6] https://www.drupal.org/project/drupal [7] https://www.drupal.org/u/hansrossel [8] https://www.drupal.org/user/36762

1 0