A volte quello che si pensa essere un miglioramento si rivela essere proprio l’opposto. E’ quanto emerso da analisi fatte dal Google Project Zero, un team di ricercatori di sicurezza di Google che studiano le vulnerabilità così dette “zero-day“.

Il caso preso in questione è quello di Samsung che, nel tentativo di prevenire alcuni attacchi ai telefoni della linea Galaxy, ha modificato il codice del kernel Android, finendo per esporre più bug di sicurezza di quanti presenti originariamente.

Il ricercatore Jann Horn ha notato che non solo i creatori di smartphone come Samsung tendono ad introdurre vulnerabilità aggiungendo driver personalizzati per l’accesso diretto all’hardware sul kernel Linux Android, ma tendono a reimplementare funzionalità di sicurezza già presenti nello stesso kernel.

La rilevazione è stata fatta sul kernel in esecuzione sul Samsung Galaxy A50 (ma è molto comune per tutti i produttori di smartphone) che, nonostante la modifica sia volta ad aggiungere sicurezza al dispositivo, introduce anche un bug di corruzione della memoria che Google ha identificato e notificato a Samsung il novembre scorso. Samsung ha quindi identificato il bug con la SVE-2019-16132 (marcato come di impatto “medio” e che permette l’esecuzione di codice arbitrario) e risolto con l’update di Febbraio, insieme ad altri bug critici che affliggono il sistema che Samsung chiama TEE (Trusted Execution Environment) sui telefoni più recenti (come il Galaxy S10).

Android has been reducing the security impact of such code by locking down which processes have access to device drivers, which are often vendor-specific

Android ha ridotto l’impatto di sicurezza di quel tipo di codice bloccando alla base i processi che hanno accesso ai driver del dispositivo, che spesso sono specifici dei vendor.

Spiega così Horn, indicando che i nuovi sistemi Android dovrebbero accedere all’hardware tramite HAL, Hardware Abstraction Layer, presente nell’OS. Ma, continua, molti vendo modificano parti centrali del kernel Linux minando la sicurezza intrinseca di questa funzionalità.

I believe that device-specific kernel modifications would be better off either being upstreamed or moved into userspace drivers, where they can be implemented in safer programming languages and/or sandboxed, and at the same time won’t complicate updates to newer kernel releases

Credo che le modifiche al kernel specifiche per il dispositivo sarebbe meglio che venissero messe in upstream (mandate alla community del kernel per la review e l’introduzione ufficiale nel kernel, ndt.) o spostate in driver userspace (quindi in un’altra zona di esecuzione), dove possono essere implementati in linguaggi di programmazione più sicuri e/o isolati, ed al tempo stesso non complicare gli aggiornamenti a nuove release del kernel.

Quindi, se usate dispositivi Samsung l’aggiornamento è d’obbligo e, chissà, magari i vendor inizieranno a capire che l’avere un community a revisionare il loro lavoro potrebbe essere un vantaggio, riversando driver ufficiali nel nostro amato kernel?

Matteo Cappadonna

Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.