Abolire il root check oppure preferirgli SafetyNet

[djechelon]

Descrivi il problema

Ritengo che per questo tipo di applicazione il root checking sia assolutamente inutile, eccessivo e peraltro aggirabile con due click

To Reproduce

Avviare Io su un device con Magisk. La app non si avvia perchè rileva i permessi di superutente.

Da Magisk, attivare la modalità Magisk Hide per la app Io. Riavviare Io. La app non si accorge di Magisk

Additional context

Il rilevamento del semplice rooting è una prassi obsoleta. Sebbene le linee guida OWASP indichino chiaramente che un device con privilegi di root è nella media un dispositivo "meno sicuro" rispetto ad uno originale, ho due osservazioni da fare sulla app Io.

1. Il metodo di rilevamento implementato ritengo sia troppo poco elaborato/robusto

Si cerca di "combattere il rooting" rilevando l'eseguibile su senza piuttosto fare un test standard di Android che è il SafetyNet.

SafetyNet, peraltro bucato da Magisk, è il tool "standard" di Google per confermare che il dispositivo è integro ed esegue un firmware originale aggiornato. SafetyNet viene eseguito online, quindi si aggiorna di continuo e non richiede che lo sviluppatore aggiorni la propria app. Molto spesso SafetyNet riesce però a bucare a sua volta MagiskHide, e l'operazione è trasparente rispetto alla app che esegue la verifica. Ad esempio Google Pay è quasi sempre in vantaggio su Magisk.

Uno dei vantaggi di SafetyNet è che può permettere il blocco, a discrezione di Google, firmware troppo obsoleti con vulnerabilità di sistema operativo evidenti e documentate.

2. Io non è una app tale da dover davvero bloccare il rooting o i custom firmware

