[Soci SLIP] spaventosa situazione con android

[Lucio Crusca]

In data sabato 21 maggio 2011 13:33:00, loredana ha scritto:
> 
> Qui c'e' invece il rapporto dei ricercatori dell'universita' di Ulm, che
> hanno fatto un ottimo lavoro ed un ottimo servizio, sia a google che ai
> suoi "clienti":
> 
> http://www.uni-ulm.de/en/in/mi/staff/koenings/catching-authtokens.html

Prendo direttamente da lì:

"The fix does not require an update of the Android OS"

"La correzione non necessita di un aggiornamento del sistema operativo 
Android"

e, più sotto

"Note that this vulnerability is not limited to standard Android apps but 
pertains to any Android apps and also desktop applications that make use of 
Google services via the ClientLogin protocol over HTTP rather than HTTPS."

"Notate che questa vulnerabilità non è limitata alle applicazioni standard di 
Android ma riguarda qualsiasi applicazione Android e anche applicazioni 
desktop (non Android, ndt) che usano i servizi Google attraverso il protocollo 
ClientLogin su HTTP piuttosto che HTTPS".

Come dire, "noi l'abbiamo provato su Android, ma il problema non è di Android, 
è di Google e delle applicazioni che usano i servizi Google in generale". Cioè 
quello che io sto dicendo fin dall'inizio. 

Ah già, il giornalista non l'ha capito ed ha scritto solo Android, citando poi 
uno studio di Juniper (che nulla ha a che vedere con il problema specifico nè 
con la ricerca universitaria in questione) che è accessibile solo a chi si 
registra. Ma tu guarda, Juniper è un inserzionista di eWeek... sarà un caso?

http://justmedia.com/blog/category/eweek/

Inoltre sembra che io non sia l'unico a lamentarmi dell'etica giornalistica di 
eWeek:

http://techrights.org/2007/11/01/open-letter-eweek/

E guarda un po'? Juniper, oltre a non fare della security il suo core 
business, è pure un partner di Microsoft:

http://www.microsoft.com/virtualization/en/us/partner-profile-juniper.aspx

Che significa che lo studio di Juniper, oltre a non specificare il 400% di quale 
numero ed oltre ad essere uno studio non divulgato, è probabilmente stato 
finanziato da Microsoft... storia già vista, solo che al tempo al posto di 
Juniper c'era il Gartner Group...

http://techrights.org/2009/01/19/gartner-corrupted-by-microsoft/

Certo, il fatto che lo studio di Juniper sia stato manovrato da Microsoft è 
solo una mia illazione, ma le premesse ci sono tutte.

> Fra le altre cose, spiega in maniera molto semplice in cosa consista
> l'attacco e quali rimedi siano stati suggeriti sia a google che a chi
> usa i servizi di google. Questo vale solo per il problema specifico
> della cattura dei tokesn e l'impersonificazione
> (man-in-the-middle-attack)

Scusami se ti correggo di nuovo su questo aspetto, ma il problema del 
ClientLogin NON porta ad un attacco MITM:

http://it.wikipedia.org/wiki/Man_in_the_middle

> servizi di google. Non so esattamente dove sia implementato questo
> protocollo, non conoscendo android, ma a naso me lo aspetto in una delle
> librerie di sistema. 

No, come dicevo già nella scorsa email, è un protocollo di livello 7, ovvero 
applicativo, che significa che viene implementato ogni volta per ogni singola 
applicazione. Non fa parte di Android.

> Ovviamente, anche le singole applicazioni che lo
> usano devono essere corrette, ma immagino che il codice stia in una
> funzione di libreria che viene richiamata da tutte le applicazioni, 

No, non esiste alcuna libreria per Android o per altri sistemi che implementi 
ClientLogin. È semplicemente una chiamata HTTP o HTTPS. Volendo si possono 
usare librerie di terze parti (Apache) per semplificarsi la vita, ma non fanno 
parte di Android e devono essere incluse in modo statico in ogni singola app.

> non che sia duplicato nelle singole applicazioni. 

Invece sì, è duplicato in tutte le applicazioni.

> Un minimo di cognizioni di
> software engineering ce l'avranno anche dalle parti di google, spero.

Le librerie a collegamento dinamico hanno pro e contro. Nell'era in cui la 
memoria non costa più nulla, i pro delle librerie statiche si fanno più 
importanti e risparmiare bytes non ha più molto senso se questo pone problemi 
di altro genere, tipo la gestione delle dipendenze.

Documentazione a sostegno di quel che dico:

http://stackoverflow.com/questions/2152337/how-can-i-implement-clientlogin-on-
android-to-access-google-services

> 
> Google comunque controlla le comunicazioni del vostro
> cellulare/tablet/quant'altro e percio' la "correzione" ve la fa lui,
> come e quando vuole. Questa, del controllo delle comunicazioni e del
> loro abuso a proprio uso e consumo, mi immagino sia la funzione
> principale di android, che non si trova in GNU/linux, ma che ben
> conosciamo grazie a microsoft e mac.

