Le 5 décembre, quelqu’un du surnom IRC de [ubuntu] a rejoint le Discord de Pine64 #pinephone canal à travers un pont IRC. Dans l’esprit des traditions de cadeaux de décembre, ils ont présenté à leurs collègues utilisateurs de PinePhone une offre – un jeu « Serpent ». Quoi [ubuntu] soi-disant conçu avait le potentiel de devenir une application standard installée avec une petite mais dévouée communauté de fans, de moddeurs et de speedrunners.
Malheureusement, ce ne serait pas l’univers alternatif dans lequel nous vivons, et tout n’allait pas bien avec le partage du paquet avec un joyeux « hei gaiz je fais du serpent gaem voici le lien www2-pinephnoe-games-com-tz remplace le tiret par le point kthxbai » annonce. Étonnamment, c’était un cheval de Troie ! Sous les couches de Base64 et de Bashfuscator, nous rencontrerions du code shell qui pourrait se trouver dans la section « exemple d’utilisation » d’une entrée de thésaurus moderne pour le mot « encore« .
La partie malveillante du code n’est pas sophistiquée – à part l’obscurcissement, la chose la plus complexe à ce sujet est qu’il s’agit de Bash, un langage avec illisibilité intégré. En raison des privilèges root donnés lors de l’installation du paquet, le find-basé sur l’équivalent moderne de rm -rf /* n’a aucun mal à faire son sale boulot de nettoyer le système de fichiers, en exécutant un shred sur chaque fichier au préalable s’il est disponible pour contrecarrer la récupération de données. Quant à la partie bonus « Wipe the cellular modem’s firmware », elle exploite le CVE-2021-31698. Tout cela se passerait mercredi prochain à 20h00, avec une programmation effectuée par un systemd-soutenu cronjob.
[ubuntu] n’a pas partagé les sources, juste les binaires, emballés pour une installation facile sur Arch Linux. L’un des membres éminents de la communauté PinePhone a installé ce binaire et a apprécié la partie « jeu » de celui-ci, s’enquérant des plans pour le rendre open-source – étant rassuré par [ubuntu] que les sources finiraient par être publiées, « il suffit de les nettoyer ». Certains n’étaient pas si sûrs, arguant que les gens ne devraient pas sudo install-this jeux aléatoires sans lien de dépôt de code source. Les gens étaient en état d’alerte faible, et il y avait peut-être eu jusqu’à une douzaine d’installations avant qu’un membre prudent et avisé ne détargue le paquet et n’alerte les gens sur la base64 suspecte dans le .INSTALL script, environ une demi-journée plus tard.
Il s’agissait d’une attaque destructrice à petite échelle mais à effort élevé contre les utilisateurs de PinePhone, ciblant ceux qui utilisent spécifiquement Arch, d’ailleurs. L’expéditeur du logiciel malveillant a annoncé ses « efforts de développement de jeux » avant la publication, est resté dans la chaîne pour faire quelques petites discussions et questions-réponses, et par ailleurs, il ne se distinguait pas rapidement d’un développeur moyen venant bénir une plate-forme potentielle avec sa première application. Surtout, le jeu Snake était bien réel – il n’est pas clair si le code a pu être volé dans un projet open source, mais vous ne le distingueriez pas d’un jeu Snake non malveillant. Il est curieux que le package ne semble pas envoyer de données privées à des serveurs (ou crypter des fichiers, ou vous forcer à regarder des publicités similaires à des jeux mobiles modernes) – il le pourrait facilement, mais ce n’est pas le cas.
Avec la quantité de travail effectué sur la rétro-ingénierie du modem cellulaire PinePhone, il est étrange que le malware tire parti des CVE découverts parallèlement à cet effort. Vous ne vous attendriez pas à ce qu’un virus de téléphone typique réussisse un tour de brique de modem cellulaire, étant donné la fragmentation du monde Android et l’obscurcissement du monde Apple. Curieusement, le micrologiciel open source développé par la communauté pour le modem cellulaire Quectel est immunisé contre le bogue exploité et est globalement plus complet, mais Pine64 est tenu d’expédier le micrologiciel propriétaire exploitable par défaut pour des raisons de conformité réglementaire – les conséquences pour sortir des sentiers battus sont assez drastiques, selon une source Pine64.
Des questions me viennent à l’esprit. PinePhone est-il une plateforme sûre ? Mon point de vue est – « oui » par rapport à tout le reste, « non » si vous vous attendez à être inconditionnellement sûr lorsque vous l’utilisez. Dans l’état actuel des choses, c’est une plate-forme qui nécessite explicitement votre compréhension de ce que vous lui demandez de faire.
Avec plus de distributions de système d’exploitation disponibles que n’importe quel autre téléphone moderne pourrait se vanter d’être capable de prendre en charge, vous pouvez utiliser quelque chose comme Ubuntu Touch pour une expérience fluide. Vous disposez globalement de plus de puissance pour assurer votre sécurité lorsque vous utilisez un PinePhone. Les personnes qui comprennent le potentiel de ce pouvoir sont le genre de personnes qui contribuent au projet PinePhone, c’est pourquoi il est triste qu’elles aient été spécifiquement ciblées lors de cet événement.
D’autres plates-formes résolvent ces problèmes de différentes manières, où seule une partie de la solution est un logiciel et un travail architectural réels effectués par la plate-forme, et une autre consiste à former les utilisateurs. Par exemple, vous n’êtes pas censé utiliser un magasin d’applications tiers (ou un micrologiciel, un chargeur ou une méthode de prise en main) sur votre iPhone, et Android a des cases à cocher en mode développeur que vous pouvez atteindre si vous recréez le troisième mouvement de « Vol du Bumblebee » avec votre doigt dans l’écran des paramètres. La méthode de l’écosystème Linux consiste à s’appuyer sur le noyau pour fournir des primitives de sécurité de bas niveau fiables, mais la responsabilité incombe aux distributions d’incorporer des logiciels et des configurations qui utilisent ces primitives.
Je dirais que les distributions Linux mobiles devraient également définir et maintenir leur position sur l’échelle de « sécurité », en élaborant sur les mesures qu’elles prennent lorsqu’il s’agit d’applications tierces. Il y a six mois, alors que je préparais un résumé sur les différents systèmes d’exploitation disponibles pour PinePhone et leurs positions sur la sécurité des applications, cela m’a pris beaucoup plus de temps que je ne me sentirais à l’aise d’avoir quelqu’un pour une tâche d’une telle importance.
L’essentiel des conseils donnés aux nouveaux arrivants est « n’installez pas de logiciels aléatoires auxquels vous ne pouvez pas faire confiance ». Bien que ce soit un bon conseil en soi, vous auriez raison de le souligner – un jeu ne devrait pas être capable d’effacer votre système, et « obtenir de meilleurs utilisateurs » n’est généralement pas une stratégie viable. Tout stratège en sécurité qui nie la faillibilité humaine inhérente ne réussira pas dans le monde moderne, alors voyons ce que nous pouvons faire en plus de la partie habituelle « éduquer les utilisateurs ». Comme d’habitude, il y a un XKCD pour commencer.
Même être capable d’écrire dans un fichier arbitraire appartenant à l’utilisateur sur un système Linux est un « jeu terminé ». Dis, dans $HOME/.bashrc, vous pouvez créer un alias sudo à stdin-recording-app sudo et récupérer le mot de passe de l’utilisateur la prochaine fois qu’ils s’exécutent sudo dans la borne. .bashrc n’est pas non plus le seul fichier accessible en écriture par l’utilisateur à être exécuté régulièrement. Alors que des solutions de sandboxing sont développées pour résoudre ce genre de problèmes, le travail est lent et les aspects de celui-ci ne sont pas triviaux, généralement mieux décrits comme « liste blanche dynamique et complexe ».
Un conseil couramment distribué est « si vous ne pouvez pas lire le code et comprendre ce qu’il fait, ne l’exécutez pas », vraisemblablement, censé s’appliquer aux packages et aux bases de code plus longs qu’un projet de week-end. Ironiquement, cela place Linux dans une situation désavantageuse injustifiée par rapport aux systèmes à source fermée. La méthode de distribution d’applications « partager un fichier .exe » est plus ancienne que je ne le suis personnellement, et c’est toujours une méthode acceptée de partage de logiciels que quelqu’un a écrit pour Windows, l’UAC étant devenu une autre boîte de clic réflexive. Encore une fois, mettre plus d’un fardeau de sécurité sur les épaules des utilisateurs de Linux est facile mais stupide.
Le partage du code source aiderait-il même dans la situation des logiciels malveillants ? Non! En fait, attacher un lien à un référentiel de code source aiderait [ubuntu] rendre la distribution du malware plus plausible. Lorsque vous publiez un package, même sur des plates-formes supposées réputées, il est rarement possible de vérifier si le code à l’intérieur du package que vous téléchargez correspond au code de votre référentiel.
C’est vrai pour de nombreux endroits – les versions de GitHub et GitLab, DockerHub, NPM, RubyGems, les magasins d’extensions de navigateur, PyPi et même certains référentiels Linux supposés sûrs, comme F-droid, sont vulnérables. Fournir du code source avec un package malveillant ajoute de la légitimité et enlève des incitations aux personnes qualifiées pour vérifier le binaire en premier lieu – hé, le code est déjà là pour voir ! Si [ubuntu] fait juste cela, peut-être parlerions-nous de cet incident quelques jours plus tard et sur un ton plus sombre. Les attaques de la chaîne d’approvisionnement sont la nouvelle tendance en 2023 et 2021.
De nombreux systèmes de sécurité que nous avons mis en place sont basés sur la confiance. La signature du paquet est la plus importante, où une signature cryptographique d’une personne responsable de la maintenance du paquet est utilisée pour établir « la personne X se porte garante de l’innocuité de ce paquet ». HTTPS est une autre technologie basée sur la confiance que nous utilisons quotidiennement, même si, en réalité, vous faites plus confiance au mainteneur du magasin de clés de votre navigateur ou de votre système d’exploitation qu’à tout propriétaire de clé particulier.
Lorsqu’elle est appliquée dans la mesure où elle nous rend réellement plus sûrs, la technologie basée sur la confiance impose un fardeau aux nouveaux développeurs qui n’ont pas de prouesses sociales et cryptographiques raisonnablement raffinées. Cependant, alors que nous sommes souvent confrontés à un manque de documentation, à des API incomplètes et à des bibliothèques non testées, devrions-nous vraiment augmenter davantage la charge ? Ce n’est peut-être pas si mal.
La technologie de signature basée sur la confiance que je mentionne souvent est appliquée aux images du système d’exploitation que vous téléchargez généralement pour amorcer votre PC (ou votre téléphone !) avoir de telles signatures, ce qui m’a déçu, car la plupart des grandes distributions pour PC les fournissent et je m’attendais à ce que l’espace téléphonique Linux ne soit pas différent, et ne pas avoir de signatures peut être désastreux. Un certain nombre de fonctionnalités liées à la sécurité comme celle-ci sont disponibles, mais ne sont pas utilisées car elles nécessitent un effort non négligeable pour s’intégrer à l’infrastructure d’un projet s’il n’a pas été conçu dans un souci de sécurité dès le départ ou pour créer un charge supplémentaire pour les développeurs.
La communauté PinePhone a mis en place de nouvelles règles, certaines canalisant vers le territoire de l’« automatisation ». Cela aidera peut-être un type spécifique de problème à avoir moins d’impact à l’avenir – même si je dirais que la mémoire institutionnelle devrait jouer un rôle plus important à cet égard. Méfiez-vous des Grecs portant des cadeaux… jusqu’à ce qu’ils apprennent à contourner les heuristiques de votre bot Discord ? J’ai déjà, par exemple. Il s’agit d’un sujet monumental avec des racines au-delà du Great PinePhone Snake Malware de 2021, et cet article ne traite même pas autant de cela que de vous aider à comprendre ce qui se passe avec les aspects importants de la sécurité Linux, ou peut-être même la sécurité de tous les open logiciel source.
Pour moi, ce malware frappe les notes « inévitable » et « ajustement de cap » et « douleurs de croissance ». Des discussions sur la confiance et les logiciels ont lieu dans chaque communauté qui s’agrandit suffisamment.
Nous devons reconnaître que les logiciels malveillants Linux sont possibles et peuvent éventuellement se généraliser, et une discussion saine sur la manière de les arrêter est cruciale. Linux n’a toujours effectivement aucun malware, mais le jour où nous ne pouvons plus l’affirmer approche de nous.
Je ne suis pas sûr de l’ajustement exact dont nous avons besoin. Comprendre le système va un long chemin, mais les mesures de sécurité que nous attendons ne peuvent exclure les utilisateurs expérimentés et les développeurs débutants. Techniquement, qu’il s’agisse de conteneurisation, de sandboxing, d’infrastructure basée sur la confiance ou de langages sécurisés en mémoire, nous devons savoir ce dont nous avons besoin avant de savoir quoi demander.
Je tiens à remercier [Lukasz] de la communauté Pine64 et [Hacker Fantastic] pour obtenir de l’aide sur les vérifications de la situation du PinePhone.
