La prima cosa importante è pensare sul significato di questo buco di sicurezza. Questa è una escalation di privilegi locali : se un utente malintenzionato può ottenere l'esecuzione di codice di sua scelta sulla macchina, con privilegi "normali", quindi quell'attaccante può utilizzare questo buco per ottenere privilegi più estesi su quella macchina.
In generale, per un sistema desktop, quando gli attaccanti possono eseguire il proprio codice sul proprio computer, hanno già vinto. Sui sistemi desktop, le tue azioni, come "utente normale", vengono tutte eseguite come processo in esecuzione, dal punto di vista del kernel, con i privilegi collegati al tuo account utente. Se un utente malintenzionato riesce a eseguire il proprio codice, lo farà attraverso la sovversione di una delle sue applicazioni o facendo involontariamente un salvaschermo apparentemente onesto o qualcosa del genere. I privilegi allegati al tuo account sono sufficienti per saccheggiare il contenuto di tutti i tuoi file, visualizzare annunci spuri, dirottare le connessioni di rete e generalmente rubare tutta la tua vita. Anche ottenere i privilegi di root sulla macchina non aumenta in modo sostanziale la portata del disastro, anche se potrebbe rendere la vita più facile per l'aggressore.
Inoltre, come "utente normale", già hai modi per ottenere i privilegi di root e li usi regolarmente - ad es. autorizzare un aggiornamento del plugin Flash. Il sistema di aggiornamento ti chiederà la tua password e la userà per richiedere e ottenere i privilegi di root. Un utente malintenzionato che può eseguire codice sotto il tuo nome deve solo imitare un aggiornamento Flash per visualizzare il popup e ottenere i privilegi. In questo senso, la nuova vulnerabilità è irrilevante per un sistema desktop . Corrispondentemente, non c'è fretta nel risolverlo.
I buchi di escalation dei privilegi hanno molto più senso su server condivisi , dove diversi utenti potenzialmente potenzialmente ostili condividono lo stesso hardware e il sistema operativo deve arbitrare tra gli utenti e proteggerli da ciascuno altro. I server condivisi sono un vecchio modello, quando stavamo parlando dei mainframe . Un professionista della sicurezza delle informazioni che ora ha quarant'anni deve essere stato esposto a quel modello mentre era studente, negli anni '80 o '90. A quel tempo, gli studenti di computer usavano tipicamente i terminali in qualche sala computer condivisa e accedevano a uno o pochi server centrali con un sistema operativo simile a Unix. L'escalation dei privilegi era allora un molto richiesto.
Questo si applica raramente al giorno d'oggi. Al momento, nel 2015, quando c'è hardware condiviso, agli utenti sono concesse macchine virtuali, non semplici account di shell. Lì ancora sono luoghi in cui i server sono condivisi nel vecchio modo, ma sono una specie in via di estinzione. Se le macchine OS X sono server che vengono utilizzati in questo modo, con utenti che non tutti possono fidarsi (o che non si fidano l'uno dell'altro), allora sì, il buco di escalation dei privilegi è un grosso problema. Tuttavia, è probabile che non sia così.
Supponendo che tu voglia ancora aggiustare rapidamente il buco installando la patch di Esser, hai due punti da considerare:
-
In pratica, stai inserendo nella tua macchina, con "privilegi del kernel", un pezzo di codice scaricato da Internet. Ciò comporta una dose di fiducia piuttosto pesante. Devi essere sicuro che il personaggio Internet che sembra avere il nome di "Stefan Esser" è abbastanza affidabile e che nessun altro potrebbe modificare la patch in cui è memorizzata o mentre la scarichi.
In che modo una certa "garanzia" da parte di un altro personaggio Internet , anche con un avatar fantastico, può creare un extra di fiducia?
Potresti, tuttavia, ottenere il codice sorgente, verificarlo, quindi compilarlo da solo. Ma se pensi di poterlo fare, allora non hai bisogno di aiuto da un sito StackExchange; ne conosci già abbastanza.
-
La patch cambia il comportamento della macchina, concettualmente per renderla "migliore" (o "più sicura"), ma un cambiamento è sempre un cambiamento e può rompere le cose. È possibile che qualche sviluppatore di applicazioni, da qualche parte, abbia notato che alcune variabili di ambiente DYLD_ * sopravvivono tramite l'esecuzione di SUID, e in realtà lo usano per alcune funzionalità (senza necessariamente notare che questo ha implicazioni sulla sicurezza). Mentre la patch sembra essere abbastanza innocua (almeno da quello che vedo nel codice sorgente - ma puoi fidarti di me ?), Non posso escludere la possibilità che questo influenzi il comportamento di alcune parti di il sistema operativo o le applicazioni.