Recently, Drupal released a security advisory on the remediation of an access bypass vulnerability (CVE-2019-6342). In Drupal 8.7.4, when the experimental Workspaces module is enabled, an access bypass condition is created. In terms of the security risk, Drupal rates the vulnerability as Critical.<\/p>\n
Reference:<\/p>\n
https:\/\/www.drupal.org\/sa-core-2019-008<\/p>\n
2 Scope of Impact<\/strong><\/h2>\n\n- Affected Versions<\/li>\n
- Drupal 8.7.4\n
\n- Unaffected Versions<\/li>\n<\/ul>\n<\/li>\n
- Drupal 8.7.5<\/li>\n
- Drupal < 8.7.4<\/li>\n
- Drupal 8.6.x<\/li>\n<\/ul>\n
3 Vulnerability Detection<\/strong><\/h2>\nDrupal users can check whether they are affected by this vulnerability by logging in to the background and choosing Manage > Reports > Status report<\/strong> to view the version of the current application. If the version is 8.7.4, they are at risk.<\/p>\n![\"Red](\"https:\/\/nsfocusglobal.com\/wp-content\/uploads\/2019\/08\/0805-1.jpg\")
<\/a>
\n<\/strong><\/p>\n4 Mitigation<\/strong><\/h2>\n4.1 Official Fix<\/strong><\/h3>\nDrupal has released a new version to fix this vulnerability. Affected users can visit the following link to download this version and upload their installation:<\/p>\n
https:\/\/www.drupal.org\/project\/drupal\/releases\/8.7.5<\/p>\n
5 Technical Analysis<\/strong><\/h2>\n5.1 Vulnerability Reproduction<\/strong><\/h3>\nInstall Drupal 8.7.4, log in as admin<\/strong>, access \/admin\/modules<\/strong>, select Workspaces<\/strong>, and click Install<\/strong>.<\/p>\n![\"Red](\"https:\/\/nsfocusglobal.com\/wp-content\/uploads\/2019\/08\/0805-2.jpg\")
<\/a><\/p>\nIf a message shown in the following page appears in the upper right corner, the installation succeeds. You can switch between the Stage and Live mode.<\/p>\n
![\"Red](\"https:\/\/nsfocusglobal.com\/wp-content\/uploads\/2019\/08\/0805-3.jpg\")
<\/a><\/p>\nUse another browser to open the homepage of Drupal without logging in, and access http:\/\/127.0.0.1\/drupal-8.7.4\/node\/add\/article<\/a>. On this page, you can directly add arbitrary articles without being required to have the author or administrator privileges.<\/p>\n![\"Red](\"https:\/\/nsfocusglobal.com\/wp-content\/uploads\/2019\/08\/0805-4.jpg\")
<\/a><\/p>\n5.2 Vulnerability Analysis<\/strong><\/h3>\nWorkspaces is a new experimental module built into the Drupal 8.6 core. It allows website administrators to review and edit the content and then publish unlimited amounts of it all at once.<\/p>\n
Workspaces can work in Stage or Live mode, with Live as the default one. The differences between the two modes are as follows:<\/p>\n
\n- When Workspaces is in Stage mode, the edited content is not immediately updated. After all articles are edited, the administrator can publish them to the live environment by clicking Deploy to Live<\/strong>. That is to say, the Stage workspace is equivalent to a temporary depot.<\/li>\n<\/ul>\n
![\"Red](\"https:\/\/nsfocusglobal.com\/wp-content\/uploads\/2019\/08\/0805-5.jpg\")
<\/a><\/p>\n\n- The Live workspace is characterized by instant updates. That is to say, when an article is edited, the website content is immediately updated.<\/li>\n<\/ul>\n
In either mode, there is a bug caused by incorrect coding: An anonymous user can create, publish, edit, and delete articles without login. The vulnerability stems from the authentication module EntityAccess.<\/p>\n
When a user initiates a request, the system calls back the privilege check module to check the current user’s permissions. Specifically, in the RouterListener method of EventListener, the onKernelRequest() method calls the matchRequest() method of the AccessAwareRouter class, and then calls the checkRequest() method of the AccessManager class. Finally, in the performCheck() method of the AccessManager class, the call_user_func_array function calls back the corresponding operation for a specific permission check.<\/p>\n
![\"Red](\"https:\/\/nsfocusglobal.com\/wp-content\/uploads\/2019\/08\/0805-6.jpg\")
<\/a><\/p>\nFor example, access_check.node.add is called back when an article is published. The related method is defined in the NodeAccessControlHandler controller, which is inherited from EntityAccessControlHandler. In the createAccess() method of the parent class, the create_access permission for the corresponding operation is called back. In this process, the module name and related hook are spliced to constitute a callback function.<\/p>\n
$function = $module . ‘_’ . $hook<\/em><\/p>\nHere the workspaces_entity_create_access() method is called back to enter Workspaces.<\/p>\n
![\"Red](\"https:\/\/nsfocusglobal.com\/wp-content\/uploads\/2019\/08\/0805-7.jpg\")
<\/a><\/p>\nWhen the entityCreateAccess() method is called, there exists a key operation, bypassAccessResult.<\/p>\n
![\"Red](\"https:\/\/nsfocusglobal.com\/wp-content\/uploads\/2019\/08\/0805-8.jpg\")
<\/a><\/p>\nThe bypassAccessResult() method checks whether the current user has the “bypass node access” and is specific to Workspaces. This method determines that “if a user is in his\/her own active workspace, he\/she has a full permission”. “Full permission” here refers to addition, deletion, and edit operations on articles.<\/p>\n
This looks odd, but is actually a designed function. Normally, whether a user owns a full permission is configured in admin\/people\/permissions in the background. By default, anonymous and non-administrative authenticated users do not have such permission.<\/p>\n
![\"Red](\"https:\/\/nsfocusglobal.com\/wp-content\/uploads\/2019\/08\/0805-9.jpg\")
<\/a><\/p>\nOnly when “Bypass content entity access in own workspace” is enabled, can users publish and delete articles without logging in. The vulnerability in question bypasses this configuration, allowing privilege escalation by default.<\/p>\n
Let’s look further into how bypassAccessResult() is implemented. In the process, the AccessResultAllowed object or AccessResultNeutral object is returned. “Neutral” means that the result may need to be further determined subsequently. However, as far as this vulnerability is concerned, the result is just “access” or “forbidden”.<\/p>\n
![\"Red](\"https:\/\/nsfocusglobal.com\/wp-content\/uploads\/2019\/08\/0805-10.jpg\")
<\/a><\/p>\nThe method first obtains the current active workspace, then determines via allowedIf whether the current user has the permission, and finally saves this data to the cache, including the cached content, cache label, and expiration time. Subsequently, the method determines whether to create an allowed access result depending on whether the permission is present via allowedIfHasPermission. If the permission is not present, the user is not allowed access and a reason is provided. This mechanism works well by far. When no workspace permission is configured for anonymous users in the background, the AccessResultNeutral object is returned, indicating “forbidden”. Now comes the vulnerable part.<\/p>\n
$owner_has_access->orIf($access_bypass);<\/em><\/p>\nBy checking the patch, we find that, in the preceding statement, orIf is changed to andIf.<\/p>\n
![\"Red](\"https:\/\/nsfocusglobal.com\/wp-content\/uploads\/2019\/08\/0805-11.jpg\")
<\/a><\/p>\nThe design logic of the two methods is rather complicated. Their most important function is to make a judgment on the “Neutral” result. In the case of orIf, whether to allow access is up to the caller’s decision. In the case of andIf, access is directly prohibited.<\/p>\n
As far as this vulnerability is concerned, the difference is shown in the following figures.<\/p>\n
\n- orIf()<\/li>\n<\/ul>\n
![\"Red](\"https:\/\/nsfocusglobal.com\/wp-content\/uploads\/2019\/08\/0805-12.jpg\")
<\/a><\/p>\nThe AccessResultAllowed object is returned.<\/p>\n
![\"Red](\"https:\/\/nsfocusglobal.com\/wp-content\/uploads\/2019\/08\/0805-13.jpg\")
<\/p>\n
\n- andIf()<\/li>\n<\/ul>\n
![\"Red](\"https:\/\/nsfocusglobal.com\/wp-content\/uploads\/2019\/08\/0805-14.jpg\")
<\/a><\/p>\nThe AccessResultNeutral object is returned.<\/p>\n
![\"Red](\"https:\/\/nsfocusglobal.com\/wp-content\/uploads\/2019\/08\/0805-15.jpg\")
<\/a><\/p>\nAfter the check is complete, we come back to the checkAccess() method of the AccessAwareRouter class. This method checks the returned result and so isAllowed() of AccessResultNeutral throws an exception.<\/p>\n
![\"Red](\"https:\/\/nsfocusglobal.com\/wp-content\/uploads\/2019\/08\/0805-16.jpg\")
<\/a><\/p>\nOn the page, a 403 Forbidden error is displayed, indicating access denied.<\/p>\n
- \n
- Unaffected Versions<\/li>\n<\/ul>\n<\/li>\n
- Drupal 8.7.5<\/li>\n
- Drupal < 8.7.4<\/li>\n
- Drupal 8.6.x<\/li>\n<\/ul>\n
3 Vulnerability Detection<\/strong><\/h2>\n
Drupal users can check whether they are affected by this vulnerability by logging in to the background and choosing Manage > Reports > Status report<\/strong> to view the version of the current application. If the version is 8.7.4, they are at risk.<\/p>\n
<\/a>
\n<\/strong><\/p>\n4 Mitigation<\/strong><\/h2>\n
4.1 Official Fix<\/strong><\/h3>\n
Drupal has released a new version to fix this vulnerability. Affected users can visit the following link to download this version and upload their installation:<\/p>\n
https:\/\/www.drupal.org\/project\/drupal\/releases\/8.7.5<\/p>\n
5 Technical Analysis<\/strong><\/h2>\n
5.1 Vulnerability Reproduction<\/strong><\/h3>\n
Install Drupal 8.7.4, log in as admin<\/strong>, access \/admin\/modules<\/strong>, select Workspaces<\/strong>, and click Install<\/strong>.<\/p>\n
<\/a><\/p>\nIf a message shown in the following page appears in the upper right corner, the installation succeeds. You can switch between the Stage and Live mode.<\/p>\n
<\/a><\/p>\nUse another browser to open the homepage of Drupal without logging in, and access http:\/\/127.0.0.1\/drupal-8.7.4\/node\/add\/article<\/a>. On this page, you can directly add arbitrary articles without being required to have the author or administrator privileges.<\/p>\n
<\/a><\/p>\n5.2 Vulnerability Analysis<\/strong><\/h3>\n
Workspaces is a new experimental module built into the Drupal 8.6 core. It allows website administrators to review and edit the content and then publish unlimited amounts of it all at once.<\/p>\n
Workspaces can work in Stage or Live mode, with Live as the default one. The differences between the two modes are as follows:<\/p>\n
- \n
- When Workspaces is in Stage mode, the edited content is not immediately updated. After all articles are edited, the administrator can publish them to the live environment by clicking Deploy to Live<\/strong>. That is to say, the Stage workspace is equivalent to a temporary depot.<\/li>\n<\/ul>\n<\/a><\/p>\n
- \n
- The Live workspace is characterized by instant updates. That is to say, when an article is edited, the website content is immediately updated.<\/li>\n<\/ul>\n
In either mode, there is a bug caused by incorrect coding: An anonymous user can create, publish, edit, and delete articles without login. The vulnerability stems from the authentication module EntityAccess.<\/p>\n
When a user initiates a request, the system calls back the privilege check module to check the current user’s permissions. Specifically, in the RouterListener method of EventListener, the onKernelRequest() method calls the matchRequest() method of the AccessAwareRouter class, and then calls the checkRequest() method of the AccessManager class. Finally, in the performCheck() method of the AccessManager class, the call_user_func_array function calls back the corresponding operation for a specific permission check.<\/p>\n
<\/a><\/p>\nFor example, access_check.node.add is called back when an article is published. The related method is defined in the NodeAccessControlHandler controller, which is inherited from EntityAccessControlHandler. In the createAccess() method of the parent class, the create_access permission for the corresponding operation is called back. In this process, the module name and related hook are spliced to constitute a callback function.<\/p>\n
$function = $module . ‘_’ . $hook<\/em><\/p>\n
Here the workspaces_entity_create_access() method is called back to enter Workspaces.<\/p>\n
<\/a><\/p>\nWhen the entityCreateAccess() method is called, there exists a key operation, bypassAccessResult.<\/p>\n
<\/a><\/p>\nThe bypassAccessResult() method checks whether the current user has the “bypass node access” and is specific to Workspaces. This method determines that “if a user is in his\/her own active workspace, he\/she has a full permission”. “Full permission” here refers to addition, deletion, and edit operations on articles.<\/p>\n
This looks odd, but is actually a designed function. Normally, whether a user owns a full permission is configured in admin\/people\/permissions in the background. By default, anonymous and non-administrative authenticated users do not have such permission.<\/p>\n
<\/a><\/p>\nOnly when “Bypass content entity access in own workspace” is enabled, can users publish and delete articles without logging in. The vulnerability in question bypasses this configuration, allowing privilege escalation by default.<\/p>\n
Let’s look further into how bypassAccessResult() is implemented. In the process, the AccessResultAllowed object or AccessResultNeutral object is returned. “Neutral” means that the result may need to be further determined subsequently. However, as far as this vulnerability is concerned, the result is just “access” or “forbidden”.<\/p>\n
<\/a><\/p>\nThe method first obtains the current active workspace, then determines via allowedIf whether the current user has the permission, and finally saves this data to the cache, including the cached content, cache label, and expiration time. Subsequently, the method determines whether to create an allowed access result depending on whether the permission is present via allowedIfHasPermission. If the permission is not present, the user is not allowed access and a reason is provided. This mechanism works well by far. When no workspace permission is configured for anonymous users in the background, the AccessResultNeutral object is returned, indicating “forbidden”. Now comes the vulnerable part.<\/p>\n
$owner_has_access->orIf($access_bypass);<\/em><\/p>\n
By checking the patch, we find that, in the preceding statement, orIf is changed to andIf.<\/p>\n
<\/a><\/p>\nThe design logic of the two methods is rather complicated. Their most important function is to make a judgment on the “Neutral” result. In the case of orIf, whether to allow access is up to the caller’s decision. In the case of andIf, access is directly prohibited.<\/p>\n
As far as this vulnerability is concerned, the difference is shown in the following figures.<\/p>\n
- \n
- orIf()<\/li>\n<\/ul>\n<\/a><\/p>\n
The AccessResultAllowed object is returned.<\/p>\n
<\/p>\n- \n
- andIf()<\/li>\n<\/ul>\n<\/a><\/p>\n
The AccessResultNeutral object is returned.<\/p>\n
<\/a><\/p>\nAfter the check is complete, we come back to the checkAccess() method of the AccessAwareRouter class. This method checks the returned result and so isAllowed() of AccessResultNeutral throws an exception.<\/p>\n
<\/a><\/p>\nOn the page, a 403 Forbidden error is displayed, indicating access denied.<\/p>\n
- andIf()<\/li>\n<\/ul>\n
- orIf()<\/li>\n<\/ul>\n
- The Live workspace is characterized by instant updates. That is to say, when an article is edited, the website content is immediately updated.<\/li>\n<\/ul>\n
- When Workspaces is in Stage mode, the edited content is not immediately updated. After all articles are edited, the administrator can publish them to the live environment by clicking Deploy to Live<\/strong>. That is to say, the Stage workspace is equivalent to a temporary depot.<\/li>\n<\/ul>\n