Quali sono i problemi di sicurezza e le condizioni di competizione nell'uso di `find -exec`?

Dalla findpagina man :

-exec command ;
    There are unavoidable security problems
    surrounding use of the -exec action; you should use the
    -execdir option instead.

-execdir command {} +
    Like -exec, but the specified command is run from the
    subdirectory containing the matched file, which is not
    normally the directory in which you started find.  This a much
    more secure method for invoking commands, as it avoids race
    conditions during resolution of the paths to the matched
    files.

Cosa significa questo? Perché ci sono condizioni di gara con l'esecuzione dalla directory di partenza? E come sono questi rischi per la sicurezza?

shell find security

— Danny Tuppeny
fonte

Correlati: Perché il looping sull'output di find è una cattiva pratica? dove questo è coperto in alcune delle risposte.

— Stéphane Chazelas,

Risposte:

Ho trovato i dettagli qui :

L' -execazione provoca l'esecuzione di un altro programma. Passa al programma il nome del file che viene considerato in quel momento. In genere, il programma richiamato eseguirà alcune azioni su quel file. Ancora una volta, c'è una condizione di razza che può essere sfruttata qui. Prenderemo come esempio specifico il comando
 find /tmp -path /tmp/umsp/passwd -exec /bin/rm
In questo semplice esempio, stiamo identificando un solo file da eliminare e invocando /bin/rmper eliminarlo. Esiste un problema perché esiste un intervallo di tempo tra il punto in cui find decide che deve elaborare l' -execazione e il punto in cui il /bin/rmcomando in effetti emette la chiamata di sistema unlink () per eliminare il file dal filesystem. Entro questo periodo, un utente malintenzionato può rinominare la /tmp/umsp directory, sostituendola con un collegamento simbolico a /etc. Non c'è modo /bin/rmdi determinare se sta funzionando sullo stesso file che Find aveva in mente. Una volta che il collegamento simbolico è in atto, l'aggressore ha convinto a trovare la causa della cancellazione del /etc/passwdfile, che non è l'effetto previsto dal comando che è stato effettivamente invocato.

Non sono sicuro della probabilità che qualcuno possa mai sfruttarlo; ma immagino che ci sia la risposta!

— Danny Tuppeny
fonte

Nel caso sopra, execdirchdir /tmp/umspprima di eseguire il comando, e quindi teoricamente, un ricollegamento di un utente malintenzionato nella directory non avrebbe alcun effetto .. se il ricollegamento avvenisse dopo aver trovato "decide" di valutare, -execma prima che il rmcomando possa fare il suo lavoro. Ma mi chiedo perché questo possa fare la differenza: l'attaccante potrebbe semplicemente ricollegare dopo che l'utente ha deciso di scrivere il findcomando.

— Otheus,

@RuiFRibeiro Il collegamento non è l'argomento passato al comando, è una directory intermedia. /tmp/umspè una directory quando la findvede, ma quando rmviene eseguita, l'attaccata l'ha trasformata in un collegamento simbolico a /etc. /tmp/umsp/passwdè sempre un file normale, ma non è lo stesso.

— Gilles 'SO- smetti di essere malvagio' il

Credo che il motivo per cui -execè pericoloso sia perché se l'utente non specificasse il nome completo e il percorso del programma da eseguire, potrebbe potenzialmente eseguire il programma sbagliato.

Esempio:

find /some/path -exec coolprogram

In /some/path, qualcuno ne ha creato un altro coolprograme carica tutti i tuoi dati su un cattivo attore.

Ma aspetta, dici, non è necessario eseguirlo come ./coolprogram? Sì, ma alcune persone hanno PATH=.:/bin:whatever, che eseguirà il programma nella directory corrente.

Ciò è probabilmente semplificato, ma penso che potrebbe essere pericoloso in alcuni casi. Ho dovuto risolvere un problema una volta in cui un byte zero cpiofiniva nella directory sbagliata. Ha causato l'arresto anomalo di un programma perché cpionon funzionava poiché stava eseguendo il file a zero byte nella directory.

— Doug
fonte

Questi rischi non sono isolati find -exec. Se hai inserito il .tuo percorso, semplicemente eseguire coolprogramnella tua directory corrente è già pericoloso, che tu lo usi findo meno!

— Danny Tuppeny,

D'accordo, ma sembra che -execdir faccia attenzione anche alle condizioni che ho menzionato:

The ‘-execdir’ action refuses to do anything if the current directory is included in the $PATH environment variable. This is necessary because ‘-execdir’ runs programs in the same directory in which it finds files – in general, such a directory might be writable by untrusted users. For similar reasons, ‘-execdir’ does not allow ‘{}’ to appear in the name of the command to be run.

— Doug

Immagino che la morale della storia sia quella di avere. nel tuo percorso è anche una cattiva idea, motivo per cui mi assicuro che non sia presente.

— Doug,

Interessante sapere di non consentire .nel percorso e {}nel comando. Forse in futuro Linux proibirà .completamente il percorso e gli strumenti non dovranno implementare i propri controlli di sicurezza! :)

— Danny Tuppeny,

Penso che il 90% del codice che scrivo sia solo per catturare il 5% delle cose che vanno male. :)

— Doug