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.

Mitigazione della vulnerabilità

Autorizzazioni del file system

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. Seleziona tutte le istanze di WordPress e fai clic su Controlla la sicurezza.
  3. Verifica che «Autorizzazioni per file e directory» sia contrassegnato come OK.
  4. Se non lo è, fai clic su Proteggi.

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>

Nota: Non esiste un elenco di file da proteggere adatto a tutte le applicazioni web o CMS. I file esatti i cui permessi devono essere modificati per proteggere un’applicazione web variano a seconda dell’applicazione in questione.

Configurazione Apache

Questo modo di mitigare la vulnerabilità è adatto per gli abbonamenti che utilizzano Apache come server web (un abbonamento utilizza Apache se la “Modalità proxy” è attiva in Hosting e DNS > Impostazioni Apache & Nginx).

Nota: 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.

Per mitigare la vulnerabilità, procedi come segue:

  1. Vai su Piani di servizio > il tuo piano > la scheda «Server Web» (o il tuo abbonamento > Siti web e Domini > Hosting e DNS > Impostazioni Apache e Nginx).
  2. Seleziona la casella di controllo “Limita la capacità di seguire link simbolici”.

Facendo ciò per un piano di servizio, si mitiga la vulnerabilità di tutti gli abbonamenti basati su quel piano di servizio (ossia, un autore di attacco che accede a un abbonamento non sarà in grado di effettuare attacchi contro altri abbonamenti). Facendo ciò per un abbonamento, si mitiga la vulnerabilità solo per quell’abbonamento.

Nota: Un sito web che utilizza collegamenti simbolici ai propri file continuerà a funzionare se non utilizza l’opzione «FollowSymLinks» nel file .htaccess, perché l’opzione «SymLinksIfOwnerMatch» è abilitata di default. Se un tale sito utilizza l’opzione «FollowSymLinks» nel file .htaccess, smetterà di funzionare.

Attenzione: 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.

Configurazione nginx

Questo modo di mitigare la vulnerabilità è adatto per gli abbonamenti che utilizzano nginx per servire direttamente i file statici (un abbonamento utilizza nginx se la “Modalità proxy” è disattiva o se la “Modalità proxy” è attiva e “Servire file statici direttamente da nginx” è attiva in Hosting e DNS > Impostazioni Apache & Nginx).

Per mitigare la vulnerabilità, procedi come segue:

  1. Vai su Piani di servizio > il tuo piano > Server Web (o il tuo abbonamento > Siti web e Domini > Hosting e DNS > Impostazioni Apache e Nginx).
  2. Seleziona la casella di controllo “Limita la capacità di seguire link simbolici”.

Facendo ciò per un piano di servizio, si mitiga la vulnerabilità di tutti gli abbonamenti basati su quel piano di servizio (ossia, un autore di attacco che accede a un abbonamento non sarà in grado di effettuare attacchi contro altri abbonamenti). Facendo ciò per un abbonamento, si mitiga la vulnerabilità solo per quell’abbonamento.

Nota: 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 per 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 (un set di patch per il kernel Linux che enfatizza i miglioramenti della sicurezza, è richiesto un abbonamento a pagamento)

Se nessuna delle opzioni per mitigare la vulnerabilità di cui sopra è applicabile alla tua situazione, puoi installare il set di patch per il miglioramento della sicurezza grsecurity per il kernel Linux e poi configurare la funzionalità GRKERNSEC_SYMLINKOWN. Si noti che l’utilizzo di grsecurity non è gratuito e richiede l’acquisto di un abbonamento annuale.