Chez Google, la gestion des correctifs de sécurité a basculé sur un système de risque

Le changement a été révélé par Android Authority le 13 septembre et confirmé à demi-mot par Google. Nos confrères relèvent ainsi que le bulletin de juillet ne contenait aucune vulnérabilité corrigée, une rupture face aux 120 failles corrigées depuis le début de l’année. À l'inverse, le bulletin de septembre comportait des correctifs pour 119 failles à lui seul. Comment expliquer une telle différence ?

Une évaluation des risques

Google donne à présent la priorité aux failles comportant un risque élevé, qui ne tient pas uniquement compte de la criticité d’une vulnérabilité. L’entreprise ne détaille pas les critères d’évaluation, mais on peut supposer que le nombre de cibles potentielles et la facilité de mise en œuvre font partie des principaux, de même que l’existence d’une exploitation connue. Selon Android Authority, le mécanisme est nommé Risk-Based Update System, ou RBUS.

La règle est simple : si la faille présente un risque élevé, elle est publiée comme telle dans le bulletin mensuel, et si elle peut attendre, elle partira dans le bulletin trimestriel. Pour nos confrères, ce changement a été mis en place pour soulager les constructeurs intégrant Android dans leurs smartphones (OEM). Les failles à haut risque ont ainsi des chances accrues d’avoir un correctif rapidement diffusé, la diffusion des solutions étant parfois complexe à maintenir en fonction du nombre d’appareils concernés.

Toujours selon Android Authority, ce changement explique pourquoi le bulletin de juillet était vide : aucune faille à haut risque n’était répertoriée. Il explique aussi celui de septembre comptait autant de failles corrigées : elles avaient toutes été mises de côté pour le grand bulletin trimestriel.

Avantages et inconvénients

Bien que Google n’ait pas documenté ce changement, la société l’a confirmé à demi-mots à Android Authority :

« Les bulletins de sécurité Android et Pixel sont publiés tous les mois. Pour assurer la sécurité des utilisateurs, nous intégrons une sécurité puissante profondément ancrée dans les fondations d’Android. Android arrête la plupart des exploitations de vulnérabilité à la source grâce à un renforcement complet de la plate-forme, comme notre utilisation du langage Rust et des protections anti-exploitation avancées. Android et Pixel corrigent en permanence les failles de sécurité connues et donnent la priorité à la correction des vulnérabilités les plus risquées en premier »

Côté utilisateurs, rien ne change vraiment dans la plupart des cas. Les constructeurs décidant d’appliquer quand même les correctifs de sécurité tous les mois pourront continuer à le faire. Ceux souhaitant un rythme plus souple ne diffuseront alors des correctifs mensuels que si des failles à haut risque y sont présentes, et se contenteront d’une grosse mise à jour tous les trois mois dans le cas contraire.

Les avantages ne concernent a priori que les OEM, qui ont parfois du mal à tenir le rythme, selon les gammes commercialisées et le nombre de modifications faites sur la base d’Android. En leur offrant un nouveau cycle trimestriel, ils peuvent en théorie mieux préparer le terrain.

L’approche a également ses inconvénients. Retarder la publication des mises à jour peut laisser le temps à certaines failles d’être exploitées. Car les informations circulent : si des failles sont trouvées, les entreprises sont averties, de même que les équipes d’ingénieurs. Plus il y a de personnes au courant, plus le risque de fuite augmente, et avec lui la probabilité d’une exploitation.

Un système complexe

Le problème des mises à jour de sécurité sur Android est débattu depuis longtemps, avec toujours le même constat : les constructeurs doivent jouer le jeu. La pluralité des gammes et le nombre de modifications apportées à la base d’Android peuvent ralentir l’application des correctifs, car il faut mener suffisamment de tests pour s’assurer du bon fonctionnement. Plus il y a d’appareils dans les gammes, plus ce travail est conséquent.

Comme le rappelle d’ailleurs Android Authority, les entreprises ne jouent pas toutes le jeu de la même manière. Si l’on voit depuis deux ans des annonces très importantes sur la durée du support, notamment sur les Pixel et les Galaxy S de Samsung, un bon support est trop souvent dépendant de la gamme. De nombreux appareils d’entrée ou milieu de gamme ont un support limité de quelques années, les correctifs de sécurité n’arrivant pas tous les mois. C'est d'ailleurs ce qui a poussé l'Union européenne à imposer un nouveau minimum de cinq ans pour les mises à jour logicielles sur tous les nouveaux appareils.

• Smartphones, tablettes : l’étiquette énergie et l’écoconception entrent en application

Google connait bien le problème. Le projet Mainline (initié avec Android 10, mais arrivé concrètement dans les versions suivantes) a notamment été instauré pour augmenter le nombre de composants pouvant être mis à jour directement par Google Play. Mais de nombreux composants bas niveau ne peuvent être modifiés que par les constructeurs. Aussi, lorsque Google signale une faille et prépare une modification de code, celle-ci n’est pas publiée immédiatement dans AOSP (Android Open Source Project), pour que les modifications de code ne révèlent pas les détails de la brèche.

Le nouveau mécanisme ne remet pas en cause l’Android Security Bulletin mensuel. L’ASB dispose pour rappel de deux versions : une publique pour lister les failles corrigées, et une privée pour avertir les OEM un mois avant et leur laisser le temps d’intégrer les correctifs. En revanche, certains bulletins seront parfois vides, qu’ils soient publics ou privés. Les bulletins complets seront désormais alignés sur le rythme trimestriel d'Android depuis sa dernière version 16, ce qui pourrait bien poser problème aux ROM personnalisées.