Ritengo di essere una persona molto esperta in sicurezza informatica. Spesso vedo che sulla sicurezza si verificano i due estremi opposti. O gli sviluppatori non hanno la cultura della sicurezza e fanno cose profondamente errate (es. password nei repository, pochi controlli sugli utenti autenticati), oppure in nome della "Sicurezza" si iniziano a introdurre eccessive limitazioni (tornerò sull'autenticazione biometrica).

Credo personalmente che l'antiroot su una app come Io sia parte del secondo caso. Posso capire che chi ha sviluppato abbia seguito le linee guida OWASP o altre best practice, e condivido l'uso critico delle best practice,, ma la "Sicurezza" ad ogni costo ha due costi: costo materiale di sviluppo e manutenzione, e costo di frustrazione degli utenti (che se determinati potrebbero passare alle versioni web).

Il test SafetyNet, da sviluppatore e utente rootato, credo sia utile solo per certi tipi di applicazioni, come quelle che eseguono pagamenti NFC o certi giochi online basati sulla localizzazione GPS. Facile: trattandosi della possibilità di movimentare denaro in forma non autorizzata, ed essendo le banche responsabili delle transazioni non autorizzate, dire che ci sta fare prevenzione. E la maggior parte delle banche usa SafetyNet piuttosto che controllare gli eseguibili di sistema. Da riportare i casi emblematici come Intesa Sanpaolo che ad esempio non impedisce la consultazione e la movimentazione del conto ai cellulari "non originali" ma blocca solo il pagamento digitale NFC, che era ciò che io intendo nel mio post.

Per questa app, ho fatto due ragionamenti

Bloccare del tutto la app è inutile

Gli unici dati "finanziari" sono i metodi di pagamento PagoPA, che dovrebbero essere custoditi su server remoto comunque (credo). Se l'utente vuole solo ricevere gli avvisi di scadenza rata asilo e pagarli in altre forme, perchè bloccargli anche quello? Abbiamo paura, anche in epoca di Exodus, che app root malevoli rubino i dati personali "generici" dell'utente? La discussione diventa un ginepraio. Andrebbe fatta una riflessione...

Avrebbe senso bloccare solo i pagamenti PagoPA?

Magari la app contiene sul secure storage dei token che potrebbero essere esfiltrati per attivare pagamenti? Se così fosse, blocchiamo solo il pagamento PagoPA, non tutto il resto.

In generale, finiamo che in nome della "Sicurezza" degeneriamo in realtà l'esperimento delle cinque scimmie che ho piacere a linkarvi ritenendolo una utile lettura.

I servizi via web non sanno riconoscere un device rooted

E questo è il punto che a me preme di più, forse. Ci siamo mai fatti questa domanda? Se io accedo ad un servizio, anche ad "altissima sicurezza" da browser posso avere qualunque tipo di diavoleria sul mio device/browser (dagli add-on spia-pubblicitari ai keylogger), ma non vedo da parte della community eccessiva attenzione. Se un utente root vede che non può fruire della funzione da app, e non vuole rinunciare al root (es. blocco pubblicità, per quanto discutibile ecc.) va sul web dal device rootato e via!

In sostanza

La proposta è

1. Sostituire il root check che ad oggi viene fatto col controllo degli eseguibili su con SafetyNet, API più appropriata e approfondita per questo tipo di controlli
2. Valutare se non bloccare del tutto la app all'avvio in caso di test SafetyNet non passato, ma usare un approccio più soft basato su notifiche o blocco solo di alcune funzionalità più "critiche"

---

Edit: ho deciso di cambiare il titolo di questo ticket per una questione di linguaggio. Dare dell'"inutile" al root check mi sembra distruttivo e fuori luogo

[leophys]

In sostanza

La proposta è

1. Sostituire il root check che ad oggi viene fatto col controllo degli eseguibili `su` con SafetyNet, API più appropriata e approfondita per questo tipo di controlli

2. Valutare se non bloccare del tutto la app all'avvio in caso di test SafetyNet non passato, ma usare un approccio più soft basato su notifiche o blocco solo di alcune funzionalità più "critiche"

TL;DR

• La API SafetyNet delega la certificazione della sicurezza del dispositivo alle scelte, non solo tecnologiche ma anche politiche, di Google.
• Concordo che sia il modo giusto di controllare l'integrità di un dispositivo, ma impedire l'utilizzo di questo che è un servizio_pubblico a quel panorama di persone che, ad esempio, non può permettersi uno smartphone nuovo (e quindi aggiornato) mostra profili di incostituzionalità.
• La giusta soluzione è di controllare l'integrità del OS del dispositivo, usando SafetyNet, e in caso di risultato negativo avvisare l'utente con un banner di conferma interattivo (approccio usato, ad esempio, dall'app di BNL).

La mia opinione

Sono un felice utente di custom ROM. Ho fatto tempo fa la scelta di usare ROM buildate da me, a partire da LineageOS. Il motivo per cui ho fatto questa scelta è duplice:

• per avere una versione di android aggiornata anche su un dispositivo non più supportato ufficialmente (nexus 5)
• per sperimentare liberamente software che altrimenti non sarei stato in grado di utilizzare

So che faccio parte di una nicchia trascurabile e non rappresento i bisogni della maggior parte delle persone, ma sollevo questo punto anche per il tipo di servizio che questa app dovrebbe offrire.

Ci sono due casi d'uso che mi vengono in mente:

• l'utente di vecchio smartphone, con versione di android non più supportata e che quindi fallirebbe il controllo SafetyNet (o su cui l'API non è proprio presente)
• il/la poweruser che ha installato una custom ROM

Entrambi i casi d'uso sono legittimi e non giustificano l'esclusione dal servizio. Tale esclusione poi non sarebbe in mano allo stato, ma dipenderebbe dalle scelte tecniche (legittime), politiche (questo è un fattore non trascurabile) e anche, soprattutto, commerciali di un entità privata (nel caso di android, Google, sussidiaria di Alphabet). Questo ultimo aspetto legato poi in maniera molto complessa alle scelte degli OEM (Samsung, per fare solo un esempio) che hanno mostrato chiaramente negli anni di non avere interesse a supportare dispositivi "vecchi" per favorire l'acquisto di dispositivi nuovi. Parallelamente a questo, anche se ci sono stati interventi da parte delle autorità europee in difesa dei diritti dei cittadini al controllo dei propri dati, non c'è una pari spinta per obbligare i produttori a supportare il software dei dispositivi.

Conlcusioni

Come quasi sempre accade, le decisioni che spesso si ammantano di tecnico, sono squisitamente politiche. Questa ne potrebbe rappresentare un esempio concreto chiaro. La domanda a cui si deve rispondere è: chi ha il diritto, di fatto, ad accedere ad un servizio pubblico e chi no?

Dato che lo sviluppo del codice avviene in chiaro, poi, sarebbe interessante anche poter partecipare, o almeno assistere, al processo decisionale che sta dietro a queste scelte.

[zarEclEC]

Ma poi dov'è il senso del root check se chiunque può fare fork e rimuovere il check? 🤔

I controlli si fanno server-side (esempio il login per verificare se i dati sono corretti), client-side può esserci qualsiasi cosa, come ha giustamente fatto notare @djechelon , anche un browser, e lì il root check non c'è.

Benvenga l'avviso per gli utenti meno esperti, ma non questo che succede ora:

L'applicazione non può decidere per me.
L'avviso va trasformato in una domanda

Ci sono tutti questi rischi [inserire frasi "spaventose" qui], vuoi procedere lo stesso? [Si/No]

E sarà l'utente a farsi carico del peso della sua scelta, un po' come fa google stesso quando abiliti le sorgenti sconosciute per installare apk esterni

[djechelon]

Ma poi dov'è il senso del root check se chiunque può fare fork e rimuovere il check?

Ti faccio una considerazione di ingegneria del SW, e provo a semplificarla. Un software open non è sempre un software che chiunque può realmente forkare, dipende dal SW. Magari una app pubblica per un discorso di trasparenza e funding* pubblica i sorgenti, ma non deve necessariamente essere interoperabile con la pippo_mod.

Il motivo è sui pagamenti, torniamo sempre lì. Il settore bancario è soggetto a grosse grosse grosse responsabilità e costi in caso di frodi. Puoi pubblicare open il firmware di un POS, ma per usarlo va firmato digitalmente dal tenutario del repository.

*Funding: se ci sono soldi pubblici io cittadino esigo che la app sia "mia" proprietà, perchè i soldi vengono dalle mie tasse. Tutte le opere intellettuali fatte coi soldi del governo USA sono "pubblico dominio" a default, è sufficiente come esempio?

[Undermaken]

Ciao ragazzi.
@djechelon offre una ottima analisi e un ottimo spunto.
Abbiamo appreso la problematica e stiamo cercando di capire come intervenire tecnicamente dopo un confronto con il nostro DPO e quindi il garante della privacy (già da tempo)

Il check che facciamo è debole e da alcune segnalazioni sembra generare anche dei falsi positivi, diminuendo l'accessibilità all'app.

Tengo questa PR updated con notizie a riguardo cosi che possiamo anche confrontarci per trovare la soluzione migliore

[leophys]

Il motivo è sui pagamenti, torniamo sempre lì. Il settore bancario è soggetto a grosse grosse grosse responsabilità e costi in caso di frodi. Puoi pubblicare open il firmware di un POS, ma per usarlo va firmato digitalmente dal tenutario del repository.

Ciao @djechelon, intervengo e lo faccio con nessuna intenzione polemica.
Siamo d'accordo su questo, ma il contesto di questo servizio non è il dominio bancario o commerciale, ma un servizio dello stato. Penso che lo stato possa prendersi dei rischi, dato che ha anche l'autorità di emanare leggi e farle rispettare.

*Funding: se ci sono soldi pubblici io cittadino esigo che la app sia "mia" proprietà, perchè i soldi vengono dalle mie tasse. Tutte le opere intellettuali fatte coi soldi del governo USA sono "pubblico dominio" a default, è sufficiente come esempio?

Anche qui concordo. Mi piacerebbe che questo non fosse uno stato d'eccezione, ma la norma.

Una domanda per @Undermaken, il progetto accetta PR? Avete un template per le PR. Posso dedurre che siano ben volute?

[Undermaken]

@leophys

Una domanda per @Undermaken, il progetto accetta PR? Avete un template per le PR. Posso dedurre che siano ben volute?

Si certo le PR sono ben volute da parte di tutta la community
Abbiamo un gruppo di sviluppo interno che le valuta, ne fa la revisione e nel caso le accetta.

Se la PR aggiunge una funzionalità, il processo prevede anche la revisione da parte del Product Owner che ne vede la compatibilità in termini di prodotto.

[studiofuga]

Se la sicurezza dell'intero sistema dipende dal fatto che l'utente ha un sistema rootato o meno, è un grosso problema di design. L'utilizzo di firmware derivati o con i privilegi di root possono essere dettati da esigenze legittime: ad esempio di software che senza di essi non possono funzionare.
Ad ogni modo, personalmente ritengo che la app debba proteggere esclusivamente le parti sensibili; ad esempio, limitando l'accesso ai sistemi di pagamento in caso di "firmware non sicuro".
Sarebbe un approccio più pragmatico e meno soggetto a falsi positivi. Possibilmente, demandando al giudizio dell'utente (e scaricando la responsabilità) se procedere o meno.

my 0.2c.

[Undermaken]

Se la sicurezza dell'intero sistema dipende dal fatto che l'utente ha un sistema rootato o meno, è un grosso problema di design. L'utilizzo di firmware derivati o con i privilegi di root possono essere dettati da esigenze legittime: ad esempio di software che senza di essi non possono funzionare.
Ad ogni modo, personalmente ritengo che la app debba proteggere esclusivamente le parti sensibili; ad esempio, limitando l'accesso ai sistemi di pagamento in caso di "firmware non sicuro".
Sarebbe un approccio più pragmatico e meno soggetto a falsi positivi. Possibilmente, demandando al giudizio dell'utente (e scaricando la responsabilità) se procedere o meno.

my 0.2c.

Concordo, tecnicamente.
Per fortuna o purtroppo l'intervento tecnico è subordinato alle indicazioni del DPO che a sua volta pone discute la problematica con il garante della privacy.

I miei 2cents in questo senso sono: molti aspetti di diritto e giuridici non coprono, o mal rappresentano, situazioni come queste. Ecco perchè spesso le soluzioni sono degli ibridi inefficaci oppure totalmente divergenti. Come società stiamo cercando anche di colmare questo gap portando problemi "reali" che richiedono interventi efficaci e in linea con i tempi.

Spero riusciremo a breve ad adottare una soluzione che tecnicamente risolve il problema ed insieme tutela la sicurezza e la privacy del cittadino. Qualora queste condizioni non sono garantite il cittadino deve essere opportunamente informato

[Undermaken]

Abbiamo aggiunto la richiesta nel nostro backlog
Ne parliamo durante lo sprint settimanale che si farà domani.
Se la proposta è ok per il PDO e il PO e gli assegneremo una priorità alta, verrà rilasciato nel prossimo aggiornamento

Grazie per il supporto ;)
#1706 (comment)

