Come ottenere accesso di root su un Mac, senza alcun hack:



Fonte, workaround e pezze varie.

Ohi ohi...
non ho provato sul mio sistema, ma... gravuccia questa, no?
Ce ne saranno altri di programmi con flag SUID che hanno lo stesso problema?

Messaggio modificato da gpz500 il 20 Jun 2008, 12:11

Su macchine in cui si usa seriamente la multiutenza sì, permette ad un utente limitato (anche l'utente Guest) di agire come root.

Chi amministra Mac in ambienti condivisi (laboratori, uffici) o concede accessi remoti (es.: server) farà bene a darci un occhio.

Vale anche per 10.4, mi sorprende che nessuno ci abbia fatto caso prima.



Questo non lo so, con altre applicazioni sono stati più accorti. Activity Monitor per esempio che pure ha bisogno di privilegi di root, ad essere SUIDdato è un “programmino” separato (pmTool).

Altre info.

Secondo me è grave anche per chi è da solo!
Pensa se qualcuno riesce a farti eseguire, magari da una pagina web (sfruttando una eventuale falla di Firefox o Safari) oppure con un inganno, lo script in questione con "rm -rf /*" al posto di "whoami"...

Ma perché dovrebbe farlo? :°D

Se la macchina è monoutente allora `rm -rf ~` basta e avanza.

Cioè una volta che questo Qualcuno è riuscito ad eseguire un programma sulla tua macchina, con i privilegi del tuo utente, tu hai già un grosso problema, perché questo Qualcuno può leggere-scrivere-cancellare i tuoi file (la tua mailbox, i tuoi documenti, etc).

Insomma non ha bisogno di “evadere” dal tuo account, e questa vulnerabilità serve proprio a questo, evadere.

In effetti, neanch'io ho alcunché fuori dalla mia cartella home, a parte il sistema operativo e le applicazioni...

Riapro la discussione perche' una notizia che ho appena letto mi ha fatto ripensare alla faccenda.

Senza il bug di ARDAgent il trojan dell'articolo dovrebbe, per installarsi tra i servizi ad avvio automatico, richiedere l'inserimento della password da parte dell'utente. Il che ridurrebbe di molto la sua pericolosita`.

Mi par di capire che non e` ne' inutile ne' superfluo ottenere i privilegi di root senza inserire la password, neanche in un sistema single user.
La Apple dovrebbe correre ai ripari il piu` presto possibile: ora che la vulnerabilita` e` nota pubblicamente casi del genere si moltiplicheranno.

Che ne pensate?

Ma vedi, dipende tutto dalle scelte di design dell'autore...

Senza privilegi si posson scattare foto con la webcam ed inviarle in giro (non so se poi come root è possibile evitare l'accensione del LED).

Senza privilegi si può rendere accessibile in remoto il computer della vittima: basta premurarsi di “agganciare” il daemone di turno ad una porta oltre la 1024 piuttosto che far partire il servizio di condivisione con le impostazioni predefinite.

Per intercettare la tastiera a quanto ne so dovrebbe essere sufficiente un Input Manager in ~/Library, almeno in Tiger. Su Leopard le cose dovrebbero essere cambiate, ma non so quanto.

Anche l'avvio automatico... (semplificando) c'è un avvio automatico “di sistema” ed un avvio automatico “per utente”. Il secondo può bastare.

Certo che se conosci un metodo facile facile come questo per ottenere root, allora te ne freghi dei dettagli e usi quello :°D

Per completezza d'informazione:
La cosa mi sembra di aver capito però che non funziona da remoto e solo con la condivisione di remote desktop spenta.
Bisogna perciò essere fisicamente sulla macchina. A questo punto se si vogliono far dei danni non è sufficente inserire un cd di sistema, piallare la password di amministratore ed avere via libera su tutto?
In ambienti di multiutenza se si vuole evitare che un utente possa far danni non ci si limita a non farlo amministratore ma si mettono anche le limitazioni a quel che si può fare...
Se date il computer in mano a qualcuno che può inserire un cd o lanciare qualsiasi cosa è normale che ci sia da preoccuparsi...

Per fortuna :°D



“Screen Sharing”, su Leopard.

Questa cosa che dev esser spento l'ho letta anche io, ma qua il “giochino” funziona anche quando è acceso.

Certo che oh dover tener acceso un *servizio di rete* per evitare una scalata di privilegi *locale* è un po' ridicolo :°D



Assolutamente no, è sufficiente indurre l'utente ad eseguire un programma o script (che poi sfruttando ARDAgent eccetera eccetera).



Ah certo, per uno che ha accesso alla macchina può essere sufficiente, solo che se tu amministratore una mattina arrivi in ufficio/biblioteca/laboratorio/quellocheè e non riesci a fare il login perché la password è stata cambiata *TI ACCORGI CHE LA MACCHINA È STATA VIOLATA*, e puoi attuare le varie ed eventuali contromisure (notificare gli altri utenti del problema e dirgli di cambiare le password, piallare la macchina, etc.).

Lo stesso vale per l'eventuale furto dell'hard disk o del computer stesso, caso mai qualcuno volesse intervenire per ricordarci che chi ha accesso fisico alla macchina può fare pure queste cose... :°D

Se invece tu una mattina arrivi in ufficio/biblioteca/laboratorio/quellocheè e tutto ti appare al suo posto come il giorno prima, perché non sono state effettuate manomissioni visibili... beh, che fai?! :°D

Niente, e chi ha manomesso la macchina può continuare imperterrito a (per esempio) spiare le attività tue e di tutti gli altri utenti.

Mica bello.



Eh ok, ma quali, anzi quante, limitazioni pensi di poter mettere?

No perché magari puoi vietare agli utenti di eseguire Script Editor e Terminal, e ok, questo è facile :°D

Ma poi gli devi bloccare pure iChat, iCal, Mail e Rubrica (tutte applicazioni in grado di eseguire script). Questo per quanto riguarda le applicazioni standard. Se cominciamo anche a contare le applicazioni di terze parti, le cose si complicano.

E poi gli devi anche impedire di crearsi file all'interno di ~/Library/LaunchAgents, e via discorrendo.

Tutte cose che se in OS X non ci fosse un programma che consente di eseguire applicazioni con i privilegi di root non ci sarebbe bisogno di limitare.

beh messa così il pericolo esiste da sempre: vado in script editor, registro le mie azioni mentre cambio lo screen saver e poi cancello tutta la cartella ~/Library. Poi ti invio lo script consigliandoti di lanciarlo che vedrai che screen saver...
A quel punto il patatrac è fatto. Il punto ora è: è il sistema fallato o l'utente si è meritato di veder sparire la propria Library?



Quando lo faccio si parte al contrario. Si blocca tutto, poi si permettono le cose man mano. Ma ad esempio iChat solo con determinati utenti, Safari solo sui siti che voglio io, ecc...
Io non permetto all'utente nemmeno di spegnere la macchina (accensione e spegnimento sono pianificati).

Potrei risponderti che un sistema operativo che nel 2008 non ti avverte che l'applicazione che hai appena scaricato da Internet o è allegata ad una e-mail o ti è stata inviata per IM potrebbe farti dei danni è un sistema poco sicuro, per diversi motivi. Infatti Leopard è più sicuro di Tiger perché ti avverte. Tiger era un po' più sicuro dei precedenti perché ti avvertiva che stavi per aprire per la prima volta una applicazione seguendo un url o aprendo un documento.

Ma non ti risponderò così perché qua nessuno sta asserendo che OS X è un sistema fallato perché un processo eseguito da un utente limitato può accedere ai file e le cartelle di proprietà di quello stesso utente. Ci mancherebbe :°D

Semmai, si sta asserendo che OS X è fallato perché un componente di sistema consente ad utente limitato di ottenere i privilegi di root. Sì ho scritto proprio “fallato” :°D Del resto a cosa servono gli account e le limitazioni se poi si può “evadere” con una riga di AppleScript?!



Che noia il tecnomachismo.



Sì ma il metodo usato da un diligente amministratore di sistema per definire le limitazioni è irrilevante, perché il fatto degno di nota è che autorizzando l'uso di iChat o Mail o Rubrica o iCal o iTunes (per rimanere nell'ambito delle applicazioni predefinite) si consente ad un utente cui magari è stato vietato l'uso di Script Editor o Terminal di eseguire script e sfruttare il buco in ARDAgent per sconfinare (togliersi le limitazioni, crearsi altre utenze, etc.).

Poi grazie... facile dire “blocco iChat”. Quello lo fai per la sicurezza... della produttività aziendale, non della macchina. Già decidere di bloccare Mail o Rubrica mi pare più difficile :°D

su questo ti do assolutamente ragione. Per quasi lo stesso motivo lo trovo fallato perchè basta avere un cd versione retail e prendi il possesso di qualsiasi cosa (documenti con FileVault esclusi).
Però anche chi ha provato a mettere paletti molto rigidi con l'installazione del sistema dimostra che non serve nemmeno chiedere ogni volta la fattura d'acquisto (consiglio una chiamata per attivare windows ogni tanto, sembrano rassegnati ad un lavoro inutile come quando nell'Urss c'erano 8 persone a fare il lavoro di 1).
Volevo porre l'attenzione che non c'è niente di cui allarmarsi, se non che senza tanto buon senso è possibile fare dei danni facilmente.


e perchè? ti assicuro che si fa regolarmente, limitandolo a scambiarsi solo con taluni indirizzi e per la rubrica è normale porre limitazioni, se non addirittura obbligandolo ad accedere a quelle condivise in rete e basta.

Beh non c'è nemmeno bisogno del CD... Avvio in single user mode + qualche comando da terminale. Sicuramente col CD è più user friendly :°D



Insomma dipende... sulla pericolosità di questa falla in certi contesti c'ho pure io le mie obiezioni e le ho già esposte. Dopo di che penso che una macchina "ad accesso più o meno pubblico" (uffici, biblioteche, aule, etc) sia molto più in pericolo ora di quanto non lo fosse prima (prima per via degli “attacchi fisici”).



Perché se gli blocchi Mail non può... usare l'e-mail?! :°D

A meno di non usare un client diverso, ovvio, ma ci si ritrova daccapo se questo client alternativo consente di eseguire script nei filtri.



Esempi: io sono un utente autorizzato ad usare Rubrica su una certa macchina. Come fai ad impedirmi l'esecuzione di uno script tramite il menu contestuale dei campi di una scheda creata in locale? Se sono autorizzato ad usare Mail, come fai ad impedirmi di collegare uno script ad un filtro? Se sono autorizzato ad usare iCal come fai ad impedirmi di aggiungere un evento che ad una certa ora fa partire uno script?

Se devo far accedere il "pubblico" ad una macchina la filtrerei col "controllo censura" talmente tanto che non puoi far danni.
Se devo dare una macchina in mano ad un dipendente, parto dal presupposto che senza il suo buon senso non posso proteggere niente. Quindi se può far danni anche ad altri dovrò analizzare bene la mia strategia di backup.
Concordo con te che non ci si aspettasse una cosa del genere; ma continuo a dire che secondo me non deve cambiare niente rispetto a prima, le precauzioni necessarie ora lo erano anche prima, ed esulano da questo bug.

Per la precisione: il controllo censura ti permette di specificare gli indirizzi con cui permettergli di chattare o inviare mail... in ambito aziendale può rivelarsi comoda.

Sì ma ripeto la domanda: come impedisci ad un utente autorizzato ad usare Mail o iChat di utilizzarle per eseguire script?

Non ci ho provato (ma mi sembra che sia possibile, anche se non in maniera banale - non è il periodo in cui troverò il tempo per i miei appunti e trovare come fare). Non mi pongo il problema perchè do per scontato che gli permetto di scrivere con persone affidabili e che controllo.
La mia attenzione non la pongo nel blindare il blindabile ma nel poter rimediare a problemi ed ovviamente nel permettergli danni solo a sè stessi.

Sono in parte vulnerabile (potenzialmente perchè ARD è sempre attivo in modo che possa controllarli centralmente) al fatto che un l'utente A crei uno script per controllare quello che fa l''utente B e lo tiene sott'occhio...
Non mi sembra una cosa cui dedicare del tempo, ci sono problemi e vulnerabilità che mi danno più grattacapi