Archivio per 28 Luglio 2009

WordPress Changing File Permissions

28 Luglio 2009


On computer filesystems, different files and directories have permissions that specify who and what can read, write, modify and access them. This is important because WordPress may need access to write to files in your wp-content directory to enable certain functions.

Permission Modes

  7       5     5
 user   group  world
 r+w+x  r+x    r+x
 4+2+1  4+0+1  4+0+1  = 755

The permission mode is computed by adding up the following values for the user, the file group, and for everyone else. The diagram shows how.

  • Read 4 – Allowed to read files
  • Write 2 – Allowed to write/modify files
  • eXecute1 – Read/write/delete/modify/directory
  6      4      4
 user   group  world
 r+w    r      r
 4+2+0  4+0+0  4+0+0  = 644

Example Permission Modes

Mode Str Perms Explanation
0477 -r–rwxrwx owner has read only (4), other and group has rwx (7)
0677 -rw-rwxrwx owner has rw only(6), other and group has rwx (7)
0444 -r–r–r– all have read only (4)
0666 -rw-rw-rw- all have rw only (6)
0400 -r——– owner has read only(4), group and others have no permission(0)
0600 -rw——- owner has rw only, group and others have no permission
0470 -r–rwx— owner has read only, group has rwx, others have no permission
0407 -r—–rwx owner has read only, other has rwx, group has no permission
0670 -rw-rwx— owner has rw only, group has rwx, others have no permission
0607 -rw—-rwx owner has rw only, group has no permission and others have rwx
See full list 0000 to 0777.

Permission Scheme for WordPress

All files should be owned by your user account on your web server, and should be writable by your username. Any file that needs write access from WordPress should be group-owned by the user account used by the webserver. For example, you may have a user account that lets you FTP files back and forth to your server, but your server itself may run using a separate user, in a separate usergroup. A user such as dhapache or nobody.

The file and folder permissions of wordpress should be the same for most users, depending on the type of installation you performed and the umask settings of your system environment at the time of install.

NOTE: If you installed WordPress yourself, you likely do not need to modify file permissions. Unless you are experiencing problems with permission errors, or you want to, you probably should not mess with this.

For core WordPress files, all should be writable only by your user account. However, if you utilize mod_rewrite Permalinks or other .htaccess features you should make sure that WordPress can also write to your /.htaccess file.
If you want to use the built-in theme editor, all files need to be group writable. Try using it before modifying file permissions, it should work.

Some plugins require the /wp-content/ folder be made writeable, but in such cases they will let you know during installation. In some cases, this may require assigning 755 permissions or higher (e.g. 777 on some hosts). The same is true for /wp-content/cache/ and maybe /wp-content/uploads/

Additional directories under /wp-content/ should be documented by whatever plugin / theme requires them. Permissions will vary.

