Do sudo e .profile / .bashrc abilitano l'escalation di privilegi banali?

Tutto ciò che puoi fare su un account compromesso, può farlo anche un utente malintenzionato.

Fondamentalmente, questo è dovuto al fatto che i provider di Linux isolano tra gli utenti, non tra singoli processi eseguiti come lo stesso utente. Si considera che ogni processo eseguito come un determinato utente abbia capacità equivalenti a quelle di altri processi in esecuzione sotto quell'utente.

Is it true that the system sudo executable can be circumvented in this way?

Sì, e anche in altri modi. Se si elevano i privilegi per eseguire il root su un account non privilegiato compromesso, si compromette la root. Se si rilasciano privilegi da root utilizzando su a un account non privilegiato, compromette anche root ! Non puoi mai elevare in sicurezza i privilegi su un account non sicuro. Mentre è possibile sfruttare il sistema utilizzando PATH , è anche possibile dirottare il processo bash stesso per annusare l'input della chiave. Disabilitare l'esecuzione con noexec non è inoltre utile perché gli interpreti (bash, python, perl, ecc.) Continueranno a essere eseguiti. L'opzione noexec non è e non è mai stata progettata come funzionalità di sicurezza, nonostante sia regolarmente distribuita come tale.

Un elenco incompleto di modi in cui un utente malintenzionato potrebbe dirottare l'uso di sudo o su :

• Uso della variabile LD_PRELOAD sul processo principale (ad esempio bash ).

• Aggancio del processo genitore con ptrace() o process_vm_writev() .

• Sniffing o iniezione di sequenze di tasti nell'emulatore di terminale usando il protocollo X11.

• Creazione di alias o funzioni per eseguire il wrapping dell'eseguibile sudo effettivo.

Ho spiegato questi in modo più dettagliato su la mia risposta ad un'altra domanda .

Why are desktop Linux systems, by default, set up in such an easily exploitable way?

Aumentare i privilegi su un account non fidato non è qualcosa che supponiamo fare. Per non parlare del desktop Linux è un ripensamento nel grande schema dell'architettura generale * nix. È un fallimento del cinema di sicurezza ripetere incessantemente lo stesso cattivo consiglio, non un fallimento dell'architettura di sicurezza di Linux stessa. Le persone ripetono ripetutamente di usare sudo per root perché molti nuovi utenti eseguiranno invece tutto come root, anche i loro browser! In questo caso, è meglio usare sudo . È dannoso nel caso in cui l'utente sia già abbastanza intelligente da non utilizzare root per tutto.

Tieni presente che sudo è altamente configurabile e può essere progettato per consentire solo determinati comandi. Questo è dove brilla davvero. Puoi configurare sudo per consentire solo di eseguire apt-get update come root (con o senza password) e negare tutto il resto. Ciò limiterebbe ulteriormente l'aggressore a fare qualcosa di diverso da ... beh ... facendo un aggiornamento del software.

È importante ricordare che, anche se lo si configura per consentire solo l'esecuzione di determinati comandi come root, è comunque possibile sparare ai piedi se si autorizzano i programmi che non sono progettati per essere eseguiti come root tramite un utente non fidato. Ho visto un esempio di vita reale di qualcuno che cerca di eseguire VeraCrypt in questo modo e ha spiegato il motivo per cui non è sicuro . L'idea era che VeraCrypt fosse sicuro da eseguire come root, quindi dovrebbe essere sicuro usare sudo per elevarlo a root come utente non protetto e non privilegiato. Si scopre che l'idea è imperfetta e consente un'escalation di privilegi banali!

Shouldn’t the default way to invoke sudo make sure that it is, in fact, the executable provided by the system (nobody is going to type /usr/bin/sudo every time)?

La digitazione del percorso completo non ti proteggerà! Puoi facilmente creare una funzione che contenga un / iniziale, e sovrascriverà l'eseguibile reale. Anche se l'eseguibile si è assicurato che fosse autentico e tentasse di sconfiggere lo sniffing, un processo dannoso potrebbe sequestrare il processo bash e annusare le battute indipendentemente da sudo , rendendo impossibile rilevarlo dal suo punto di vista.

$ function /usr/bin/sudo { echo 'hijacked!'; }
$ /usr/bin/sudo id
hijacked!

In such an environment, it seems that using sudo is fundamentally insecure and one would be better off enabling login as root and logging in on a separate TTY.

Questo è sempre il caso. Si noti che anche l'accesso a un altro TTY non è perfettamente sicuro. Dovresti utilizzare SAK , la combinazione Secure Attention Key, per assicurarti di interagire con una sessione di accesso autentica ( agetty o logind , ad esempio). SAK è una combinazione chiave che il kernel ascolta (e quindi non può essere repressa dallo userspace). Quando lo rileva, uccide tutti i processi nel TTY corrente, attivando la richiesta di accesso per apparire. Se si è passati a un TTY genuino e senza compromessi, il prompt sparirà e riapparirà. Se sei su un TTY dirottato, uccide il processo dannoso e riporta il vero prompt di accesso.

Innanzitutto, la modifica di .profile non comporterà automaticamente l'escalation dei privilegi. L'utente interessato deve avere già sudo di diritti.

1 - sudo non viene circunventato. Stai facendo funzionare qualcos'altro al posto di esso. Puoi cambiare .profile e aggiungere alias sudo=~/.evilsudo e ottenere lo stesso risultato.

2 - Pensa al modo pigro di configurare sudo . Su un ambiente desktop, sarebbe il caso, ma non su un ambiente server. Su un ambiente server, /etc/sudoers dovrebbe concedere all'utente solo i comandi che dovrà eseguire per eseguire il suo compito. Ci si aspetterebbe che l'amministratore Oracle eseguisse sudo service oracle , quindi sarebbe su suder. Ad esempio, non oradmin ALL=(ALL:ALL) ALL .

Ed è già troppo tardi se qualcuno esegue il codice sul tuo account. Chiunque modifichi il tuo .profile potrebbe avviare un'altra shell catturando ogni singola pressione di un tasto, e tu perderai non solo la tua password, ma tutto il resto che digiti su di essa. Password ssh remote, password database, password ftp, qualsiasi cosa. Se il tuo .profile è compromesso, è game over.

Se vuoi veramente proteggere l'utente contro questo, monta ogni singola directory scrivibile dall'utente come noexec . In questo modo ~/bin o /tmp o qualsiasi altra cosa non avrà il permesso di eseguire qualsiasi cosa. Aumenti marginalmente la sicurezza e diminuisci drasticamente la praticità.