[Mte90]

Concordo, le varie app di banche ti dicono che il dispositivo è rootato e che se continui ad usarlo sono problemi tuoi, però ti fanno usare l'app.
Limitare così è molto controproducente come in tanti hanno già detto e non mi dilungo.

[Undermaken]

merged #1961

[Tachi107]

So che questo Issue è stato chiuso due anni fa, ma al momento non ho la possibilità di aprire un nuovo Issue con tutti i dettagli tecnici della cosa, e lascerò un breve commento come piccolo promemoria per non dimenticarmi di aprire un thread vero e proprio.

Sebbene SafetyNet sia un controllo abbastanza efficace per verificare che un dispositivo venduto coi servizi Google preinstallati non sia stato modificato, esso non è sufficiente per la verifica di dispositivi sicuri / non modificati ma sprovvisti di servizi Google, perché così venduti dal produttore o per scelta del proprietario del telefono.

Fortunatamente in Android esiste un metodo standard, implementato proprio nel progetto AOSP, che permette di verificare se il dispositivo sta eseguendo una versione di Android sicura e non modificata. Questo metodo è chiamato Key Attestation, e rende possibile controllare che il dispositivo non sia stato modificato sfruttando l'hardware, non il software. Questo metodo è quindi anche più sicuro di SafetyNet, in quanto non è possibile falsificare i risultati con Magisk o simili (almeno fino a quando Google non deciderà di utilizzare le chiavi memorizzate in hardware anche in SafetyNet, rendendo i due metodi praticamente la stessa cosa).

Oltre alla maggiore garanzia dell'autenticità dei risultati, con la Key Attestation è possibile supportare anche le custom ROM di terze parti, aggiungendo le loro chiavi pubbliche alla lista di chiavi fidate. Certo, non tutte le custom ROM sono affidabili, ma credo che aggiungere il supporto ad alcuni progetti con alti standard di sicurezza come LineageOS o GrapheneOS sia fattibile. Quest'ultima, oltre ad essere decisamente più sicura di una versione stock di Android, ha anche scritto una breve guida che descrive i principi di questa Key Attestation, e spiega come aggiungere le loro chiavi alla lista di quelle fidate; la potete trovare qui: https://grapheneos.org/articles/attestation-compatibility-guide

Spero che possiate considerare l'idea di implementare questa cosa, in modo da rendere tutti un po' più sicuri e un po' meno dipendenti da Google :)

[djechelon]

E direi che sistema una volta per tutte la questione Huawei