In un contesto PHP/Apache/Linux, perché esattamente chmod 777 è pericoloso?

Ci sono molte buone ragioni generali per seguire il minimalismo quando si tratta di autorizzazioni, ma nel contesto di un webhost LAMP, le poche che vengono subito in mente sono

• Su una piattaforma di hosting condiviso, altri utenti che condividono il tuo host ora possono leggere e scrivere sui tuoi script.
• Su un host dedicato, i processi non autorizzati possono leggere/scrivere ed eliminare accidentalmente i tuoi file. Diciamo che c'è un processo di registrazione personalizzato in esecuzione in background come utente nessuno che ha un bug che si traduce nel tentativo di rm -rf / . Ora generalmente questo sarà innocuo perché difficilmente ci sarebbe alcun file su cui nessuno dovrebbe avere i permessi di scrittura, ma questo processo canaglia ora porterà con sé i tuoi file.
• Per deturpare il tuo sito web, qualcuno deve solo ottenere l'accesso come qualsiasi utente, anche dire nobody o qualche account fittizio. In genere, l'attaccante dovrebbe eseguire un ulteriore attacco di escalation a livello utente per raggiungere il punto in cui può causare danni. Questa è una vera minaccia. Alcuni servizi non critici potrebbero essere eseguiti con account fittizi e potrebbero contenere una vulnerabilità.

Aumenta notevolmente il profilo di vulnerabilità del tuo sito Web ad attività dannose perché è necessario entrare in un solo account.

Chiunque acceda al tuo sistema con qualsiasi login può fare quello che vuole sulle tue pagine, incluso cambiarle in "Questo sito web è davvero insicuro, quindi per favore dammi i dati della tua carta di credito".

EDIT:(per chiarire e indirizzare i commenti)

Molti servitori hanno più di uno scopo nella vita. Gestiscono più servizi. Se isoli attentamente quei servizi l'uno dall'altro assegnando a ciascuno un utente univoco e gestendo le autorizzazioni dei file di conseguenza, sì, sei ancora nei guai se qualcuno compromette le credenziali di un account, ma il danno che può fare è limitato a quell'unico servizio . Se hai solo un account generico e imposti l'intero file system su 777, un account compromesso mette a repentaglio tutto sulla macchina.

Se il tuo server è dedicato solo all'esecuzione di Apache/PHP e non ha altri scopi nella vita, e c'è un solo account con cui viene eseguito Apache/PHP, avere quell'account compromesso è buono come avere l'intera macchina compromessa dal punto di vista della tua applicazione (sebbene dovresti comunque avere i file di sistema protetti e non scrivibili dall'account utilizzato per eseguire PHP... ciò dovrebbe comunque essere possibile solo per un account amministratore/root).

Se possono scrivere un file ed è eseguibile, possono cambiarlo in qualcosa che viene eseguito sulla tua macchina (eseguibile o script) e quindi utilizzare shell_exec di PHP per eseguire quell'eseguibile. Se sei configurato per non consentire shell_exec, possono modificare anche la tua configurazione

Ecco uno scenario:

1. Hai una directory non protetta in cui gli utenti possono caricare.
2. Caricano due file:uno script di shell e un file php che ha un system() chiamalo allo script della shell.
3. accedono allo script php che hanno appena caricato visitando l'url nel loro browser, provocando l'esecuzione dello script della shell.

Se questa directory è 777, significa che chiunque (incluso l'utente apache, che è quello che eseguirà lo script php) può eseguirlo! Se il bit di esecuzione non è impostato su quella directory e presumibilmente i file all'interno della directory, il passaggio 3 sopra non farebbe nulla.

modifica dai commenti:non sono i permessi del file PHP che contano, sono i system() chiamata all'interno del file PHP che verrà eseguita come chiamata di sistema linux dall'utente linux apache (o qualsiasi altra cosa tu abbia impostato apache per l'esecuzione), ed è PRECISAMENTE dove conta il bit di esecuzione.