Bug nel tuo script
Se pensi che questo script funzioni alla grande, non lo hai testato abbastanza.
C'è una classica vulnerabilità nel tuo script: file temporaneo non sicuro . Hai tentato di proteggerti, ma in un modo troppo complicato, e ti sei sparato ai piedi.
random=$(tr -dc [:digit:] </dev/urandom | head -c2)
random è impostato su due cifre casuali. C'è una probabilità dell'1% che questo restituisca 01 , il che fa sì che random2 sia impostato su una stringa di lunghezza 1. Se si esegue questo script ogni 10 minuti, ciò accade circa una o due volte al giorno. (In realtà questa è una sottostima: la vulnerabilità rimane praticamente sfruttabile se per 02 (~ 4k file) e forse 03 (~ 240k file).) Un utente locale può creare tutti i file /tmp/.0 , /tmp/.1 , ecc. Quando viene raggiunta la probabilità dell'1%, lo script scrive su un file di proprietà di quell'utente e poi lo legge. L'utente può modificare il file nel frattempo per inserire la propria password di root preferita. Questa è una condizione di competizione, quindi un exploit potrebbe non essere affidabile al 100%, ma ci vorranno solo pochi giorni di attesa prima che abbia successo.
Un'altra vulnerabilità che non richiede una condizione di competizione oltre alla probabilità casuale è che l'utente locale potrebbe creare un collegamento simbolico, consentendo loro di troncare un file di loro scelta (la chiamata a shred tronca il contenuto del file , quindi rimuove il collegamento).
C'è anche una probabilità del 3% che random2 sia una stringa vuota: quando random è 00. In that case, your script runs chmod 0400 / tmp '. Ciò causerà molte interruzioni.
Lezioni apprese
Bene, lezioni da imparare, in ogni caso.
- Errori di cattura. Il tuo script presume che tutto funzioni correttamente e continui ad andare avanti anche se è solo sbattuto contro il muro. Usa
set -e per interrompere lo script se si verifica un errore. (Non sempre è sufficiente in script complessi, ma qui sarebbe stato sufficiente.)
- Utilizza gli strumenti standard anziché le soluzioni costruite in casa. Per creare un file temporaneo, usa
mktemp .
- Capisci perché stai facendo le cose. La creazione di un file in
/tmp con un nome casuale protegge da file temporanei non sicuri. Ma rendere la lunghezza del nome casuale non ha senso. È un parametro di sicurezza. Rendilo costante, o fallo variare in base alla configurazione o all'ambiente se si tratta di un compromesso tra sicurezza, usabilità o prestazioni; in questo caso, potresti renderlo abbastanza grande senza alcuna penalizzazione delle prestazioni.
- Il modo migliore per proteggere i dati non è esporlo. L'utilizzo di un file temporaneo non è utile in questo caso: potresti aver reindirizzato i dati a
chpasswd . Se si collegano i dati, in primo luogo non si trova mai in un file su disco, quindi non è necessario preoccuparsi di creare il file temporaneo in modo sicuro e non è necessario preoccuparsi di cancellarlo in seguito.
Nessun vantaggio in termini di sicurezza
Includere la data corrente in una password è inutile. Il punto delle password deve essere segreto. Tutti conoscono la data.
La modifica di una password non lo rende più difficile da decifrare. L'obiettivo dell'attaccante è trovare la password corrente, qualunque essa sia. Che la password modificata in passato e che cambierà in futuro non ha importanza.
Se qualcuno incrina la tua password in un dato momento e non funziona più dopo, vedrà la data e capirà abbastanza rapidamente ciò di cui hanno bisogno per cambiare.
Invece di aggiungere un elemento pubblico alla tua password, rendila più lunga, con un elemento segreto, generato casualmente . Ciò renderà più difficile la memorizzazione, ma è necessario memorizzarlo solo una volta e non è necessario cambiarlo. Le modifiche alle password non migliorano la sicurezza per un account di shell, dove una volta che l'utente malintenzionato ha avuto accesso, possono installare una backdoor che non dipende dalla password. XKCD # 936: password complessa breve o passphrase lunga del dizionario ? descrive un buon metodo per generare una password strong ma memorabile.
Altre lezioni
Non dovresti progettare un sistema di sicurezza finché non migliori le valutazioni di sicurezza.
- Cercando di migliorare la sicurezza aggiungendo un valore pubblico a una password.
- Quel problema di lunghezza del nome del file.
- Chiamare lo script
screenshot.jpg può sembrare carino, ma in realtà ha zero vantaggi di sicurezza e l'unica persona che potrebbe danneggiare sei tu, se elimini accidentalmente quel vecchio screenshot inutile.