Esiste un modo per cui un utente malintenzionato potrebbe utilizzare mkdir per compromettere un sistema?

22

Sto configurando un account utente limitato per l'utente ricardo, un utente problematico sul mio sistema. Voglio garantirgli il diritto di creare directory sudo, cosa che a volte deve fare. Sto considerando questa regola nel mio /etc/sudoersfile:

ricardo   ALL=(root) NOPASSWD: /bin/mkdir

Utilizzando solo questa regola, c'è un modo in cui ricardo potrebbe intenzionalmente o accidentalmente compromettere il sistema?

security directory

— Ricardo Altamirano
fonte

2

Se hai un filesystem con un conteggio di inode statico, potrebbe usare tutti i tuoi inode.

— Giordania,

2

@schaiba Gli piace armeggiare e vedere se riesce a sfruttare il sistema e non legge sempre le pagine man come dovrebbe.

— Ricardo Altamirano,

8

Una corretta istruzione dell'utente, combinata senza sudo al momento, sarebbe la cosa consigliata da fare da me.

— schaiba,

2

Come dice @schaiba, puoi usare tali utenti insegnandoli e dando loro responsabilità (sotto stretta supervisione). Ho visto guerre tra sysdamins e utenti, poiché i primi hanno cercato di bloccare troppo il sistema. Gli utenti erano più numerosi degli amministratori di sistema da 10 a 1 e anche allora ( senza l'accesso a Internet di oggi!) La sconfitta degli amministratori di sistema era umiliante. Non entrare mai in una simile posizione!

— vonbrand,

2

È il caso di un ricardo di troppo. O almeno, così parlava BOFH ...

— Deer Hunter il

21

Ho il sospetto che un attacco del genere funzioni, in cui «qualcosa» è un modulo del kernel che proverà a caricarsi dopo il montaggio di rootfs:

$ sudo mkdir -m 777 /lib/modules/`uname -r`/a
$ cp evil.ko /lib/modules/`uname -r`/a/«something».ko

Si noti inoltre che è possibile utilizzare altri nomi, a seconda degli alias dichiarati nel modulo. Immagino che non verrà caricato fino a quando non verrà eseguito depmod, cosa che succederà la prossima volta che ci sarà un aggiornamento del kernel, quindi mkdirnon verrà nemmeno mostrato di recente nel registro sudo.

Ci sono molte cose in / etc che leggono tutti i file in una directory, a volte in modo ricorsivo. Ancora peggio, alcune di quelle directory non esistono per impostazione predefinita e l'unico modo per conoscerle è leggere la manpage, gli script di init, ecc. Per il programma che le utilizza. Alcune, anche peggio, sono cose deprecate di retrocompatibilità e potrebbero non essere più documentate.

modifica: pensato a qualche altra directory, queste in /usr/local:

/usr/local/lib/perl/5.14.2(differisce a seconda della versione di Perl, prova perl -Va scoprirlo). Crea una Filesottodirectory e inseriscila Find.pm. Ora, ogni volta che qualcuno lo utilizza File::Find, utilizzerà la versione dell'attaccante. Allo stesso modo, fai lo stesso con Getopt::Long. Le utilità di sistema sono spesso scritte in Perl, quindi questo probabilmente dà radice. (Prova ack-grep --color -a 'use.+::' /usr/sbin | less -R)
Penso che Python, Ruby, ecc. Abbiano directory simili. Anche le utilità di sistema sono scritte in Python.
Sovvertire molte cose che qualcuno compila con le sue sottodirectory /usr/local/include.

— derobert
fonte

Oh, ma se <utente malvagio> è in grado di copiare i moduli su cui il kernel li caricherà, il gioco termina prima dell'inizio.

— vonbrand,

1

@vonbrand <utente malvagio> normalmente non può, ma ha usato il suo sudo mkdirper creare una nuova directory dove può.

— derobert,

20

Eseguendo mkdircome root, l'utente può bloccare altri processi / utenti dalla creazione di nuovi file e directory creando directory con nomi identici (e / o diritti errati) in precedenza.

Questo potrebbe essere rilevante per la sicurezza, specialmente con i file di registro e di blocco .

Come notato da Jordan , è possibile utilizzare anche il numero massimo di inode che può bloccare l'intero sistema.

Aggiungendo l'utente a gruppi specifici (o usando ACL ), dovresti essere in grado di risolvere i problemi senza concedere alcun diritto tramite sudo.

— Jofel
fonte

Grandi punti. Probabilmente lascerò mkdirfuori l'elenco dei comandi che ricardo può usare.

— Ricardo Altamirano,

Se è per estenuanti inode, un semplice for((i = 0;; i++)); do touch $i; doneandrà bene (bashismo, scusa, ma hai l'idea).

— vonbrand,

@vonbrand Tranne che non è come root, quindi verrà bloccato da una quota. Naturalmente, altri sudocomandi che OP sta prendendo in considerazione possono consentire anche di esaurire gli inode; L'OP deve essere consapevole di quel vettore DoS.

— derobert,

11

Dovresti reindirizzarlo a una prigione chroot. O meglio, a una piccola VM, che può andare in crash una volta ogni ora. Tutto quello che devi fare è fornire una nuova copia.

— ott--
fonte

Consiglio vivamente questo. Dagli accesso come root sulla propria VM.

— emory

to a chroot ^ H ^ H ^ H ^ H ^ Carcere di Hounty ...

— Cacciatore di cervi,

6

Ci sono possibilità grazie alla possibilità di creare directory con accesso in scrittura. Con mkdir -m 777 blahl' ricardoutente può scrivere quello che preferisce nella nuova directory. Avresti bisogno di un processo sul sistema già in esecuzione come un altro utente che ricercherà un albero di directory per caricare config, script o moduli. Quindi l'utente potrebbe eventualmente aggiungere le proprie cose da caricare o eseguire. La prima cosa che mi viene in mente è se si esegue un server Web in grado di eseguire php o cgi. È quindi possibile eseguire script come quell'utente. Sto lottando per trovare altri esempi del mondo reale, specialmente rootquelli ma sono sicuro che lo siano.

ssh è un esempio di demone che intrappola questo tipo di scenario. Se hai creato una .sshdirectory per un utente che non ne aveva una e hai creato il tuo authorized_hostsfile. sshdnota che le autorizzazioni delle directory sono troppo aperte e ignora la chiave pubblica.

Potresti sicuramente creare fastidi a te stesso creando directory in cui ci si aspetta che i file vengano visualizzati (come i file transitori tmp o di scambio) che molti programmi non gestiscono bene.

Potresti creare molti cgroups ma non sembra che tu faccia nulla con loro. Almeno potresti riuscire a mettere in ginocchio un sistema. Ci sono voluti circa 10000 cgroups su una scatola con 256M per il killer OOM per eliminare sshd.

Se controlli l' -mopzione mkdire l'UMASK sudodell'ambiente, penso che sia tornato ad essere solo un fastidio.

— opaco
fonte