Domanda:
Quali sono le potenziali vulnerabilità nel consentire agli utenti non root di eseguire apt-get?
kzl
2020-06-12 04:30:51 UTC
view on stackexchange narkive permalink

Ci sono due modi in cui posso pensare di farlo:

  1. Su un sistema con sudo , modificando / etc / sudoers .

  2. Su un sistema senza sudo (come un ambiente Docker), scrivendo un programma simile al seguente e impostando setuid bit con chmod u + s . apt-get controlla l'uid reale, quindi è necessaria una chiamata a setuid . 

  ... int main (int argc, char ** argv) {char * envp [] = {...}; setuid (0); execve ("/ usr / bin / apt-get", argv, envp); return 1;}

Ho due domande:

  1. Quali sono le potenziali vulnerabilità del consentire agli utenti non root di eseguire apt-get ?
  2. Il mio obiettivo è consentire alle persone di installare / rimuovere / aggiornare i pacchetti, dato che apt-get vive in un refroot personalizzato non di sistema e si installa da un custom repository apt curato. Esistono modi più sicuri per consentire agli utenti non root di eseguire apt-get su un sistema senza sudo?
Mi viene in mente questo post del blog: https://0x90909090.blogspot.com/2015/07/no-one-expect-command-execution.html Apt in particolare non è elencato lì, ma non me lo sarei aspettato affatto se fosseha permesso l'esecuzione del comando in qualche modo.Forse specificando un repository sulla riga di comando (che sarebbe sotto il controllo dell'aggressore), forse c'è un flag per un file deb locale ... e tutto ciò sta ignorando che si potrebbero rimuovere pacchetti di sistema o mantenere pacchetti non aggiornatimantenendo un file di blocco.
Un suggerimento per un modo più sicuro dipende da cosa vuoi fare.Le persone hanno bisogno di installare pacchetti?Aggiornare solo i pacchetti?O vuoi semplicemente solo un audit trail?Qual è l'obiettivo qui?
Grazie per il fidanzamento!L'obiettivo è consentire alle persone di installare / rimuovere / aggiornare i pacchetti.
https://www.cyberciti.biz/faq/debian-ubuntu-linux-hook-a-script-command-to-apt-get-upgrade-command/ Questo è un metodo che consente l'esecuzione di codice arbitrario per apt-get, ma richiede i privilegi di root per essere implementato in primo luogo.Non sono riuscito a trovarne altri.
Se gli utenti devono essere in grado di rimuovere i pacchetti, possono sempre uccidere il sistema rimuovendo i pacchetti di sistema.Un modo più sicuro potrebbe essere quello di scrivere uno script che accetti un nome di pacchetto, lo filtri e lo eviti e chiami apt install / upgrade.Per la rimozione, forse quello script potrebbe tenere traccia dei pacchetti installati dall'utente e consentire la rimozione solo di quelli?Non è banale assicurarsi che qualcosa di personalizzato come questo sia sicuro: se è importante, potresti chiedere a qualcuno di testare la soluzione.O forse ci sono soluzioni là fuori di cui non ho sentito parlare (non l'ho schivato / cercato su Google).
Ho appena chiarito nella domanda che apt-get è installato in un refroot personalizzato!I pacchetti di sistema non sono a rischio.Sono d'accordo, non è banale.Allo stesso tempo, non ho trovato né pensato a nessuna vulnerabilità che potrebbe derivare da ciò, quindi volevo chiedere qui nel caso qualcuno avesse una risposta.
Gli utenti dovrebbero quasi certamente creare contenitori invece di fare ... qualunque cosa sia.Cerca soluzioni di container senza root come podman.
Sebbene le risposte negative siano tutte buone e corrette, in linea di principio ciò che OP vuole può essere fatto in modo sicuro, rifiutando qualsiasi cosa tranne la richiesta di un nuovo pacchetto nel set di repository attendibile preesistente.Questo ha ancora minacce come far sì che un demone non sicuro inizi con i privilegi, ma è più vicino a ragionevole che consentire comandi arbitrari `apt-get`.
@MichaelHampton Grazie per il tuo suggerimento.Per chiarire il mio caso d'uso, in realtà stavo chiedendo di consentire agli utenti di utilizzare apt-get in un ambiente Docker.Ogni utente ha il proprio contenitore Docker e, sebbene io voglia assicurarmi che non possano eseguire comandi arbitrari come root, voglio anche consentire loro di installare pacchetti da un repository personalizzato.
@R..GitHubSTOPHELPINGICE Grazie per il tuo suggerimento!Potresti chiarire cosa intendi per "far sì che un demone non sicuro inizi con i privilegi", per favore?
[aptdaemon] (https://launchpad.net/aptdaemon) in combinazione con polkit consente di aggiornare elenchi di pacchetti e pacchetti già esistenti su Debian / Ubuntu senza essere root.
@kzl: A meno che non sia cambiato qualcosa (ammetto che è passato molto tempo da quando ho toccato i dist basati su Debian tranne nei contenitori), i pacchetti che forniscono i daemon forniscono file init (servizio systemd o attivazione dbus o qualsiasi altra cosa) che li fanno eseguire automaticamente.Quindi, se puoi installarne uno oscuro spazzatura, puoi usarlo come superficie di attacco;se funziona come root questo può farti diventare root.
Anche se riesci a chiudere tutti i problemi relativi ad apt, devi comunque fare lo stesso per dpkg.E per le persone che impostano un percorso che punta a un collegamento simbolico a una shell.
@R..GitHubSTOPHELPINGICE Ciò che OP vuole può essere fatto sia in modo sicuro che semplice utilizzando nix.nix è un gestore di pacchetti che può funzionare accanto ad apt-get.È interessante come nix sia costruito in modo tale che non ci siano problemi di sicurezza consentendo a tutti gli utenti un accesso illimitato per eseguire nix.È facile installare nix su ubuntu https://nixos.org/download.html
Cinque risposte:
Cyclic3
2020-06-12 20:48:42 UTC
view on stackexchange narkive permalink 
  apt-get update -o APT :: Update :: Pre-Invoke :: = / bin / sh

Da GTFOBins

Questo ti dà una shell di root sul sistema. Nessuna creazione di pacchetti e aggiunta di falsi repo; questo darà all'utente che esegue questo comando un accesso facile e semplice a root.

Quindi, in risposta alla tua domanda, stai effettivamente dando root a ogni utente che ha accesso a questo binario. Se sei disposto a farlo, potresti anche dare loro l'accesso sudo o la password di root.

Questa dovrebbe davvero essere una risposta accettata, IMO;è una soluzione molto più elegante che risponde più chiaramente alla domanda "cosa può fare un utente con` apt`. Non hai nemmeno bisogno di un elenco di fonti, un file di pacchetto, un accesso a Internet o qualsiasi altra cosa ... è solo istantaneamenteti cade in un guscio.
@CBHacking L'ho cambiato in risposta accettata secondo il tuo suggerimento - grazie.Questa è probabilmente la risposta a cui la maggior parte delle persone sarebbe interessata, sebbene non affronti come mitigare questo rischio, come fa la risposta di Arminius di seguito.https://security.stackexchange.com/a/233162/236489
@CBHacking Grazie mille!Il tuo exploit è più applicabile nel mondo reale in base alla mia esperienza: ho visto alcuni pannelli di gestione che consentono agli utenti di modificare i repository e installare pacchetti, ma non espongono il comando "apt-get" stesso.
Fornire loro una shell `root` (o l'accesso di sistema a` apt-get`) è la cosa più stupida che si possa fare.Quando questa è una classe o un ambiente simile, stai certo che almeno un ragazzo è in grado di usarlo.Qual è esattamente il punto di avere un sistema di sicurezza, solo per minare la sua autorità?Se segui uno di questi due modi, stai certo che gli studenti disturbati potrebbero capirlo come: la sfida è iniziata.Una tale configurazione dovrebbe essere conservata meglio in un segmento di rete isolato.
CBHacking
2020-06-12 10:25:18 UTC
view on stackexchange narkive permalink

Dici che stai usando un "repository apt personalizzato" ma non c'è modo di imporlo. Qualsiasi utente che può invocare apt può specificare il proprio elenco di sorgenti, ad esempio apt install root-backdoor -o Dir :: Etc :: Sourcelist = ~ / apt / my-own-sources. elenco . Questo può essere fatto anche per tutte le altre impostazioni di configurazione, il che significa che puoi anche fare in modo che apt sovrascriva file arbitrari con il contenuto che scegli (ad esempio impostando la directory della cache per i pacchetti recuperati).

I pacchetti possono (e spesso) eseguire comandi arbitrari durante l'installazione. Dal momento che l'attaccante può controllare l'elenco delle fonti, può creare pacchetti dannosi che forniscono agli utenti non privilegiati una backdoor privilegiata, o semplicemente eseguire (come root) qualsiasi comando desideri dall'attaccante come parte del processo di "installazione".

apt non è assolutamente un programma sicuro per consentire alle persone di eseguire (con privilegi di root) se si desidera impedire loro di eseguire codice arbitrario con privilegi di root.

EDIT: Voglio chiamare attenzione a questa risposta come un modo molto più pulito per ottenere l'esecuzione arbitraria (come root) da apt .

Grazie per la risposta!Apprezzo la tua intuizione.Impedire agli utenti di specificare i propri elenchi di sorgenti (ad es. Creando un wrapper che chiama specificamente `apt-get install - ` con privilegi di root) sarebbe sufficiente per impedire agli utenti di installare pacchetti arbitrari (e quindi impedire l'esecuzione di codice arbitrario come root)?
@kzl: Non è necessario "creare un wrapper", `sudoers (5)` supporta già questo genere di cose in modo nativo.Tuttavia, non posso raccomandarlo perché `apt-get` consente all'utente di specificare la versione di un pacchetto, quindi un attaccante potrebbe eseguire il downgrade di un pacchetto per abilitare una vulnerabilità di sicurezza.
Si noti che a partire da apt ~ 1.2 è possibile installare i pacchetti direttamente senza fare riferimento a un repository, utilizzando `. /` Per puntare a un file deb.
@Kevin Grazie per la risposta.I vincoli che ho elencato sopra erano 1) nessun sudo 2) refroot personalizzato (apt-get non di sistema) e 3) repository apt curato personalizzato.La risposta di Armenius di seguito, suggerendo una whitelist, risponde a questa domanda.https://security.stackexchange.com/a/233162/236489
Arminius
2020-06-12 21:45:59 UTC
view on stackexchange narkive permalink

