Selon un commit récent que nous avons découvert dans le projet Android Open Source, Google prépare pour faire la distinction entre le niveau de correctif de sécurité du fournisseur et le correctif de sécurité Android Framework niveau. Cela permet aux OEM de maintenir Android à jour en attendant que les fournisseurs de matériel fournissent des correctifs.
Pendant longtemps au début de son histoire, Android avait la réputation d'être moins sécurisé qu'iOS en raison de l'approche "jardin clos" d'Apple en matière d'applications. Nous n'allons pas examiner si cette réputation passée est méritée ou non, mais il est clair que Google a fait de grands progrès dans la sécurisation d'Android contre les vulnérabilités. Non seulement la société propose de nouvelles fonctionnalités de sécurité dans la dernière version d'Android, Android P, mais ils fournissent également "sécurité de niveau entreprise" dans leurs derniers appareils grâce à un module de sécurité matériel dans le Google Pixel 2/2 XL. Assurer la sécurité d'un appareil nécessite également des mises à jour continues pour corriger toutes les dernières menaces. C'est pourquoi Google a
bulletins de sécurité mensuels pour que tous les fabricants et fournisseurs d'appareils intègrent des correctifs contre toutes les vulnérabilités actives et potentielles connues. Maintenant, il semble que la société puisse apporter des modifications au système Android Security Patch en fournissant un moyen de faire la distinction entre le niveau de correctif du framework Android et le niveau de correctif du fournisseur avec le chargeur de démarrage, le noyau, etc. soit pour diviser les niveaux de correctifs de sécurité afin que les OEM puissent fournir des mises à jour pures du framework, soit pour mieux identifier à l'utilisateur le niveau de correctif qu'ils exécutent.Correctifs de sécurité Android mensuels - Introduction
Nous savons tous que les correctifs de sécurité sont importants, surtout après qu’une série de vulnérabilités très médiatisées ont été rendues publiques au cours du second semestre de l’année dernière. Le Vulnérabilité BlueBorne a attaqué le protocole Bluetooth et a été corrigé dans le Correctifs mensuels de septembre 2017, KRACK cible une faiblesse du Wi-Fi WPA2 et a été corrigé décembre 2017, et les vulnérabilités Spectre/Meltdown ont été pour la plupart corrigées avec le Correctifs de janvier 2018. La correction de vulnérabilités telles que celles-ci nécessite généralement une coopération avec un fournisseur de matériel (tel que Broadcom et Qualcomm) car la vulnérabilité concerne un composant matériel comme la puce Wi-Fi ou Bluetooth ou le CPU. D'un autre côté, il existe des problèmes dans le système d'exploitation Android comme celui-ci attaque par superposition de messages toast qui nécessitent uniquement une mise à jour du framework Android pour être corrigés.
Chaque fois que Google déploie un correctif de sécurité mensuel, les fabricants d'appareils sont tenus de corriger TOUTES les vulnérabilités. indiqué dans le bulletin de sécurité du mois s'ils souhaitent affirmer que leur appareil est sécurisé jusqu'à ce correctif mensuel niveau. Chaque mois, il existe deux niveaux de correctifs de sécurité qu'un appareil peut respecter: le niveau de correctifs du 1er du mois ou du 5 du mois. Si un appareil indique qu'il exécute un niveau de correctif à partir du 1er du mois (par ex. Le 1er avril au lieu du 5 avril), cela signifie que la version contient tous les correctifs de framework ET de fournisseur de la version du mois dernier, ainsi que tous les correctifs de framework du dernier bulletin de sécurité. En revanche, si un appareil indique qu'il exécute un niveau de correctif à partir du 5 du mois (le 5 avril pour exemple), cela signifie qu'il contient tous les correctifs de framework et de fournisseur du mois dernier et de ce mois-ci. bulletin. Voici un tableau qui illustre la différence fondamentale entre les niveaux de correctifs mensuels :
Niveau de correctif de sécurité mensuel |
1er avril |
5 avril |
---|---|---|
Contient les correctifs du framework d'avril |
Oui |
Oui |
Contient les correctifs des fournisseurs d'avril |
Non |
Oui |
Contient les correctifs du framework de mars |
Oui |
Oui |
Contient les correctifs des fournisseurs de mars |
Oui |
Oui |
Vous savez probablement à quel point la situation des correctifs de sécurité est désastreuse dans l'écosystème Android. Le graphique ci-dessous montre que Google et Essential fournissent les mises à jour mensuelles de correctifs de sécurité les plus rapides, tandis que d'autres sociétés sont à la traîne. Cela peut prendre des mois pour qu'un OEM apporte les derniers correctifs à un appareil, par exemple comment le OnePlus 5 et OnePlus 5T a récemment reçu le Correctif de sécurité d'avril alors qu'ils étaient auparavant sur le patch de décembre.
État du correctif de sécurité Android en février 2018. Source: @SecX13
Le problème lié à la fourniture de mises à jour du correctif de sécurité Android n'est pas nécessairement que les OEM soient paresseux, car cela peut parfois échapper à leur contrôle. Comme nous l'avons mentionné précédemment, les mises à jour mensuelles des correctifs de sécurité nécessitent souvent la coopération d'un responsable matériel. fournisseur, ce qui peut entraîner des retards si le fournisseur n'est pas en mesure de suivre le correctif de sécurité mensuel bulletins. Pour lutter contre cela, il semble que Google pourrait commencer à séparer le niveau de correctif de sécurité Android Framework du niveau de correctif du fournisseur. (et éventuellement au niveau du chargeur de démarrage et du noyau) afin qu'à l'avenir, les OEM puissent fournir une sécurité de cadre purement Android mises à jour.
Mises à jour plus rapides des correctifs de sécurité Android pour les vulnérabilités du framework?
Un nouveau commettre est apparu dans le gerrit du projet Android Open Source (AOSP) qui fait allusion à un « correctif de sécurité du fournisseur » prop" qui serait défini dans les fichiers Android.mk chaque fois qu'une nouvelle version d'un appareil est en cours créé. Cette propriété s'appellera "ro.vendor.build.security_patch
" et sera analogue à "ro.build.version.security_patch
" qui existe actuellement sur tous les appareils Android pour spécifier le niveau mensuel du correctif de sécurité Android.
Cette nouvelle propriété nous indiquera plutôt le "VENDOR_SECURITY_PATCH
" niveau de l'appareil, qui peut ou non correspondre au niveau du correctif de sécurité Android Framework. Par exemple, un appareil peut fonctionner avec les derniers correctifs d'infrastructure d'avril 2018 ainsi que avec les correctifs du fournisseur de février 2018. En faisant la distinction entre les deux niveaux de correctifs de sécurité, il est possible que Google ait l'intention de laisser les OEM expédier le derniers correctifs de sécurité du système d'exploitation Android, même si les fournisseurs n'ont pas fourni de correctifs mis à jour pour ce correctif mensuel niveau.
Alternativement, Google peut simplement afficher le minimum des deux niveaux de correctifs (avec éventuellement les niveaux de correctifs du chargeur de démarrage et du noyau) afin de montrer plus précisément à l'utilisateur le correctif de sécurité sur lequel se trouve son appareil. Nous n'avons pas encore de confirmation sur l'intention derrière ce patch, mais nous espérons en savoir plus bientôt.
À tout le moins, cela sera utile à ceux d'entre nous qui Projet tripleImages système génériques (GSI) et autres ROM personnalisées basées sur AOSP, car souvent, les ROM personnalisées ne fournissent que des mises à jour du framework sans mettre à jour tous les correctifs du fournisseur, le chargeur de démarrage et les correctifs du noyau qui sont spécifiés dans un bulletin de sécurité mensuel, de sorte que la non-concordance provoque une confusion parmi les utilisateurs lorsqu'ils pensent qu'ils exécutent les derniers correctifs alors qu'en réalité leur appareil n'est que partiellement corrigé par rapport aux dernières sécurités mensuelles bulletin.