Mitigating the Symlinks Vulnerability

When Apache or nginx serve static files, they follow symbolic links even if a link points to a file owned by another system user (for example, one corresponding to a different subscription). This allows an attacker with access to a subscription to read files from another subscription, including files containing passwords and settings for WordPress and other CMSes.

Mitigating the vulnerability

File system permissions

If you are using WP Toolkit, the easiest way to mitigate the vulnerability for your WordPress instances is to use the Toolkit:

1. Go to WP Toolkit.
2. Select all WordPress instances and click Check Security.
3. Verify that “Permissions for files and directories” is marked as OK.
4. If it is not, click Secure.

If you are not using WP Toolkit or if you need to secure some CMS other than WordPress, you need to manually correct the permissions on all files you want to protect by denying all permissions to the “Other” group by running the following command:

chmod o-rwx <file_name>

Note

There is no “one size fits all” list of files to be secured in this way that fits any web application or CMS. The exact files that must have their permissions changed to secure a web application depend on the application in question.

Apache configuration

This way of mitigating the vulnerability is suitable for subscriptions that use Apache as their web server (a subscription uses Apache if “Proxy mode” is on in Hosting & DNS > Apache & nginx settings).

Note

In Plesk Obsidian 18.0.30 and later, this solution is applied by default. On earlier Plesk versions, follow the instructions below to mitigate the vulnerability.

To mitigate the vulnerability, do the following:

1. Go to Service Plans > your plan > the “Web Server” tab (or your subscription > Websites & Domains > Hosting & DNS > Apache & nginx Settings).
2. Select the “Restrict the ability to follow symbolic links” checkbox.

Doing this for a service plan mitigates the vulnerability for all subscriptions based on that service plan (that is, an attacker gaining access to a subscription will not be able to carry out attacks against other subscriptions). Doing this for a subscription mitigates the vulnerability for that subscription only.

Note

A website that uses symlinks to its own files will keep working if it does not use the “FollowSymLinks” option in the .htaccess file, because the “SymLinksIfOwnerMatch” option is enabled by default. If such a site uses the “FollowSymLinks” option in the .htaccess file, it will stop working.

Caution

Applying this solution will still leave you vulnerable to a “time-of-check to time-of-use” race condition related to the Apache’s “SymLinksIfOwnerMatch” option. To mitigate that vulnerability as well, you can apply this patch to Apache (the patch has not been tested by Plesk, apply at your own risk) or to use one of the kernel based symlink protection options described further in this article.

Nginx configuration

This way of mitigating the vulnerability is suitable for subscriptions that use nginx for serving static files directly (a subscription uses nginx if either “Proxy mode” is off or “Proxy mode” is on and “Serve static files directly by nginx” is on in Hosting & DNS > Apache & nginx settings).

To mitigate the vulnerability, do the following:

1. Go to Service Plans > your plan > Web Server (or your subscription > Websites & Domains > Hosting & DNS > Apache & nginx Settings).
2. Select the “Restrict the ability to follow symbolic links” checkbox.

Doing this for a service plan mitigates the vulnerability for all subscriptions based on that service plan (that is, an attacker gaining access to a subscription will not be able to carry out attacks against other subscriptions). Doing this for a subscription mitigates the vulnerability for that subscription only.

Note

This option is not applicable to computers running Linux kernel version 2.6.39 or earlier. To mitigate the vulnerability on such machines, we recommend that you either upgrade the operating system to the latest stable version or use one of the kernel based symlink protection mechanisms listed below.

SecureLinks in mod_hostinglimits for CloudLinux

On computers running CloudLinux, you can mitigate the vulnerability by enabling the symlink owner match protection mechanism available as part of the HostingLimits module for Apache. Refer to the CloudLinux documentation for more information.

KernelCare Symlink Protection patchset for CentOS 7 (available for free)

On computers running CentOS 7, you can mitigate the vulnerability by installing the free Symlink Protection Patchset available from CloudLinux. Refer to the CloudLinux documentation for more information.

Grsecurity (a set of patches for the Linux kernel emphasizing security enhancements, paid subscription required)

If none of the above options for mitigating the vulnerability are applicable to your situation, you can install the grsecurity set of security-hardening patches for the Linux kernel and then configure the GRKERNSEC_SYMLINKOWN feature. Note that using grsecurity is not free and requires purchasing a yearly subscription.