Impedire agli utenti di specificare i propri elenchi di sorgenti (ad es. creando un wrapper che richiami specificamente apt-get install - <packages> con privilegi di root) sarebbe sufficiente per impedire agli utenti di installare pacchetti arbitrari (e quindi impedire l'esecuzione di codice arbitrario come root)?

No, apt-get può anche prelevare pacchetti dai percorsi. Un utente malintenzionato potrebbe creare un pacchetto .deb dannoso che patch / etc / <something> per l'accesso root al momento dell'installazione tramite ad es. apt-get install - /path/to/foo.deb.

Potresti riuscire a farlo funzionare in modo sicuro se il tuo script wrapper personalizzato accetta solo ciò che è in una whitelist di nomi dei pacchetti e, se puoi garantire che i pacchetti vengono prelevati solo dal tuo elenco delle fonti e non possono mai essere forniti tramite configurazioni personalizzate, variabili di ambiente, ecc.

Grazie, anche questo è molto utile per me.Vorrei poter accettare più risposte.
Pedro
2020-06-12 19:20:30 UTC
view on stackexchange narkive permalink
  1. Quali sono le potenziali vulnerabilità del consentire a utenti non root di eseguire apt-get?

Compromissione completa del sistema; Escalation persistente dei privilegi da parte dell'utente autorizzato a eseguire apt-get a root.

  1. Il mio obiettivo è consentire alle persone di installare / rimuovere / aggiornare i pacchetti, dato che apt -get vive in un refroot personalizzato non di sistema e si installa da un repository apt personalizzato. Esistono modi più sicuri per consentire agli utenti non root di eseguire apt-get su un sistema senza sudo?

Come spiegato qui, non puoi garantire questo.

Ovviamente si può garantire questo, pur non minando il sistema di sicurezza.
Martin Zeitler
2020-06-15 19:17:50 UTC
view on stackexchange narkive permalink

In realtà sono fortemente in disaccordo con le risposte finora, ecco perché ho aggiunto un'altra prospettiva. Il mio approccio alla soluzione è più o meno basato su uno dei commenti di @ Cyclic3, ma modificato come richiesto.

Il vettore di attacco effettivo:

Quando esiste già una root shell, perché fornire il payload dal gestore dei pacchetti? apt-get non è il problema principale (in quanto non è essenziale per installare software), ma lo è l'approvvigionamento di software inappropriato da parte di utenti non autorizzati, che dovrebbe richiedere meglio l'installazione dei pacchetti per loro. Consentire loro di navigare in Internet con un account root sarebbe all'incirca la stessa idiozia, se guardato da una prospettiva di sicurezza.

Nota a margine, indipendente da apt -get , potrebbero sempre wget un exploit 0-day, che esegue l'escalation dei privilegi. Ciò richiederebbe la prevenzione delle destinazioni in white list sul firewall, il che non diverte gli utenti in generale, perché interrompe tutto il loro utilizzo casuale di Internet (che può includere anche la ricerca web correlata al lavoro). Questo aspetto viene spesso completamente ignorato.

Una semplice soluzione self-service:

Dal momento che nessuno vuole giocare il servo del server ... perché non scrivere una semplice interfaccia utente web , che consente loro di selezionare i pacchetti e quindi di fornirli alla macchina da cui hanno richiesto? Quindi basta ssh ed eseguire apt-get . Questo è un metodo per la lista bianca (conosco solo yum in dettaglio, che supporta la lista nera ma non la lista bianca). In generale, questo è un modo molto semplice per garantire quasi zero rischi, poiché la shell root & apt-get install viene tenuta fuori dalla loro portata. Quando si attiva questo come lavoro batch dal crontab root (assumendo che le chiavi SSH root corrispondano su tutte le macchine), non è nemmeno necessario cambiare l'account utente per farlo . Basta premere una notifica quando hai finito e saranno stupiti.

Come dicevo, quando si lavora nel supporto agli utenti: ciò che non possono fare clic, non possono sbagliare.



ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...