Che danno può fare un programma C/asm su Linux quando viene eseguito da un utente non privilegiato?

Question

Ho pensato a uno scenario in cui si consente agli utenti (può essere chiunque, possibilmente con cattive intenzioni) di inviare il codice che viene eseguito su un PC Linux (chiamiamolo nodo di riferimento). L'obiettivo è creare una sorta di ambiente di benchmark automatico per le routine a thread singolo. Diciamo che un sito web pubblica del codice su un proxy. Questo proxy passa questo codice al nodo di riferimento e il nodo di riferimento ha solo una connessione Ethernet al proxy, non a Internet stesso.

Se si consente a qualsiasi utente di inviare un codice C/asm sul nodo di riferimento, quali saranno le sfide di sicurezza? I seguenti ipotesi:

• Il programma viene eseguito come utente senza privilegi
• Il proxy avrà la possibilità di uccidere il processo sul nodo di riferimento (prendere lo scenario di un ciclo infinito per esempio)
• la delega è in grado di riavviare il nodo di riferimento (se le risposte ...)

Quindi, è in pratica possibile che questo programma spaziale utente può effettuare l'arresto del sistema operativo, o di rendere la macchina disponibile al proxy ? Con assembly il programmatore può fare praticamente quello che vuole (manipolare il puntatore dello stack per esempio), e mi chiedo quanto Linux restrittivo/robusto sia in questo senso. So anche della possibilità che i processi richiedano aree di memoria condivisa con altri processi (shm), che potrebbero anche avere un ruolo in questo caso?

Qualsiasi letteratura o articoli su questo argomento sono i benvenuti.

Le soluzioni sandbox potrebbero anche essere interessanti, ma è importante che la CPU esegua il 100% di ciò che è in grado di fare durante il benchmark (almeno sul core del benchmark in esecuzione).

Answer 1

Quindi, è in pratica possibile che questo programma spaziale dell'utente possa arrestare il sistema operativo o rendere la macchina non disponibile al proxy?

