Premier point, pour ce que ça vaut, les téléphones et tablettes Archos ont été protégé contre ce malware dans les 36 heures après l'annonce de Kryptowire du 15 novembre.
C'est l'occasion pour moi d'essayer d'expliquer ici l'écosystème Android.
Mon commentaire est très touffu, mais j'espère qu'il est quand même intéressant.
L'architecture commerciale d'Android
Voici une petite explication rapide de comment ce genre de choses peut arriver.
Android est fourni par Google en open-source en Apache2 (BSD-like), sous le nom de AOSP (Android OpenSource Project). Mais contrairement à ce qu'on pourrait par exemple voir sous Windows, Google n'impose pas d'utiliser sa propre version, il existe donc un très grand nombre dérivés.
Globalement il existe une poignée de concepteurs de puces capables de faire des puces tout intégré (WiFi/4G/Bluetooth/GPU/audio/....) de téléphones Android.
Ces concepteurs font donc une version modifiée d'Android pour inclure les drivers associé à leur puces, et surtout font une quantité assez faramineuse de modifications en tout genre. Par exemple, à une époque il s'agissait d'ajouter le support de multiples SIMs dans un téléphone, mais il peut aussi s'agir de requêtes faites par des opérateurs (par exemple afficher 4G+ dans les icônes, ou HD pour les codecs audio ""HD"").
Déjà à cette étape, la plupart des concepteurs de puces laissent des binaires.
Ensuite, il existe deux cas.
Soit il s'agit d'un gros constructeur, pour un produit vendu par millions.
Auquel cas, ce constructeur récupère directement l'Android modifié du concepteur de puces. (À ma connaissance, les exceptions ici sont Samsung et Huawei parce qu'ils sont leurs propres concepteurs de puces, et Sony)
Soit il s'agit de plus petits produits, auquel cas on arrive á une nébuleuse qu'on appellera concentrateur électronique. Il va acheter les puces aux concepteurs par millions, et va faire des PCBs avec ces puces et les différents éléments "utiles" (RAM/stockage, accéléromètre, les différents connecteurs, PMIC, ...) aussi par million.
Dans ce cas, le concentrateur va modifier la version d'Android fournie par le concepteur de puces pour inclure les drivers des composants qu'il vient de souder. Ici aussi, il leur arrive d'être plus imaginatif et faire des modifications plus évoluée que juste rajouter des drivers.
Alors, le constructeur "final" du téléphone va récupérer cette version d'Android.
Il existe donc quatre intermédiaires entre la version open-source et la version finale, et l'utilisateur.
À chacune de ces étapes, il y a bien évidement des sous-traitants en pagaille. Dans ce cas ici présent, il s'agit d'ADUPS. Sur le papier il fournit un système de mise-à-jour en-ligne, ce qui parait légitime.
Il se trouve que cette application s'avère malveillante.
Mais il ne faut pas se leurrer, il y a probablement vingt entreprises qui ont la possibilité de mettre un malware pour un constructeur de téléphone.
Celui-ci a été trouvé presque par un concours de circonstance:
Les chercheurs en sécurité ont tendance à toujours utiliser des téléphones haut de gamme, et rentrent donc dans la catégorie des téléphones produits par millions, pour lesquels un soin tout particulier a été apporté.
Ici, le smartphone "original" avait un prix réduit en échange d'un peu de publicité affichée par Amazon, c'est pour ça qu'il a été acheté par ce chercheur.
Au final, ce chercheur a trouvé un malware qui touche 1 Milliard de téléphones.
Mais étant donné le nombre d'intermédiaires, de très nombreux malwares passent à l'heure actuelle à la trappe.
Les failles de sécurité
Un autre point important à considérer en terme de sécurité est l'application des correctifs de sécurité.
Google publie ses patchs de sécurité pour AOSP mensuellement.
Si vous avez bien suivi le paragraphe précédent, vous pouvez tenter de répondre à la question suivante:
Combien de temps faut-il pour que les patchs de sécurité de Google arrivent dans la main des clients?
...
Oui, très longtemps.
J'ai dit précédemment que le chercheur n'a quasiment que eu à se baisser pour trouver des problèmes.
Similairement, il y a deux ans, Android n'était pas vraiment audité, et les chercheurs n'ont eu qu'à se baisser pour trouver des failles.
De nos jours Android est bien mieux fortifié, mais il existe encore très régulièrement des failles critiques (deux le mois dernier: http://source.android.com/security/bulletin/2016-11-01.html ).
Et Google n'est pas connu pour faire du code complètement troué, les vingt sous-traitants intermédiaires font probablement du code bien pire que Google...
Android open-source
Comme signalé plus haut, il y a pas mal de solutions Quick&Dirty disponibles pour "libérer" son téléphone, qu'on appelle communément des ROMs.
Ici, tous les drivers restent sous forme binaire, et il y a évidement un très grand nombre de blobs.
À noter qu'un grand acteur parmi les ROMs open-source est Qualcomm. En effet, ils publient les sources de leurs modifications à Android, et d'une partie de leur drivers.
Sinon, pour des plus puristes, il existe effectivement Replicant, comme tu le signales justement.
Je connais très peu Replicant, néanmoins j'en sais juste qu'ils font un travail assez remarquable, mais se limitent parfois un peu trop à mon avis. (cf l'interdiction de firmwares wifi proprio)
Android sur un kernel upstream
Maintenant, un autre point sur lequel je veux discuter est sur l'upstream. Il s'agit principalement de Linux, mais pas que.
Android se base sur un grand nombre d'abstraction matérielle-logicielle en espace utilisateur. Au moment de leur création, l'équivalent upstream n'existait pour ainsi dire pas.
Mais ce n'est plus entièrement vrai de nos jours. Si on prend une tablette pour un usage simple, il existe une interface "standard GNU/Linux" pour tout ce dont Android a besoin.
"Le chaînon manquant" est donc d'avoir des HALs Android, utilisant par derrière des interfaces standard.
Ici, il y a beaucoup de travail, mais il manque d'une grande centralisation!
Par exemple, une des abstractions nécessaires est celle permettant de faire le rendu 2D, il s'agit de hwcomposer.
La fonctionnalité Linux équivalente la plus proche (sans être strictement équivalente) est drm.
Il existe drm_hwcomposer qui remplit donc les fonctionnalités de cette HAL par DRM. La blague? J'arrive même plus à compter combien de versions différentes il existe. (Je compte celle utilisée par freedreno, celle utilisée par Google dans ChromeOS, celle d'Intel, celle d'Android-x86, et je sais que certains constructeurs en ont aussi des versions internes).
Si on prend l’accéléromètre (qui permet principalement de trouver l'orientation de l'écran), il existe une interface standard, iio.
À ma connaissance, il existe une abstraction pour ça, celle d'Intel.
On peut parler du rendu 3D, ici il n'y a pas vraiment d'API à proprement parler, mais Mesa est maintenant capable de cibler Android.
À noter que ici, j'attends une poussée importante grâce à la possibilité d'exécuter des applications Android sur ChromeOS.
ChromeOS se base en très grande partie sur des APIs existantes dans Linux upstream, et leur manière d'exécuter des applications Android consiste à mettre Android dans un LXC.
Néanmoins, il existe de nombreux domaines pour lesquels il n'existe pas d'API standard GNU/Linux:
- la communication avec la partie téléphonie/4G
- des fonctionnalité basses consommation, par exemple le "Ok Google" alors que le téléphone est en veille
- des fonctionnalités WiFi avancées, par exemple la mesure du temps-de-vol
Des téléphones et tablettes Android avec un kernel upstream
J'ai parlé de l'étape "Si j'ai un kernel mainstream qui marche, alors je peux avoir Android", parlons de l'inverse: "j'ai une tablette Android, est-ce que je peux avoir un kernel mainstream?"
Ici, les choses avancent globalement dans le bon sens.
Je pense que ce mouvement est principalement lié à Google, mais pas pour Android.
Pour ChromeOS et pour Android IoT, Google requiert (Source: https://lwn.net/Articles/706597/) de la part des concepteurs de puce d'au moins essayer de merger leurs drivers en mainstream.
De manière plus ou moins corrélée, on a pu voir sur la LKML, s'agiter un certain nombre de constructeurs pour faire inclure leur changements (Qualcomm, Rockchip, Mediatek).
On arrive à un point où on peut trouver des tablettes existant pour de vrai sur le marché qui ont la quasi-intégralité de leur drivers mainstreamé.
Je prends par exemple la tablette Archos 101 Oxygen (le concepteur de puces ici est Rockchip)
Il est possible de lui mettre un bootloader u-boot mainstream, kernel mainstream, driver wifi mainstream, driver GPU 2D mainstream, accéléromètre mainstream, écran mainstream (en trichant un peu).
Le décodage de vidéo matériel, bien que non mainstreamé (mais soumis à la LKML), est disponible en libre par des APIs standard (VA-API, VDPAU et gstreamer).
Principale ombre au tableau ici, le driver Lima (implémentation libre pour GPU 3D Mali) qui s'est fait tué dans l'oeuf.
Il faut aussi évidement parler de l'énorme travail de Free-Electrons pour mainstreamer un support Allwinner.
Il me semble qu'ici aussi, on a un support suffisant pour être utilisable de certaines tablettes Allwinner.
# My 2 cents
Posté par Ph Husson (site web personnel) . En réponse au journal Des p'tits trous, des p'tits trous, toujours des p'tits trous. Évalué à 10.
Sommaire
Premier point, pour ce que ça vaut, les téléphones et tablettes Archos ont été protégé contre ce malware dans les 36 heures après l'annonce de Kryptowire du 15 novembre.
C'est l'occasion pour moi d'essayer d'expliquer ici l'écosystème Android.
Mon commentaire est très touffu, mais j'espère qu'il est quand même intéressant.
L'architecture commerciale d'Android
Voici une petite explication rapide de comment ce genre de choses peut arriver.
Android est fourni par Google en open-source en Apache2 (BSD-like), sous le nom de AOSP (Android OpenSource Project). Mais contrairement à ce qu'on pourrait par exemple voir sous Windows, Google n'impose pas d'utiliser sa propre version, il existe donc un très grand nombre dérivés.
Globalement il existe une poignée de concepteurs de puces capables de faire des puces tout intégré (WiFi/4G/Bluetooth/GPU/audio/....) de téléphones Android.
Ces concepteurs font donc une version modifiée d'Android pour inclure les drivers associé à leur puces, et surtout font une quantité assez faramineuse de modifications en tout genre. Par exemple, à une époque il s'agissait d'ajouter le support de multiples SIMs dans un téléphone, mais il peut aussi s'agir de requêtes faites par des opérateurs (par exemple afficher 4G+ dans les icônes, ou HD pour les codecs audio ""HD"").
Déjà à cette étape, la plupart des concepteurs de puces laissent des binaires.
Ensuite, il existe deux cas.
Soit il s'agit d'un gros constructeur, pour un produit vendu par millions.
Auquel cas, ce constructeur récupère directement l'Android modifié du concepteur de puces. (À ma connaissance, les exceptions ici sont Samsung et Huawei parce qu'ils sont leurs propres concepteurs de puces, et Sony)
Soit il s'agit de plus petits produits, auquel cas on arrive á une nébuleuse qu'on appellera concentrateur électronique. Il va acheter les puces aux concepteurs par millions, et va faire des PCBs avec ces puces et les différents éléments "utiles" (RAM/stockage, accéléromètre, les différents connecteurs, PMIC, ...) aussi par million.
Dans ce cas, le concentrateur va modifier la version d'Android fournie par le concepteur de puces pour inclure les drivers des composants qu'il vient de souder. Ici aussi, il leur arrive d'être plus imaginatif et faire des modifications plus évoluée que juste rajouter des drivers.
Alors, le constructeur "final" du téléphone va récupérer cette version d'Android.
Il existe donc quatre intermédiaires entre la version open-source et la version finale, et l'utilisateur.
À chacune de ces étapes, il y a bien évidement des sous-traitants en pagaille. Dans ce cas ici présent, il s'agit d'ADUPS. Sur le papier il fournit un système de mise-à-jour en-ligne, ce qui parait légitime.
Il se trouve que cette application s'avère malveillante.
Mais il ne faut pas se leurrer, il y a probablement vingt entreprises qui ont la possibilité de mettre un malware pour un constructeur de téléphone.
Celui-ci a été trouvé presque par un concours de circonstance:
Les chercheurs en sécurité ont tendance à toujours utiliser des téléphones haut de gamme, et rentrent donc dans la catégorie des téléphones produits par millions, pour lesquels un soin tout particulier a été apporté.
Ici, le smartphone "original" avait un prix réduit en échange d'un peu de publicité affichée par Amazon, c'est pour ça qu'il a été acheté par ce chercheur.
Au final, ce chercheur a trouvé un malware qui touche 1 Milliard de téléphones.
Mais étant donné le nombre d'intermédiaires, de très nombreux malwares passent à l'heure actuelle à la trappe.
Les failles de sécurité
Un autre point important à considérer en terme de sécurité est l'application des correctifs de sécurité.
Google publie ses patchs de sécurité pour AOSP mensuellement.
Si vous avez bien suivi le paragraphe précédent, vous pouvez tenter de répondre à la question suivante:
Combien de temps faut-il pour que les patchs de sécurité de Google arrivent dans la main des clients?
...
Oui, très longtemps.
J'ai dit précédemment que le chercheur n'a quasiment que eu à se baisser pour trouver des problèmes.
Similairement, il y a deux ans, Android n'était pas vraiment audité, et les chercheurs n'ont eu qu'à se baisser pour trouver des failles.
De nos jours Android est bien mieux fortifié, mais il existe encore très régulièrement des failles critiques (deux le mois dernier: http://source.android.com/security/bulletin/2016-11-01.html ).
Et Google n'est pas connu pour faire du code complètement troué, les vingt sous-traitants intermédiaires font probablement du code bien pire que Google...
Android open-source
Comme signalé plus haut, il y a pas mal de solutions Quick&Dirty disponibles pour "libérer" son téléphone, qu'on appelle communément des ROMs.
Ici, tous les drivers restent sous forme binaire, et il y a évidement un très grand nombre de blobs.
À noter qu'un grand acteur parmi les ROMs open-source est Qualcomm. En effet, ils publient les sources de leurs modifications à Android, et d'une partie de leur drivers.
Sinon, pour des plus puristes, il existe effectivement Replicant, comme tu le signales justement.
Je connais très peu Replicant, néanmoins j'en sais juste qu'ils font un travail assez remarquable, mais se limitent parfois un peu trop à mon avis. (cf l'interdiction de firmwares wifi proprio)
Android sur un kernel upstream
Maintenant, un autre point sur lequel je veux discuter est sur l'upstream. Il s'agit principalement de Linux, mais pas que.
Android se base sur un grand nombre d'abstraction matérielle-logicielle en espace utilisateur. Au moment de leur création, l'équivalent upstream n'existait pour ainsi dire pas.
Mais ce n'est plus entièrement vrai de nos jours. Si on prend une tablette pour un usage simple, il existe une interface "standard GNU/Linux" pour tout ce dont Android a besoin.
"Le chaînon manquant" est donc d'avoir des HALs Android, utilisant par derrière des interfaces standard.
Ici, il y a beaucoup de travail, mais il manque d'une grande centralisation!
Par exemple, une des abstractions nécessaires est celle permettant de faire le rendu 2D, il s'agit de hwcomposer.
La fonctionnalité Linux équivalente la plus proche (sans être strictement équivalente) est drm.
Il existe drm_hwcomposer qui remplit donc les fonctionnalités de cette HAL par DRM. La blague? J'arrive même plus à compter combien de versions différentes il existe. (Je compte celle utilisée par freedreno, celle utilisée par Google dans ChromeOS, celle d'Intel, celle d'Android-x86, et je sais que certains constructeurs en ont aussi des versions internes).
Si on prend l’accéléromètre (qui permet principalement de trouver l'orientation de l'écran), il existe une interface standard, iio.
À ma connaissance, il existe une abstraction pour ça, celle d'Intel.
On peut parler du rendu 3D, ici il n'y a pas vraiment d'API à proprement parler, mais Mesa est maintenant capable de cibler Android.
À noter que ici, j'attends une poussée importante grâce à la possibilité d'exécuter des applications Android sur ChromeOS.
ChromeOS se base en très grande partie sur des APIs existantes dans Linux upstream, et leur manière d'exécuter des applications Android consiste à mettre Android dans un LXC.
Néanmoins, il existe de nombreux domaines pour lesquels il n'existe pas d'API standard GNU/Linux:
- la communication avec la partie téléphonie/4G
- des fonctionnalité basses consommation, par exemple le "Ok Google" alors que le téléphone est en veille
- des fonctionnalités WiFi avancées, par exemple la mesure du temps-de-vol
Des téléphones et tablettes Android avec un kernel upstream
J'ai parlé de l'étape "Si j'ai un kernel mainstream qui marche, alors je peux avoir Android", parlons de l'inverse: "j'ai une tablette Android, est-ce que je peux avoir un kernel mainstream?"
Ici, les choses avancent globalement dans le bon sens.
Je pense que ce mouvement est principalement lié à Google, mais pas pour Android.
Pour ChromeOS et pour Android IoT, Google requiert (Source: https://lwn.net/Articles/706597/) de la part des concepteurs de puce d'au moins essayer de merger leurs drivers en mainstream.
De manière plus ou moins corrélée, on a pu voir sur la LKML, s'agiter un certain nombre de constructeurs pour faire inclure leur changements (Qualcomm, Rockchip, Mediatek).
On arrive à un point où on peut trouver des tablettes existant pour de vrai sur le marché qui ont la quasi-intégralité de leur drivers mainstreamé.
Je prends par exemple la tablette Archos 101 Oxygen (le concepteur de puces ici est Rockchip)
Il est possible de lui mettre un bootloader u-boot mainstream, kernel mainstream, driver wifi mainstream, driver GPU 2D mainstream, accéléromètre mainstream, écran mainstream (en trichant un peu).
Le décodage de vidéo matériel, bien que non mainstreamé (mais soumis à la LKML), est disponible en libre par des APIs standard (VA-API, VDPAU et gstreamer).
Principale ombre au tableau ici, le driver Lima (implémentation libre pour GPU 3D Mali) qui s'est fait tué dans l'oeuf.
Il faut aussi évidement parler de l'énorme travail de Free-Electrons pour mainstreamer un support Allwinner.
Il me semble qu'ici aussi, on a un support suffisant pour être utilisable de certaines tablettes Allwinner.