|- index.php
|- wp-admin
|   `- wp-admin.css
|- wp-blog-header.php
|- wp-comments-post.php
|- wp-commentsrss2.php
|- wp-config.php
|- wp-content
|   |- cache
|   |- plugins
|   |- themes
|   `- uploads
|- wp-cron.php
|- wp-includes
`- xmlrpc.php

Using an FTP Client

FTP programs (“clients”) allow you to set permissions for files and directories on your remote host. This function is often called chmod or set permissions in the program menu.

In a WordPress install, two files that you will probably want to alter are the index page, and the css which controls the layout. Here’s how you change index.php – the process is the same for any file.

In the screenshot below, look at the last column – that shows the permissions. It looks a bit confusing, but for now just note the sequence of letters.

Initial permissions

Right-click ‘index.php’ and select ‘File Permissions’
A popup screen will appear.

Altering file permissions

Don’t worry about the check boxes. Just delete the ‘Numeric value:’ and enter the number you need – in this case it’s 666. Then click OK.

Permissions have been altered

You can now see that the file permissions have been changed.

Unhide the hidden files

By default, most FTP Clients, including FileZilla, keep hidden files, those files beginning with a period (.), from being displayed. But, at some point, you may need to see your hidden files so that you can change the permissions on that file. For example, you may need to make your .htaccess file, the file that controls permalinks, writeable.

To display hidden files in FileZilla, in it is necessary to select ‘View’ from the top menu, then select ‘Show hidden files’. The screen display of files will refresh and any previously hidden file should come into view.

To get FileZilla to always show hidden files – under Edit, Settings, Remote File List, check the Always show hidden files box.

Using the Command Line

If you have shell/SSH access to your hosting account, you can use chmod to change file permissions, which is the preferred method for experienced users. Before you start using chmod it would be recommended to read some tutorials to make sure you understand what you can achieve with it. Setting incorrect permissions can take your site offline, so please take your time.

You can make all the files in your wp-content directory writable in two steps, but before making every single file and folder writable you should first try safer alternatives like modifying just the directory. Try each of these commands first and if they dont work then go recursive, which will make even your themes image files writable. Replace DIR with the folder you want to write in

chmod 746 -v DIR
chmod 747 -v DIR
chmod 756 -v DIR
chmod 757 -v DIR
chmod 764 -v DIR
chmod 765 -v DIR
chmod 766 -v DIR
chmod 767 -v DIR

If those fail to allow you to write, try them all again in order, except this time replace -v with -R, which will recursively change each file located in the folder. If after that you still cant write, you may now try 777.

About Chmod

chmod is a unix command that means “change mode” on a file. The -R flag means to apply the change to every file and directory inside of wp-content. 766 is the mode we are changing the directory to, it means that the directory is readable and writable by WordPress and any and all other users on your system. Finally, we have the name of the directory we are going to modify, wp-content. If 766 doesn’t work, you can try 777, which makes all files and folders readable, writable, and executable by all users, groups, and processes.

If you use Permalinks you should also change permissions of .htaccess to make sure that WordPress can update it when you change settings such as adding a new page, redirect, category, etc.. which requires updating the .htaccess file when mod_rewrite Permalinks are being used.

  1. Go to the main directory of WordPress
  2. Enter chmod -v 666 .htaccess
NOTE: From a security standpoint, even a small amount of protection is preferable to a world-writeable directory. Start with low permissive settings like 744, working your way up until it works. Only use 777 if necessary, and hopefully only for a temporary amount of time.

The dangers of 777

The crux of this permission issue is how your server is configured. The username you use to FTP or SSH into your server is most likely not the username used by the server application itself to serve pages.

  7      7      7
 user   group  world
 r+w+x  r+w+x  r+w+x
 4+2+1  4+2+1  4+2+1  = 777

Often the Apache server is ‘owned’ by the dhapache or nobody user accounts. These accounts have a limited amount of access to files on the server, for a very good reason. By setting your personal files and folders owned by your user account to be World-Writable, you are literally making them World Writable. Now the dhapache and nobody users that run your server, serving pages, executing php interpreters, etc.. will have full access to your user account files.

This provides an avenue for someone to gain access to your files by hijacking basically any process on your server, this also includes any other users on your machine. So you should think carefully about modifying permissions on your machine. I’ve never come across anything that needed more than 767, so when you see 777 ask why its necessary.

The Worst Outcome

The worst that can happen as a result of using 777 permissions on a folder or even a file, is that if a malicious cracker or entity is able to upload a devious file or modify a current file to execute code, they will have complete control over your blog, including having your database information and password.

Find a Workaround

Its usually pretty easy to have the enhanced features provided by the impressive WordPress plugins available, without having to put yourself at risk. Contact the Plugin author or your server support and request a workaround.

Finding Secure File Permissions

The .htaccess file is one of the files that is accessed by the owner of the process running the server. So if you set the permissions too low, than your server won’t be able to access the file and will cause an error. Therein lies the method to find the most secure settings. Start too restrictive and increase the permissions until it works.

Example Permission Settings

The following example has a custom compiled php-cgi binary and a custom php.ini file located in the cgi-bin directory for executing php scripts. To prevent the interpreter and php.ini file from being accessed directly in a web browser they are protected with a .htaccess file.

Default Permissions (umask 022)

644 -rw-r--r--  /home/user/wp-config.php
644 -rw-r--r--  /home/user/cgi-bin/.htaccess
644 -rw-r--r--  /home/user/cgi-bin/php.ini
755 -rwxr-xr-x  /home/user/cgi-bin/php.cgi
755 -rwxr-xr-x  /home/user/cgi-bin/php5.cgi

Secured Permissions

600 -rw-r--r--  /home/user/wp-config.php
604 -rw----r--  /home/user/cgi-bin/.htaccess
600 -rw-------  /home/user/cgi-bin/php.ini
711 -rwx--x--x  /home/user/cgi-bin/php.cgi
100 ---x------  /home/user/cgi-bin/php5.cgi

.htaccess permissions

644 > 604 – The bit allowing the group owner of the .htaccess file read permission was removed. 644 is normally required and recommended for .htaccess files.

php.ini permissions

644 > 600 – Previously all groups and all users with access to the server could access the php.ini, even by just requesting it from the site. The tricky thing is that because the php.ini file is only used by the php.cgi, we only needed to make sure the php.cgi process had access. The php.cgi runs as the same user that owns both files, so that single user is now the only user able to access this file.

php.cgi permissions

755 > 711This file is a compiled php-cgi binary used instead of mod_php or the default vanilla php provided by the hosting company. The default permissions for this file are 755, which

php5.cgi permissions

755 > 100 – Because of the setup where the user account is the owner of the process running the php cgi, no other user or group needs access, so we disable all access except execution access. This is interesting because it really works. You can try reading the file, writing to the file, etc.. but the only access you have to this file is to run php scripts. And as the owner of the file you can always change the permission modes back again.

$ cat: php5.cgi: Permission denied
./php5.cgi:  Welcome

Documenti Tecnici

Articoli con tag hardening WordPress

28 Luglio 2009

Articoli con tag hardening

Il titolo è ovviamente ad effetto. Dopo aver avuto fra le mani il codice di qualche sito compromesso, ho cominciato a pensare a qualcosa per impedire o mitigare l’effetto di un bug nel codice di WordPress tale da portare ad una intrusione ed all’iniezione di codice malevolo.

Nessuna pretesa di presentare la soluzione definitiva, anzi: chi si occupa di queste cose sa meglio di chiunque altro che ogni software ha innumerevoli modi per essere sovvertito nel funzionamento.

Andiamo con ordine.


La prima linea di difesa è appunto il metodo di hosting, ossia dove e come è ospitato il nostro blog. Di solito abbiamo a disposizione uno spazio accessibile via FTP (o altri metodi a piacere), un database su MySQL ed un pannello di controllo. Il primo problema viene dal metodo con cui il corrispondente web server accede al nostro spazio: il web server altro non è che un programma che viene eseguito con un certo utente di sistema ed accede in lettura al nostro spazio per prendere i file e presentarli al resto del mondo. Alcuni fornitori adottano la corretta separazione di privilegi fra l’account con cui viene eseguito il web server e l’account con cui accediamo per modificare il nostro sito: il risultato è che i file da noi scritti non possono essere modificati dal web server. Tradotto, vuol dire che se un malintenzionato scopre una falla in WordPress e tenta di sfruttarla per modificare il codice stesso di WordPress, o di scrivere un file aggiuntivo fra quelli del sito, non ci riesce perché il web server ha accesso in sola lettura.

L’effetto collaterale è che alcune funzioni di WordPress non sono disponibili: la modifica dei temi e dei plugin, l’upload di file ed il backup del database su un file nel server. Queste funzioni richiedono appunto che il web server abbia accesso in scrittura e modifica a queste directory e file:

  • wp-content/themes/ e tutti i file presenti in essa per la modifica dei temi
  • wp-content/backup-xxx/ per i backup (se si ha il plugin installato ed attivo)
  • wp-content/uploads/ per i file caricati tramite il manager di WordPress
  • wp-content/plugins/ per i plugin.

Rendere di nuovo utilizzabili queste funzioni è piuttosto facile, al prezzo di diminuire la sicurezza di un po’: si modificano i permessi di accesso ai file ed alle directory interessate consentendo la modifica al web server. E’ pur vero che questa assegnazione può essere granulare, ossia possiamo decidere di permettere solo gli upload, ed assegnare i permessi giusti alla sola directory wp-content/uploads/.

Se invece, come purtroppo succede con alcuni servizi a basso costo, il web server accede con lo stesso account con cui accediamo noi, siamo di fronte ad un potenziale problema di sicurezza che rende molto facile l’attacco da parte di un malintenzionato in presenza di un bug in WordPress che permetta l’iniezione di codice e di file nel sito.
Questo perché il web server può essere costretto a modificare praticamente qualsiasi file fra quelli installati nel nostro sito, e niente glielo impedisce. Nell’altro caso invece, anche in presenza di un bug che permette l’iniezione di codice malevolo, l’operazione fallisce perché il web server non ha i permessi per scrivere o modificare file.

Queste sono le due casistiche che ci si trova di fronte. Nel secondo il rischio è molto maggiore e diventa difficile contrastarlo. Ma qualcosa si può fare. Vediamo.

Le misure minime

Partiamo da alcune impostazioni generali di WordPress:

  • Registrazione degli utenti: se non abbiamo particolari necessità di consentire l’accesso a chiunque voglia registrarsi, è meglio disabilitare la voce relativa alla registrazione aperta a tutti nel pannello di opzioni generali. Gran parte degli attacchi sono facilitati dalla possibilità di registrarsi. In parecchie vecchie versioni di WordPress c’era un bug che permetteva ad un utente registrato di elevare i propri privilegi, anche solo per alcune operazioni, ma tanto bastava ad aprire una breccia nelle difese. Quindi, se non serve, disabilitiamo. Da notare che non è una efficace misura contro lo spam, costringere gli utenti a registrarsi per commentare. Gli spammer non si fanno intimidire, mentre invece si scoraggiano i visitatori “onesti”. E lo spam passa lo stesso. E’ molto più efficace un plugin antispam o la moderazione dei commenti.
  • Cancelliamo i temi non utilizzati: anche quelli “di serie” con WordPress, accertando prima che i file non siano utilizzati dal tema corrente, naturalmente. Se dovesse servire, terremo di scorta il tema di default di WordPress e lo caricheremo sul sito se occorre. Questo perché i file dei temi sono comunque raggiungibili, anche se inutilizzati, ed il percorso per raggiungerli è noto, visto che è uguale per tutte le installazioni. Sono file PHP, quindi passibili di tutti i problemi di qualsiasi altro file PHP. A maggior ragione se il tema non è uno di quelli ufficiali. Potrebbe contenere errori sfruttabili da un malintenzionato, e data la minore diffusione del singolo tema rispetto a WordPress nel complesso, gli eventuali errori potrebbero passare inosservati per molto tempo, esponendo il nostro blog ad un rischio inaccettabile.
  • Cancelliamo i plugin non utilizzati: vale lo stesso discorso fatto per i temi. Anche i plugin sono file PHP, certamente più difficili da raggiungere, nel senso che se sono disabilitati non c’è modo di sapere dall’esterno se siano installati, quindi il lavoro per un malintenzionato è un po’ più difficile. Ma basta guardare quante volte parliamo nel blog stesso dei plugin e dei temi che stiamo provando per capire che troppo spesso l’informazione per il malintenzionato la forniamo noi stessi su un piatto d’argento…

Rinunciamo alla modifica del tema e dei plugin

Per operare su tema e plugin lavoreremo sempre su una copia locale nel nostro computer, per poi trasferire i file modificati sul server. E’ più laborioso ma infinitamente più sicuro. Senza trascurare il fatto di poter usare il nostro editor preferito per modificare i file PHP e CSS del tema o dei plugin.

Per impostare questa limitazione occorre togliere i permessi di scrittura al web server. Se siamo nell’ipotesi dell’utente dedicato differente dal nostro, basta impostare i permessi al valore ottale 0644 per i file e 0755 per le directory a partire da wp-content/plugins/ e wp-content/themes/, che significa: proprietario può leggere e scrivere, tutti gli altri solo leggere, invece dei classici 0666 e 0777 consigliati per abilitare la modifica dal pannello di amministrazione di WordPress.

Se invece siamo nel caso peggiore, quello del web server che accede con lo stesso nostro utente, le modifiche sono molto meno efficaci, anche se niente vieta di applicarle: occorre togliere del tutto il permesso di scrittura, anche a noi stessi, usando il valore ottale 0444 per i file e 0555 per le directory. E’ una misura molto meno efficace perché il permesso di scrittura può essere ripristinato dal proprietario del file o della directory, che in questo caso è l’utente con cui viene eseguito anche il web server: se un malintenzionato riesce ad accedere, può tentare di ripristinare il permesso attraverso un comando in PHP e da lì avere via libera. E’ comunque un ulteriore ostacolo, il che non guasta.

Disinnescare i file in upload

Questa è un po’ più complicata, e richiede l’uso di alcune funzioni del web server che potrebbero non essere abilitate. Si tratta di impedire che un file PHP inserito nella cartella di upload da un malintenzionato possa essere eseguito dall’esterno.

Se abbiamo la registrazione degli utenti inibita, siamo già a buon punto, e questa misura è in un certo senso superflua. Certo, se esistesse un bug così grande in WordPress da permettere l’upload di un file anche senza essere registrati, la prima directory che potrebbe essere utilizzata è proprio quella di upload: per definizione deve essere scrivibile dal web server. A questo punto, basta immaginare un file PHP inserito a bella posta che includa il file di configurazione e mostri utente e password del database, di seguito piazzare un file che permetta di modificare il database e includere un altro file, o se stesso, come plugin di WordPress. Il gioco è fatto.

Ebbene, se il nostro servizio di hosting lo permette è possibile disinnescare l’esecuzione di file PHP nella directory degli upload ed in tutte le sottodirectory, inserendo un file .htaccess nella directory di upload con una singola direttiva:

RemoveHandler .php

Il risultato è che un eventuale file PHP inserito in quella directory non viene interpretato, ma quando fosse invocato via browser verrebbe trattato come un file di testo semplice, e ne verrebbe mostrato il contenuto, ossia non verrebbe eseguito come script PHP.

Questo ovviamente è possibile solo se il servizio di hosting lo permette. Conoscendo il tipo di web server installato e le opzioni abilitate è possibile migliorare di parecchio la sicurezza di WordPress, naturalmente a prezzo di qualche disagio in più.


Ci sarebbe molto da dire, ancora. Non ho volutamente trattato argomenti abbastanza inflazionati come sicurezza delle password, aggiornamenti di WordPress e spam in commenti e trackback. Certamente l’argomento non è a portata di principiante, come sempre occorre sapere cosa c’è “sotto il cofano”, ma non ci si improvvisa in queste cose. I centinaia di blog WordPress violati presenti in Rete, di cui sto faticosamente tentando di avvertire i proprietari, dimostrano che mentre scrivere in un blog è alla portata di chiunque, mantenere un blog non è proprio banale.



Documenti Tecnici