Sì, tali tecniche come la deposizione delle uova un numero eccessivo di processi, allocazione di memoria eccessiva (che causa l'utilizzo file di swap), o di fare la fila un sacco di disco I/O farà la macchina non risponde in modo che il processo di supervisore non sarà correre in modo tempestivo.

Se il codice supervisore termina con lo swapping sul disco, anche se ha priorità alta, non verrà eseguito fino a quando il disco non sarà disponibile, il che può essere un ritardo molto lungo a causa dei tempi di ricerca.

Linux ha ulimit che può proteggere contro alcuni di questi, vedere Limit the memory and cpu available for a user in Linux E anche l'attività di rete dannosa può essere bloccata. È anche possibile disabilitare lo scambio e il programma chroot in un supporto tmpfs. Ma alcuni guai saranno ancora possibili.

Answer 2

Solo una rapida lista da cima alla testa.In sostanza, se non vi fidate gli utenti almeno un po ', ci si trova in difficoltà profonda:

• manipolazione Filesystem: eliminare o sovrascrivere i file appartenenti all'utente il processo viene eseguito come
• snooping tutti i tipi di dati trovato sul sistema (file, a volte il traffico di rete dello stesso utente)
• uccidere altri processi dell'utente
• il consumo di memoria fino OOM Killer inizia uccidere i processi casuali o (se si dispone di swap abilitato) fino a quando la macchina rallenta a passo d'uomo
• Generazione di un sacco di I/O da slo w il sistema
• Esecuzione exploit a piacimento (si è vicino a certi di avere un po 'di vulnerabilità senza patch privilegio escalation da qualche parte)
• vulnerabilità Sfruttare in qualsiasi software l'utente è in grado di eseguire
• Hosting una rete DDoS o la pornografia infantile file server sulla vostra macchina
• Utilizzo dell'apparecchio come proxy per l'avvio di attacchi contro i server della CIA e dell'FBI
• il cielo è il limite ...

non suona come un go od idea.

Answer 3

Un gruppo di programmi può esercitare una pressione di memoria causando la mancata risposta della macchina (specialmente quando si avvia lo scambio su disco). Esempio codice: perl -e '$_.="x"x1000000 while fork'

Answer 4

Quindi, è in pratica possibile che questo programma dello spazio utente possa arrestare il sistema operativo o rendere la macchina non disponibile al proxy?

Bene, in teoria si dovrebbe avere difficoltà a rendere il sistema operativo in crash. Tuttavia, ci sono molte segnalazioni di bug che dicono che è più possibile nella pratica di quanto vorremmo.

Senza precauzioni speciali, d'altra parte, sarà abbastanza facile ottenere il rifiuto del servizio. Immagina un programma utente che non abbia fatto altro che inondare il proxy con i pacchetti; questo, da solo, potrebbe, se non raggiungere la negazione diretta del servizio, rendere le cose imbarazzanti lentamente.

Con il montaggio del programmatore può fare praticamente tutto quello che vuole (manipolare stack pointer per esempio), e mi chiedo come restrittiva/robusto Linux è in questo senso.

Tuttavia, siamo molto meglio di così. Se tutto ciò di cui avevi bisogno per l'escalation dei privilegi era la sicurezza del "pasticcio con il puntatore dello stack", un campo sarebbe uno scherzo totale. Il kernel è destinato a per essere scritto in modo che nessun programma, non importa cosa, possa causare il crash del kernel. Come notato, è imperfetto.

La morale della storia è che non si vuole davvero eseguire codice non affidabile su un computer a cui tieni. La risposta stock qui sarebbe una VM controllata: avviare una macchina virtuale, eseguire il codice non attendibile sulla macchina virtuale, e quindi dopo il completamento o il timeout far saltare la macchina virtuale. In questo modo il danno persistente è impossibile. Per quanto riguarda altri abusi, il tuo proxy impedirà loro di ospitare servizi Internet squallidi, il che è positivo. A seconda della situazione della tua macchina virtuale, potrebbero esserci validi strumenti per limitare il consumo della CPU e l'utilizzo della rete, il che contribuirà ad eliminare altre possibilità di negazione del servizio.

Si dice che è necessario che la CPU funzioni a pieno regime. La virtualizzazione dell'hardware è piuttosto buona e le prestazioni dovrebbero riflettere in modo ragionevole quello che sarebbe su un sistema reale.

Niente di sopra è specifico di Linux, a proposito; dovrebbe essere vero per tutti i sistemi operativi credibili per tutti gli usi.

edit: Se siete veramente insistente a correre direttamente su hardware, quindi:

• avvio da un dispositivo di sola lettura (LiveCD o disco rigido writeblocked)
• non hanno supporto scrivibile nel sistema
• Aggiungere un server di spegnimento che può forzatamente ripristinare la macchina su richiesta del proxy, in caso di rifiuto del servizio; esistono soluzioni commerciali per questo

Questo essenzialmente ti dà le caratteristiche della soluzione VM, ma su hardware.

Answer 5

Se il codice è in esecuzione su un account limitato su una macchina configurata correttamente, dovrebbe resistere a molti tipi di attacco di base (accidentale o dannoso).

Il fatto che il programmatore possa utilizzare l'assembly è irrilevante: gli attacchi possono essere codificati in molte lingue diverse, compilate o meno.

Il problema principale sono problemi di sicurezza sconosciuti o vulnerabilità di 0 giorni. Consentire a qualsiasi programma non autorizzato da eseguire è un rischio e se qualcuno riesce a sfruttare un problema che consente l'elevazione dei privilegi, sei fregato.

Le sandbox sono generalmente consigliate perché limitano sia l'azione che l'applicazione può eseguire e (se progettata correttamente) riducono al minimo il danno causato da comportamenti anomali.