Debug di SUID per l'escalation dei privilegi

2

Quando esegui l'escalation dei privilegi, supponendo un'applicazione con il set SUID e un debugger, cosa ci impedisce di avviare una shell dal debugger? Voglio dire basta scrivere il codice shell in una variabile d'ambiente o da qualche parte in memoria e basta chiamare il puntatore all'interno del debugger. In ogni caso, se ciò non dovesse funzionare, potremmo semplicemente modificare manualmente un indirizzo di ritorno nello stack e eventualmente anche separarlo in seguito.

Penso di essermi perso qualcosa ma non riesco a vedere di cosa si tratta. La mia ipotesi migliore sarebbe che quando un debugger è collegato, il bit SUID viene cancellato, altrimenti questo è un modo molto generico di privilegiare l'escalation.

    
posta alex10791 31.12.2017 - 03:59
fonte

2 risposte

4

what stops us from starting a shell from within the debugger?

Se si esegue un programma setuid sotto debugger e non si è root, verrà eseguito come se non fosse setuid. Significa che verrà eseguito sotto il tuo id, non root. Quindi mentre puoi generare una shell, utilizzerà le tue credenziali.

Puoi testarlo da solo avviando su sotto gdb e verificando in un'altra console che sia eseguito sotto il tuo account utente.

E se avvii il programma setuid e poi provi a collegarlo a gdb, ciò restituirà l'errore "permesso negato".

    
risposta data 31.12.2017 - 07:47
fonte
2

Solo root può collegarsi a un processo con privilegi elevati. Un po 'più in dettaglio, allegando a un processo in esecuzione con la ptrace chiamata di sistema (che è ciò che i debugger usano sotto il cofano) richiede diverse condizioni. Una condizione necessaria, la classica condizione Unix, è che se il processo di destinazione è in esecuzione senza privilegi elevati (nessun setuid, nessun setgid e nessun altro meccanismo di elevazione dei privilegi come setcap), allora il processo che chiama ptrace deve essere in esecuzione come stesso ID utente. Un processo eseguito come root (ID utente efficace uguale a 0) può sempre essere collegato, quindi root può eseguire il debug di qualsiasi processo.

(Linux ha ulteriori restrizioni a seconda del suo stato di hardening, la maggior parte delle distribuzioni imposta kernel.yama.ptrace_scope su 1, che impedisce a qualsiasi processo non root di eseguire ptrace tranne che per tracciare i suoi processi figli. Ciò significa che puoi eseguire un programma in un debugger ma non collegare un debugger a un processo già in esecuzione.)

Inoltre, se si sta rintracciando un processo (cioè essendo sottoposto a debug), allora non può elevarne i privilegi. L'elevazione del privilegio viene eseguita dalla chiamata di sistema execve , in base ai flag di autorizzazione nel file eseguito. Se un processo chiama execve mentre viene tracciato, i flag di elevazione dei privilegi vengono ignorati e la nuova immagine di processo ha gli stessi privilegi che aveva prima della chiamata a execve .

In questo modo, l'elevazione dei privilegi è incompatibile con qualsiasi cosa possa modificare le implicazioni sulla sicurezza. Non c'è modo di organizzarsi per eseguire un debugger su un processo con privilegi extra, a meno che non si esegua il debugger come root (se lo si può fare allora non si otterranno privilegi che non avevate già).

Se si desidera eseguire il debug di un programma eseguito con privilegi elevati, ci sono due modi, entrambi che richiedono che il debugger venga eseguito come root. È possibile avviare il debugger e farlo eseguire l'intero codice di preparazione che imposta i privilegi con cui verrà eseguito il processo. Oppure puoi far partire il programma nelle sue condizioni normali e collegarlo ad esso in qualsiasi momento.

Ovviamente, se un programma inizia come setuid e poi rilascia privilegi (cioè finisce con ID utente effettivi, reali e salvati uguali, e allo stesso modo per ID gruppo e altri privilegi), è possibile allegare un debugger in esecuzione sotto stesso utente dopo che il processo ha perso i suoi privilegi.

    
risposta data 01.01.2018 - 19:05
fonte

Leggi altre domande sui tag