Affected Versions: < 3.4.3, < 3.3.14
Patched Versions: 3.4.3+, 3.3.14+
YAML deserialization can run untrusted code
An authorized user can upload a zip-format plugin with a crafted plugin.yaml, or a crafted aclpolicy yaml file, or upload an untrusted project archive with a crafted aclpolicy YAML file, that can cause the server to run untrusted code on Rundeck Community or Enterprise Edition. An authenticated user can make a POST request, that can cause the server to run untrusted code on Process Automation Edition.
The zip-format plugin issues requires authentication and authorization to these access levels, and affects all Rundeck editions:
adminlevel access to the
The ACL Policy yaml file upload issues requires authentication and authorization to these access levels, and affects all Rundeck editions:
adminlevel access to a
adminlevel access to the
The unauthorized POST request requires authentication, but no specific authorization, and affects Process Automation only.
Versions 3.4.3, 3.3.14
In general, be sure to review the contents of all zip plugins, project archives, or ACL Policy files that are loaded into the Rundeck server. When loading Project Archives, select the "Do Not Import ACL Policies" option if the contents are not trusted.
Review the access levels granted via ACL Policy files, and whether any of the above access levels are granted.
You can temporarily deny the access levels vulnerable to these issues. This has the effect of also disabling other admin level actions to the application, but will mitigate the issues.
Mitigate zip-plugin issue
The simplest way to prevent the zip-file upload issue is to make the
$RDECK_BASE/var/tmp/pluginUpload directory non-writable. This will cause any plugin uploads to fail before being processed.
Alternately, you can add an ACL Policy file to deny
admin access to all users:
description: Deny system admin access to all users to mitigate zip plugin vulnerability context: application: 'rundeck' for: resource: - equals: kind: 'system' deny: 'admin' by: group: '.*'
Applicable to Community and Enterprise editions.
Mitigate aclpolicy yaml issue
Note: there is no workaround for this issue, as it does not require authorization (only authentication).
Disable the ability to updated/modify Project ACL Policies, by adding the following ACL Policy at the system level to deny
admin to all project_acl resources for all users:
by: group: .* description: Deny [create, update, admin] for project_acl to all users for: project_acl: - deny: - create - update - admin context: application: rundeck
To completely mitigate the
system_acl vulnerability, the
update can be denied by adding a new acl policy. However, be aware that adding a policy that does this has some consequences:
- If added via the GUI/API, but with
deleteaccess still allowed, a user with
deleteaccess could delete the mitigation policy
deleteaccess is also denied in a policy added via GUI/API, then it will completely disable the ability to update or create System ACL Policy files by all users, including admin level users.
The most straightforward way to add the mitigation policy is to put the mitigation ACL policies as files into the
$RDECK_BASE/etc directory of the Rundeck server, where it can later be removed manually. Otherwise, you may be completely locked out of being able to modify ACL Policy files. As an additional safeguard, remove the text
I_UNDERSTAND_AND_WANT_TO_DO_THIS when installing.
by: group: I_UNDERSTAND_AND_WANT_TO_DO_THIS.* description: "DANGER: mitigation to Deny [create, update, admin, delete] for system_acl for all users" for: resource: - deny: - create - update - admin - delete equals: kind: system_acl context: application: rundeck
Authenticated POST issue
There is no workaround at this time. Ensure only trusted users can authenticate to Process Automation.
For more information
If you have any questions or comments about this advisory:
- Email us at firstname.lastname@example.org
To report security issues to Rundeck please use the form at https://rundeck.com/security
Reporter: Rojan Rijal from Tinder Red Team