Sì il kill switch è una porcheria, sono d'accordo. Se uno volesse prendere le 
parti di Google, potrebbe dire che il kill switch è l'unico modo che ha google 
per proteggere i propri utenti quando qualcuno pubblica qualcosa sul market 
che va oltre le condizioni d'uso del market stesso, dato che la pubblicazione 
sul market è moderata solo a posteriori. Anche se fosse così mi farebbe paura 
ugualmente ed auspico che Google un giorno aggiunga almeno l'opzione per gli 
utenti di disattivare il kill switch a loro rischio e pericolo.

Cmq non mi sembra sia la funzione principale di Android, cioè, fino ad ora 
Google ha usato il kill switch solo per togliere dei trojan dal market, quindi 
per scopi assolutamente condivisibili. 

Prima che tu mi dica "allora vedi che esistono i virus per Android?", ricordo 
che i trojan non sono dei virus, ma sono programmi maligni, mascherati da 
programmi benigni che però poi non funzionano, che l'utente deve 
volontariamente scaricare dal market ed autorizzare, come tutti gli altri... e 
se solo l'utente facesse la fatica di leggere i commenti lasciati dagli altri 
o di scaricare solo programmi di cui ha letto prima una recensione da qualche 
parte il problema non esisterebbe.

> Il rapporto in se' non e' disponibile online, bisogna registrarsi:
> 
> http://www.juniper.net/us/en/dm/interop/go/
> 
> Se qualcuno ci mette sopra le mani, varrebbe la pena farlo circolare in
> lista.

No non fatelo, o almeno prima di farlo assicuratevi che ne abbiate 
l'autorizzazione (in base alle osservazioni sopra, secondo me non ce l'avete). 
Se bisogna registrarsi per vederlo probabilmente significa che non si è 
autorizzati a divulgarlo a proprio piacimento.

> Il rapporto  ha a che fare con l'altro aspetto, ben piu' drammatico
> rispetto alla faccenda clientlogin, del malware.
> 
> "Most notable the recent android malware, DroidDream that was downloaded
> over 50,000 times in four days"
> 
> " tra i piu' rilevanti, il malware recente per android, DroidDream, che
> e' stato scaricato piu' di 50.000 volte in 4 giorni.
> 
> Scaricato, si noti, da android market, cioe' il repository ufficiale
> delle applicazioni android. 

Sì ma è moderato da Google solo a posteriori, per permettere agli sviluppatori 
di pubblicare immediatamente le applicazioni senza dover aspettare 
l'approvazione di Google.

> Sembra che si sia trattato di un rootkit che
> ha infettato piu' di 50 applicazioni prima che qualcuno se ne
> accorgesse. 

Questo dato non l'ho trovato. MI sembrava anzi che DroidDream alla fine 
riuscisse solo a leggere il modello del cellulare, ma magari mi sbaglio. Hai 
un link? 

> Se ho capito bene, le applicazioni girano in una sorta di
> jail e droiddream e' capace di quello che in altri contesti si chiama
> "priviledge escalation", 

Sì, ma solo se lo scarichi e lo installi volontariamente. La stessa cosa la sa 
fare Z4Root, che però non è un malware ma è utile per far ottenere all'utente 
i permessi di root sul proprio telefono cellulare.

> 
> Google ha certamente quello che si chiama backdoor sui vostri
> dispositivi android. La stessa cosa che i trojan usano per le
> loro sporche faccende su windows e unix system alike. 

No, qui stai confondendo le cose. La backdoor di Google sarebbe il killswitch 
di cui sopra ed ha i suoi problemi etici, ma non è la stessa cosa che usano i 
trojan, i quali usano semplicemente l'ingenuità degli utenti.

Quanto ai problemi etici, se vuoi un dispositivo Android "senza kill switch", 
basta che installi le app senza passare dal Market. Google può legalmente 
usare il killswitch solo sulle app che hai installato attraverso il market. Se 
tu installi una app scaricandola separatamente da internet (non dal Market ma 
dal sito di chi la fa) e mettendola sul dispositivo attraverso il cavetto usb 
in dotazione, Google non può legalmente rimuoverla dal tuo dispositivo e 
questo in base alle condizioni d'uso del market che Google ti chiede di 
accettare quando ti registri.

> Google lo
> usa per controllare le applicazioni, spedire informazioni che poi
> servono ai suoi scopi, 

Questo ad oggi non è vero: le condizioni d'uso del Market parlano solo della 
possibilità di google di rimuovere dal tuo dispositivo applicazioni che non 
rispettano le stesse d'uso del market. Non parlano della possibiltà di Google 
di prendere i tuoi dati e farci quello che vuole.

> 
> Cosi' e', se vi pare. Ignorarlo puo' solo far male.

Non proprio così, è giusto sapere le cose, ma è giusto sapere quelle corrette.

> 
> Ah, gli altri son peggio di google e android, per definizione.

Sì, infatti Apple, oltre ad avere il kill switch, ce l'ha pure senza 
giustificazione, perché le applicazioni sull'AppStore sono soggette ad 
approvazione da parte di Apple prima della pubblicazione (e ci mette qualche 
giorno ad approvarle), quindi ci si chiede che senso abbia per Apple poter 
mettere le mani sui terminali degli utenti.