Sécurité IT : quand les défenses d’Android sont mises à mal

Perception Point a-t-il été trop alarmiste au sujet de la faille CVE-2016-0728 ?

En association avec Red Hat, la start-up israélienne avait, en début de semaine, attiré l’attention sur cette vulnérabilité qui se situe au niveau du gestionnaire de trousseaux de clés dans le noyau Linux.

Dans son rapport, elle évoque plusieurs dizaines de millions de PC et de serveurs affectés… ainsi que les deux tiers des terminaux Android (voir notre article : « Sécurité IT : qui a les clés de Linux ? »).

Google n’est pas d’accord sur ce dernier point. Le groupe Internet, qui a développé un correctif diffusé depuis le 20 janvier, assure que « bien moins d’appareils sont touchés que ce qui a été rapporté ».

En première ligne, les terminaux Nexus vendus en marque blanche : aucun d’entre eux ne serait exposé à la faille, tout du moins dans le cas le plus probable d’une exploitation via une application malveillante (un accès direct à la machine visée est en effet requis pour enclencher le mécanisme d’élévation de privilèges).

Au-delà de Google

L’équipe Android Security – qui précise que Perception Point n’a pas pris contact avec elle – affirme par ailleurs que toutes les versions de l’OS à partir de la 5.0 (« Lollipop ») sont immunisées, grâce au système de contrôle d’accès SELinux, qui empêche tout échange de données entre les applications malveillantes et le code affecté.

Qu’en est-il pour les moutures antérieures d’Android, à partir de la 4.4 « KitKat » ? Google explique que la sécurité n’est généralement pas remise en cause, car le noyau Linux est trop ancien : les versions en dessous de la 3.8 (stabilisée depuis février 2013) ne sont pas concernées par la faille CVE-2016-0728.

Plusieurs questions restent néanmoins en suspens. Non seulement, comment les constructeurs et les opérateurs vont diffuser le patch. Mais aussi et surtout dans quelle mesure les surcouches développées par leurs soins peuvent diminuer le niveau de sécurité d’Android.

On relèvera, à ce sujet, une contribution de Now Secure, qui explique plus globalement à quel point le modèle d’exploitation actuel d’Android dépend des décisions des OEM et des opérateurs, à moins, pour l’utilisateur final, de compiler lui-même l’OS ou d’opter pour une ROM alternative de type CyanogenMod.

Failles ajoutées

Du côté de Google, on dispose d’outils dédiés pour tester les implémentations d’Android afin de s’assurer que les briques fondamentales du système n’aient pas été modifiées par les partenaires. Mais cet examen n’est valable qu’à un instant T, pour une version bien précise : il n’est ensuite plus réalisé sur l’ensemble du cycle de vie des produits.

Un exemple d’OEM ayant « cassé » la sécurité d’Android ? On peut mentionner Samsung, qui, sur le Galaxy S5, avait affaibli les défenses de SELinux en « ajoutant des failles » via l’application de clavier intelligent Swiftkey et une fonction de point d’accès sans fil.

Le groupe sud-coréen avait, il y a quelques années, tenté de se positionner sur le sujet en rejoignant l’Android Update Alliance, dont les membres s’étaient engager à assurer un suivi d’au moins 18 mois pour chacun de leurs terminaux. La coalition s’est vite éteinte…

Crédit photo : OlegDoroshin – Shutterstock.com