Domanda:
Qual è il possibile impatto del bug di dirtyc0w noto anche come "Dirty COW"?
d33tah
2016-10-21 15:42:47 UTC
view on stackexchange narkive permalink

Ho sentito parlare di Dirty COW ma non sono riuscito a trovare alcun commento decente sulla portata del bug. Sembra che l'exploit possa sovrascrivere qualsiasi file non scrivibile, il che mi fa supporre che la root locale sia possibile tramite la sostituzione di programmi SUID. È giusto? Cos'altro sappiamo di Dirty COW? È possibile sfruttarlo da remoto? Ha effetto su Android?

Sul sito è scritto "Dirty COW" (non dirty cow o dirtyc0w), cow è un riferimento a CoW, che significa copia su scrittura.
@LéoLam: È sporco qui dentro: https://github.com/dirtycow/dirtycow.github.io/blob/master/dirtyc0w.c
Questo è il nome del PoC, proprio come [c'è un pokemon.c, un cowroot] (https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs).Se guardi la [descrizione repo] (https://github.com/dirtycow/dirtycow.github.io), dice proprio lì che è "Dirty COW".
Vedi [la segnalazione di bug] (https://bugzilla.redhat.com/show_bug.cgi?id=1384344#) per maggiori dettagli.
Sette risposte:
Volker
2016-10-21 15:50:46 UTC
view on stackexchange narkive permalink

Non può essere sfruttato da remoto senza un'altra vulnerabilità. Devi essere in grado di eseguire già i comandi sul sistema.

Un classico esempio sarebbe una shell web. Supponiamo che il server stia eseguendo un'applicazione Web che presenta una vulnerabilità che consente di caricare una shell Web o eseguire in altro modo comandi di sistema. Questi comandi verranno in genere eseguiti come utente con privilegi ridotti, a volte chiamato www-data o simile.

Con questo exploit potresti sovrascrivere il file / etc / passwd per fornire a www-data l'UID 0. Ora www-data ha i privilegi di root.

Tuttavia, ho provato alcune cose e la modifica di / etc / passwd non ha funzionato sul mio sistema. Puoi impostare l'UID di un utente su 0, ma poi dovresti eseguire nuovamente l'accesso, che non è davvero un'opzione se hai solo una shell web. Il miglior exploit armato che ho visto finora sovrascrive / usr / bin / passwd , il binario che viene utilizzato per cambiare la password di un utente e ha il bit SUID impostato, con shellcode che esegue / bin / bash . Alcune limitazioni dell'exploit sembrano essere: puoi solo sovrascrivere i byte esistenti, non aggiungere nulla a un file. Inoltre, non ero in grado di scrivere più di esattamente 4KB su un file.

Per quanto riguarda Android, ho cercato nel repository git Android 4.4 la funzione in questione ( follow_page_pte ) e non ha ricevuto risultati, quindi voglio dire "no", ma non citarmi su questo.

Modifica: Android è interessato - vedi questa prova di concetto.

Il repository git di Android non dovrebbe necessariamente chiamare `follow_page_pte` per essere vulnerabile.È possibile che le app Android includano codice C nativo, quindi in linea di principio potrebbe includere codice C simile all'exploit.In pratica, il modello sandboxing di Android può disinnescare alcuni attacchi.
https://github.com/timwr/CVE-2016-5195
Nota: anche la vulnerabilità Shellshock richiedeva di "poter eseguire comandi sul sistema", ma a causa del modo in cui funzionavano alcuni software per server web, consentiva comunque l'esecuzione di codice in modalità remota.Non sarei sorpreso se avessimo una situazione simile qui.
Riscrivere `/ etc / passwd` e quindi causare il riavvio del sistema (riempire tmp?) O in qualche modo causare l'accesso a un nuovo account` www-data`?(riempi il tuo tmp locale? Fai un'altra richiesta http? Molte richieste http?)
@Nzall: Shellshock è stato un exploit completamente diverso.Era più un exploit di iniezione, quindi se una variabile di ambiente conteneva un comando, potevi "uscire" dall'ambiente e ottenere l'accesso a una shell locale.Quindi shellshock PLUS dirtycow = ESTREMAMENTE TOSSICO.Quindi, fondamentalmente, shellshock è un exploit remoto che fornisce l'accesso utente locale e dirtycow è un exploit che dà accesso root a qualcuno con accesso utente locale.Inutile dire che la combinazione è molto pericolosa.
GAD3R
2016-10-21 17:18:06 UTC
view on stackexchange narkive permalink

La vulnerabilità della mucca sporca è una vulnerabilità di escalation di privilegi nelle versioni del kernel Linux 2.6.22 e successive; esiste dal 2007 ed è stato corretto il 18 ottobre 2016.

Qual è il possibile impatto del bug di dirtyc0w?

Un locale non privilegiato l'utente potrebbe utilizzare questo difetto per ottenere l'accesso in scrittura a mappature di memoria altrimenti di sola lettura e quindi aumentare i propri privilegi sul sistema.

Questo difetto consente a un utente malintenzionato con un account di sistema locale di modificare i binari su disco, bypassando i meccanismi di autorizzazione standard che impedirebbero la modifica senza un insieme di autorizzazioni appropriato.

È possibile sfruttarlo da remoto?

non è direttamente sfruttabile da remoto; hai prima bisogno di un altro difetto per darti accesso remoto al sistema , come indicato a @IMSoP nel suo commento,

è valutato come importante :

Impatto importante

Questa valutazione è attribuita a difetti che possono facilmente compromettere la riservatezza , integrità o disponibilità di risorse. Questi sono i tipi di vulnerabilità che consentono agli utenti locali di ottenere privilegi, consentono agli utenti remoti non autenticati di visualizzare le risorse che altrimenti dovrebbero essere protette dall'autenticazione, consentono agli utenti remoti autenticati di eseguire codice arbitrario o consentono agli utenti remoti di causare un Denial of Service.

Ha effetto su Android?

Sì, perché Android utilizza il kernel Linux.

Sono interessato ?

Se hai un dispositivo che esegue un kernel Linux superiore a 2.6.22, ci sono buone probabilità che tu sia vulnerabile. Lo stesso vale per tutte le versioni di Android, indipendentemente dal fatto che provengano da Samsung, Google, Cyanogen, MIUI o altri fornitori perché non hanno ancora rilasciato aggiornamenti di sicurezza.

Per sfruttare questa vulnerabilità, l'attaccante deve eseguire il codice nel dispositivo interessato, cosa che nel caso di Android può essere eseguita tramite Android Debug Bridge (ADB) su USB o installando un'app che utilizza l'exploit.

Un ricercatore di sicurezza descrive in questo blog come sfruttare il difetto da remoto

Gli exploit possono essere utilizzati contro i provider di hosting Web che forniscono l'accesso alla shell, in modo che un cliente possa attaccare altri clienti o persino amministratori di servizi. Gli exploit di escalation dei privilegi possono anche essere combinati con attacchi che prendono di mira altre vulnerabilità. Un punto debole di SQL injection in un sito Web, ad esempio, spesso consente agli aggressori di eseguire codice dannoso solo come utente non attendibile. In combinazione con un exploit di escalation, tuttavia, tali attacchi possono spesso raggiungere lo stato di root molto ambito.

Informazioni utili possono essere trovate qui:

  1. Come determinare se il tuo sistema è vulnerabile?
  2. Qual è l'elenco delle distribuzioni Linux interessate?
  3. Come posso risolverlo?
Dici che è possibile sfruttarlo da remoto.La risposta più votata dice che non è possibile sfruttarlo da remoto.Non ho idea di chi abbia ragione, ho solo pensato di far notare la differenza.
@Anders aggiorno la mia risposta
Penso che sia una confusione terminologica: dalla tua descrizione, non è * direttamente * sfruttabile da remoto;devi prima * un altro * difetto per darti l'accesso remoto al sistema.Una volta che hai la possibilità di eseguire comandi arbitrari, questi comandi sono effettivamente "locali" per il sistema.Ad esempio, i comandi eseguiti su una connessione SSH stabilita non sono generalmente classificati come "remoti" in questo senso, perché c'è poca distinzione significativa tra loro e comandi digitati su un terminale che è fisicamente collegato al sistema.
-1 il bug NON è sfruttabile da remoto.
** Tutto ** è "sfruttabile in remoto" se si assume un difetto secondario che ti dà accesso locale ... Per sfruttabile in remoto si intende generalmente: il difetto può essere attivato * senza * tale accesso locale a una shell web o simile.
Penso che tu stia interpretando male la definizione.Le vulnerabilità sono etichettate come "importanti" quando soddisfano almeno uno dei criteri elencati: in questo caso, consente agli utenti locali di ottenere privilegi o può consentire agli utenti remoti autenticati di farlo.Se l'exploit fosse noto come sfruttabile direttamente da utenti remoti non autenticati, sarebbe invece contrassegnato come "critico".(N.B. Non sto parlando ufficialmente per RH qui)
La tua risposta sullo sfruttamento di Android è scarsamente studiata.Android UTILIZZA il kernel Linux, tuttavia, ciò non significa che la vulnerabilità possa essere sfruttata in Android.Inoltre, la risposta sullo sfruttamento remoto è fuorviante, nella migliore delle ipotesi.
kaidentity
2016-10-21 16:59:07 UTC
view on stackexchange narkive permalink

CVE-2016-5195 è un cosiddetto exploit di escalation dei privilegi. Ti consente di elevare il livello di privilegio da un normale utente Linux a root. Ma gli exploit di escalation dei privilegi sono solitamente exploit locali (il che significa che vengono eseguiti localmente su una macchina), il che significa che devi già essere loggato al sistema operativo.

L'exploit pubblico che stavo controllando permette di scrivere file di proprietà di root che sono di sola lettura o non sono affatto accessibili agli utenti non root. Ciò consente di sovrascrivere i file amministrativi. Puoi sfruttare questo per diventare root. Per esempio. puoi aggiungere una riga

 hack :: 0: 0: ,,,: / home / kai: / bin / bash 

a / etc / passwd . Ciò aggiungerebbe un utente root senza password alla casella.

sigalor
2016-10-21 22:44:46 UTC
view on stackexchange narkive permalink

Almeno influisce su Android 5.0.1 (versione kernel 3.10.54+). Ho appena provato questo codice su un dispositivo utilizzando Termux e la modifica di un file di proprietà di root funziona perfettamente. Mi piace, perché non è disponibile alcun root per quel dispositivo.

D'altra parte, mi sorprende, perché Android usa SELinux e pensavo che SELinux avrebbe impedito di scrivere su / proc / self / mem .

In realtà, ho appena provato a scrivere su un file di proprietà di un utente chiamato sdcard , che possiede tutti i file sul Scheda SD. Termux stesso (normalmente) non è autorizzato a scrivere sulla scheda SD. Quando provo dirtyc0w su un file di questo tipo, il dispositivo si blocca e si riavvia automaticamente dopo pochi secondi. Anche adb logcat non restituisce nulla durante questo blocco. Non sono sicuro di cosa stia succedendo lì.

Damon
2016-10-22 16:26:07 UTC
view on stackexchange narkive permalink

Quanto è spaventoso?

In linea di principio, un'escalation dei privilegi è piuttosto spaventosa poiché rende più o meno privi di significato tutti i controlli di accesso. In pratica, si spera che importi poco. Per prima cosa devi avere un accesso utente limitato.

Per i server, significherà che i sistemi server non ben mantenuti che sono in qualche modo sfruttabili ora saranno banalmente rootabili. Tuttavia, non è che questo sia il primo exploit di escalation di privilegi nella storia.
Per sistemi ben mantenuti, l'impatto dovrebbe essere prossimo allo zero (non avrebbero dovuto essere sfruttati fino ad ora e dovrebbero essere aggiornati a questo punto).

Per tutti i telefoni Android precedenti alla 7.0, purtroppo significa che esiste un exploit che potrebbe consentire a un'app dannosa di prendere il controllo del telefono. Questo è un pensiero estremamente spaventoso, ma non sembra essere accaduto finora, altrimenti ci sarebbero stati panico, caos e omicidi in tutto il pianeta. Gli aggiornamenti automatici risolveranno rapidamente questo problema e nel frattempo non installate nuove app (le app già presenti sul telefono da molti mesi ovviamente non hanno dirottato il telefono, quindi sono probabilmente innocuo) ... problema risolto.
Ora c'è anche un altro modo per eseguire il jailbreak del tuo telefono (almeno fino al prossimo aggiornamento di sistema).

Significa anche che qualcuno con accesso fisico al tuo computer e un account utente può eseguire il root del tuo sistema ... ma potrebbero anche semplicemente afferrare il tuo computer e portarlo via, o rubare il disco rigido, o usare Firewire / Thunderbolt che sono fondamentalmente l'accesso diretto alla memoria tramite cavo, avviare da un CDROM, o ... 200 altre cose, quindi non penso che questo sia un grosso problema nel complesso. È solo un'altra cosa che qualcuno può fare.

Ancora più importante

Poiché questo è il secondo incidente di lunga data e di alto profilo (dopo CVE-2008-0166) in cui un problema di sicurezza probabilmente serio è stato creato da un manutentore per conto di un problema di "cosa me ne frega?" , spero che il maggiore impatto che ciò avrà riaprirà una discussione sul processo di progettazione.

Il problema più grande di questa vulnerabilità è, a mio parere, che è stato identificato e risolto nel 2005 (quando era solo un problema teorico con una bassa probabilità di verificarsi), ma poi è stato ripristinato perché causava un problema su alcuni IBM serie mainframe dei primi anni '90 di cui poche persone hanno mai sentito parlare. Il che, francamente, al 99% di tutti gli utenti Linux non potrebbe importare di meno, e che avrebbe potuto essere fatto da una patch / fix dipendente dal sistema solo per s / 390. Ma ciò non è accaduto e il problema è scomparso nell'oblio fino a 11 anni dopo.

Questo è molto simile all'introduzione del 2008-0166 in cui qualcuno ha modificato il codice (che ha funzionato correttamente) senza comprenderne le implicazioni , solo perché Valgrind ha mostrato un avviso.

Forse, questo aiuterà a creare maggiore consapevolezza dell'importanza che i manutentori capiscano quali sono le esatte implicazioni di una modifica al codice per la stragrande maggioranza degli utenti, e un la valutazione (con revisione tra pari?) sulle modifiche al codice può evolversi. Si spera che sia così.

"Gli aggiornamenti automatici elimineranno rapidamente questo problema" - in qualche modo non ti credo.Quale percentuale di telefoni riceve effettivamente aggiornamenti automatici?
@d33tah: Ovviamente non lo so (come potrei).Ma vedi come i telefoni sono quasi più "di proprietà del produttore" che di proprietà _del loro proprietario_, quasi al 100%?Il mio telefono (che è un iPhone, non Android, ma comunque) sembra aggiornarsi automaticamente almeno una volta ogni due settimane (_ si sente come_ quasi ogni giorno), e l'opzione per disattivarla, se ce n'è una, è cosìben nascosto che non so nemmeno dove trovarlo.Certo, posso _delay_ l'aggiornamento, ma mi tormenterà con "installa ora" ogni volta che premo il pulsante di riattivazione.Sebbene sia fastidioso, tutto sommato, considero questo frequente aggiornamento automatico una buona funzionalità.
@Damon Android 5.0 è stato rilasciato due anni fa, ma il 50% circa dei telefoni Android esegue ancora 4.4 o versioni precedenti.Vedi https://developer.android.com/about/dashboards/.
@Damon Purtroppo, la situazione dell'aggiornamento di Android è molto, molto diversa dalla situazione dell'aggiornamento di iOS.Con l'eccezione di pochi (relativi) importanti produttori che hanno ora iniziato a fornire assistenza su alcuni modelli di telefono disponibili su alcuni importanti operatori in modo tempestivo, i proprietari di telefoni Android realizzati da grandi OEM possono ancora generalmente aspettarsi (a) aggiornamenti che effettivamentearrivare ai loro telefoni settimane o mesi dopo che Google li ha rilasciati per la prima volta agli OEM o (b) nessun aggiornamento.
katrix
2016-10-21 20:47:29 UTC
view on stackexchange narkive permalink

The Guardian sembra dire SÌ, ma sembra che dipenda dalla variante di Android in questione:

Ciò vale anche per Android: il il sistema operativo mobile è interessato. Sebbene i dispositivi Android di fascia alta, come Galaxy S7 e Pixel, ricevano aggiornamenti di sicurezza regolari, la stragrande maggioranza dei dispositivi Android venduti riceve pochi, se del caso, aggiornamenti post-vendita.

Google ha rifiutato di commentare, ma ha confermato che Android è una delle distribuzioni Linux interessate. L'azienda ha pubblicato un avviso di sicurezza per i partner per avvisare i partner Android, uno dei passaggi per quei partner che rilasciano una patch.

Steve Sether
2016-10-21 23:46:51 UTC
view on stackexchange narkive permalink

Il bug consente a un utente malintenzionato che può eseguire codice arbitrario di scrivere in una memoria di "sola lettura". Le cache Linux spesso utilizzavano file nella memoria di sola lettura. Come hai intuito, questo ti consente di fare cose come cambiare il contenuto di un file di root setuid per eseguire codice arbitrario, come una shell, come root.

Il bug in sé e per sé non è sfruttabile da remoto poiché richiede che l'aggressore esegua uno specifico eseguibile creato dall'aggressore. In genere, quando usiamo le parole "sfruttabile in remoto", non è richiesta la capacità di eseguire codice arbitrario.

Tuttavia, ci sono situazioni in cui un utente malintenzionato può già eseguire codice arbitrario in base alla progettazione che non sono così ovvie come accesso ssh. Questo potrebbe essere il motivo di un po 'di confusione, poiché potrebbe non essere sempre ovvio che un utente malintenzionato abbia i privilegi di esecuzione del codice. Potenzialmente, gli ambienti di compilazione automatizzata condivisi possono essere vulnerabili a questo tipo di exploit, poiché spesso consentono allo sviluppatore di eseguire codice arbitrario. Un utente malintenzionato in questo scenario potrebbe potenzialmente ottenere privilegi di root.

Non mi sento qualificato per rispondere se questo bug è sfruttabile in Android. Se è sfruttabile su Android, l'ambito sarebbe molto probabilmente limitato al proprietario del telefono che è in grado di "eseguire il root" del dispositivo, piuttosto che a un utente malintenzionato remoto che ottiene il controllo del telefono.

significherebbe semplicemente che la sandbox dell'applicazione non funziona e qualsiasi applicazione può utilizzare il dispositivo indipendentemente dall'approvazione dell'utente, come in MS-DOS


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