Ho sentito parlare di Dirty COW ma non sono riuscito a trovare alcuna descrizione decente sulla portata del bug. Sembra che l'exploit possa sovrascrivere qualsiasi file non scrivibile, il che mi fa pensare che la root locale sia possibile tramite la sostituzione dei programmi SUID. È giusto? Cos'altro sappiamo di Dirty COW? È possibile sfruttarlo da remoto? Ha effetto su Android?
Non può essere sfruttato da remoto senza un'altra vulnerabilità. Devi essere in grado di eseguire comandi sul sistema già.
Un esempio classico 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 altrimenti eseguire comandi di sistema. Questi comandi vengono generalmente eseguiti come utente con privilegi ridotti, talvolta chiamati www-data o simili.
Con questo exploit potresti sovrascrivere il file /etc/passwd per dare 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. È possibile impostare l'UID di un utente su 0, ma in tal caso è necessario effettuare nuovamente l'accesso, che non è realmente un'opzione se si dispone solo di una shell Web. Il miglior exploit di armi che ho visto finora sovrascrive /usr/bin/passwd , il binario che viene usato 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 in un file.
Per quanto riguarda Android, ho cercato il repo Git di Android 4.4 per la funzione in domanda ( follow_page_pte ) e non ha ottenuto risultati, quindi voglio dire "no", ma non citarmi su questo.
Modifica: Android è interessato - vedi questa bozza di concetto .
La vulnerabilità della dirty cow, è una vulnerabilità di escalation di privilegi nelle versioni del kernel di Linux 2.6.22 e versioni successive; esiste dal 2007 ed è stato risolto il 18 ottobre 2016.
Qual è il possibile impatto del bug di dirtyc0w?
An unprivileged local user could use this flaw to gain write access to otherwise read-only memory mappings and thus increase their privileges on the system.
This flaw allows an attacker with a local system account to modify on-disk binaries, bypassing the standard permission mechanisms that would prevent modification without an appropriate permission set.
È possibile sfruttarlo da remoto?
non è direttamente sfruttabile da remoto; per prima cosa hai bisogno di un altro difetto per darti l'accesso remoto al sistema , come indicato da @IMSoP nel suo commento,
è valutato come un importante bug:
Important impact
This rating is given to flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the types of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow remote users to cause a denial of service.
Ha effetto su Android?
Sì, perché Android utilizza il kernel Linux.
If you have any device running a Linux kernel higher than 2.6.22, there’s a good chance that you are vulnerable. The same goes for all versions of Android whether they come from Samsung, Google, Cyanogen, MIUI, or other vendors because they have not yet issued security updates.
In order to exploit this vulnerability, the attacker needs to run code in the affected device, which in Android’s case can be done via the Android Debug Bridge (ADB) over USB or by installing an app that makes use of the exploit.
Aggiorna
Un ricercatore di sicurezza descrive questo blog su come sfruttare il difetto da remoto
The exploits can be used against Web hosting providers that provide shell access, so that one customer can attack other customers or even service administrators. Privilege-escalation exploits can also be combined with attacks that target other vulnerabilities. A SQL injection weakness in a website, for instance, often allows attackers to run malicious code only as an untrusted user. Combined with an escalation exploit, however, such attacks can often achieve highly coveted root status.
Informazioni utili possono essere trovate qui :
CVE-2016-5195 è un cosiddetto exploit di escalation di privilegi. Ti permette di elevare il livello di privilegio da un normale utente Linux a root. Gli exploit di escalation di privilegi sono in genere exploit locali (il che significa che vengono eseguiti localmente su una casella), il che significa che è già necessario accedere al sistema operativo.
L'exploit pubblico che stavo controllando consente di scrivere file di proprietà di root che sono di sola lettura o non accessibili a tutti gli utenti non root. Ciò consente di sovrascrivere i file amministrativi. Puoi sfruttare questo per diventare root. Per esempio. puoi aggiungere una linea
hack::0:0:,,,:/home/kai:/bin/bash
a /etc/passwd . Ciò aggiungerebbe un utente root senza password alla casella.
Almeno ha effetto 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 in modo impeccabile. Mi piace, perché non esiste una radice disponibile per quel dispositivo.
D'altra parte, mi sorprende, perché Android utilizza SELinux e pensavo che SELinux avrebbe impedito di scrivere in% % co_de.
In realtà, ho appena provato a scrivere su un file di proprietà di un utente chiamato /proc/self/mem , proprietario di tutti i file sulla 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 sdcard non emette nulla durante questo blocco. Non sai cosa sta succedendo lì.
In linea di massima, un'escalation dei privilegi è piuttosto spaventosa dal momento che rende più o meno privo di significato qualsiasi controllo dell'accesso. In pratica, spero che contenga poco. Devi prima avere un accesso limitato agli utenti.
Per i server, significherà che i sistemi di server non ben mantenuti che sono in qualche modo sfruttabili ora saranno banalmente fattibili. Non è come se questo fosse il primo exploit di escalation di privilegi nella storia, però.
Per i sistemi ben mantenuti, l'impatto dovrebbe avvicinarsi a zero (non avrebbero dovuto essere sfruttati finora e dovrebbero essere aggiornati ormai).
Per tutti i telefoni Android precedenti alla 7.0, sfortunatamente 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 che sia successo fino ad ora, o ci sarebbe stato il panico, il caos e l'omicidio in tutto il pianeta. Gli aggiornamenti automatici elimineranno rapidamente questo problema e, nel frattempo, non installano nuove app (le app già presenti sul telefono per molti mesi ovviamente non hanno dirottato il telefono, quindi sono probabilmente innocuo) ... problema risolto.
Ora c'è ancora un altro modo di eseguire il jailbreak del tuo telefono (almeno fino al prossimo aggiornamento del sistema, almeno).
Ovviamente significa anche che qualcuno con accesso fisico al tuo computer e un account utente può effettuare il root del tuo sistema ... ma potrebbero anche prendere il tuo computer e portarlo via, o rubare il disco rigido, o usare Firewire / Thunderbolt che sono fondamentalmente accesso diretto alla memoria via cavo, avvio da un CDROM, o ... 200 altre cose, quindi non penso che questo sia un grosso problema in generale. È solo l'ennesima cosa che qualcuno può fare.
Dato che 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 maintainer per conto di un "cosa mi importa?" problema, spero che il maggiore impatto che questo avrà riaprirà una discussione sul processo di ingegneria.
Il più grande problema di questa vulnerabilità è, a mio avviso, che è stato identificato e risolto nel 2005 (quando si trattava semplicemente di 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. Che, francamente, il 99% di tutti gli utenti Linux non potrebbe importare di meno, e che avrebbe potuto essere fatto da una patch / correzione dipendente dal sistema solo per s / 390. Ma ciò non accadde e il problema svanì 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 avvertimento.
Forse questo aiuterà a creare una maggiore consapevolezza dell'importanza dei manutentori di comprendere quali sono le esatte implicazioni di un cambiamento di codice per la stragrande maggioranza degli utenti, e una valutazione complessiva più critica (con revisione tra pari) sulle modifiche al codice potrebbe evolversi . Spero che sia così.
The Guardian sembra per dire che è un SI, ma sembra che dipenda dalla variante di Android in questione:
That also applies to Android: the mobile operating system is affected. While top-end Android devices, such as the Galaxy S7 and Pixel, receive regular security updates, the vast majority of Android devices sold receive few, if any, post-sale updates.
Google declined to comment, but confirmed that Android is one of the Linux distributions affected. The company has posted a Partner Security Advisory to alert Android partners, one of the steps to those partners then issuing a patch.
Il bug consente a un utente malintenzionato di eseguire codice arbitrario per scrivere in memoria che è "di sola lettura". Le cache di Linux spesso utilizzavano file in memoria di sola lettura. Come hai intuito, questo ti permette di fare cose come cambiare il contenuto di un file di root setuid per eseguire il codice arbitario, come una shell, come root.
L'insetto di per sé non è sfruttabile da remoto poiché richiede che l'attaccante esegua un eseguibile specifico creato dall'attaccante. In genere, quando utilizziamo le parole "da remoto sfruttabili", non è richiesta la possibilità di eseguire codice arbitrario.
Tuttavia, ci sono situazioni in cui un utente malintenzionato può già eseguire codice arbitrario in base alla progettazione che non è ovvio come l'accesso ssh. Questo potrebbe essere il motivo di una parte della confusione, in quanto potrebbe non essere sempre ovvio che un utente malintenzionato abbia i privilegi di esecuzione del codice. Potenzialmente, gli ambienti di build automatizzati condivisi possono essere vulnerabili a questo tipo di exploit, in quanto spesso consentono allo sviluppatore di eseguire codice arbitrario. Un utente malintenzionato in questo scenario potrebbe potenzialmente ottenere i privilegi di root.
Non mi sento qualificato per rispondere se questo bug è sfruttabile in Android. Se è sfruttabile su Android, molto probabilmente l'ambito sarà limitato al fatto che il proprietario del telefono sia in grado di "rootare" il dispositivo, piuttosto che un utente malintenzionato remoto che ottiene il controllo del telefono.
Leggi altre domande sui tag linux kernel exploit known-vulnerabilities dirty-cow