Sommaire
Dans un ordinateur, le rôle du processeur est d'exécuter les instructions qui lui sont présentées, afin, on l'espère, de faire fonctionner un programme, si possible sans trop de bogues… Je ne pense pas apprendre grand chose au lectorat de LinuxFR là-dessus. Dans ce journal, je veux par contre m'attarder sur la confiance que nous portons sur cet élément, qui in fine décide du comportement de notre ordinateur, et sur les raisons pour lesquelles je crois fermement qu'il faudrait sérieusement réfléchir aux alternatives aux systèmes actuels.
De la communication téléphonique…
Pendant mes études, j'ai longtemps travaillé au service téléphonique d'une compagnie de taille respectable (plusieurs milliers d'appels par jour). Une des choses qui m'a de prime abord intrigué est la manière dont les personnes sourdes/muettes/malentendantes pouvaient passer un coup de fil. Je ne m'étais jamais réellement posé la question, jusqu'à ce que je reçoive un appel d'une de ces personnes. En bref, ils utilisent un service de relais (ou en tout cas, c'est comme ça que ça s'appelle au Québec) : la personne muette écrit ce qu'elle veut dire, et un opérateur l'énonce. Lorsque je réponds, l'opérateur l'écrit afin que la personne sourde puisse le lire. La discussion se construit alors par personne interposée. C'est assez déroutant, particulièrement lorsque l'opérateur vous relaie les insultes et admonestations de votre interlocuteur sur un ton on ne peut plus professionnel.
Une question plus sérieuse demeure : comment la personne malentendante fait-elle pour s'assurer que ce qu'elle écrit est réellement ce qui m'est dit par l'opérateur? Comment est-elle certaine que ce qu'elle lit est réellement ce que j'ai dit? Et puis, même si les paroles sont correctement transmises d'un côté comme de l'autre, comment s'assurer que l'opérateur n'en garde pas une trace, par exemple lorsqu'il s'agit de sujets privés ou sensibles?
En bref, le malentendant possède, comme tout citoyen, le droit à la vie privée, le droit d'association et tous les autres qui en découlent, mais doit faire confiance à un tiers pour le mettre en application dans bien des cas.
aux systèmes informatiques
Ces personnes ne pourraient-elles pas par ailleurs utiliser d'autres moyens de communication, tels que les courriels, que l'on peut chiffrer et signer? Pas tout à fait : le problème de l'opérateur téléphonique est exactement celui des logiciels propriétaires (ou privateurs, pour les puristes). L'utilisateur doit impérieusement faire confiance en tout temps au logiciel qu'il exécute. Rien ne sert de chiffrer un courriel si c'est pour voir cette protection complètement contournée par l'OS…
À cela, on peut répondre que c'est une des raisons d'être des logiciels libres : pouvoir se servir d'outils dont on n'a pas à faire aveuglément confiance. Oui, mais chaque brique propriétaire d'un système libre est problématique :
- Un simple logiciel non libre, même sans droits particuliers, peut déjà causer beaucoup de dégâts. N'oublions pas qu'il a par défaut accès à tous vos fichiers personnels, puisqu'il s'exécute sous votre compte utilisateur…
- Même si on retire tous ces logiciels non libres, il reste encore la question des firmwares : à quoi bon chiffrer ses messages si la carte réseau peut faire un DMA et envoyer des données sensibles d'elle-même…
- Même si on retire tous ces firmwares (ce que font les distributions approuvées par GNU), il reste encore la question du BIOS/UEFI. Ces programmes étant exécutés avant l'OS, il est trivial de mettre en place une backdoor généralisée contre laquelle l'OS ne pourra rien faire…
- Si on remplace le BIOS par une version libre (par exemple coreboot ou libreboot), est-ce terminé? Sommes-nous à l'abri? Hélas, non.
Le microcode
Dans les débuts de l'informatique, les processeurs étaient réellement un simple ensemble de circuits logiques, assemblage de transistors connectés de manière physique entre eux, qui réalisaient diverses tâches. Cependant, avec la complexification des jeux d'instructions et des procédés de lithographie, il a fallu passer à un autre mode de conception : l'utilisation d'un microcode capable de traduire une instruction assembleur "complexe" en une suite de petites microinstructions élémentaires, qui, elles, sont implémentées physiquement.
D'un point de vue ingénierie, c'est une excellente idée, et virtuellement tous les processeurs modernes utilisent ce genre d'architecture. Toutefois, cela soulève un problème, puisque ce microcode est aussi un programme. Pour la petite histoire, certains anciens systèmes stockaient directement le microcode en mémoire, comme un programme conventionnel. Or, la confiance en ce programme est cruciale, puisque c'est lui qui contrôle tout le reste. À quoi bon chiffrer nos données si le microcode est programmé de telle sorte à introduire une faille systématique dans les calculs…
Le problème est pire qu'on peut le penser sur nos machines usuelles. Les deux fabricants principaux de processeurs x86 (Intel et AMD) intègrent tous deux des technologies allant bien plus loin que le microcode, et qui sont absolument nécessaires au fonctionnement du processeur. Je cite (et traduis librement) le message lié :
Ces firmwares signés, propriétaires et binaires doivent être exécutés avant même la fin d'une opération reset (AMD), ou sont en mesure de redémarrer électriquement (hard reset) le système en entier s'ils n'ont pas été exécutés après 30 minutes d'activité (Intel). Ces blobs binaires sont continuellement en service lorsque le système est en fonction, et, dans le cas d'Intel, continuent à fonctionner même lorsque la machine est éteinte, mais a accès à une source d'énergie (batterie ou prise électrique). Ces systèmes ont accès sans restriction à l'entièreté de la mémoire et des périphériques, ce qui leur confère en pratique un niveau de privilège encore plus élevé que le noyau du système d'exploitation lui-même.
(je vous invite à lire le reste du message si vous êtes intéressés, il est très instructif)
Pourquoi s'en soucie-t-on aussi peu
Il est étonnant qu'à un moment où on parle autant de libertés numériques, de vie privée sur Internet et de sécurité informatique, on discute aussi peu de la confiance absolue que nous accordons aux "opérateurs" de nos logiciels. La plupart du temps, les projets d'ordinateurs entièrement libres sont vus comme des lubies de geeks barbus qui n'ont rien d'autre à faire (à part installer GNU/Hurd peut-être), ou d'activité extrémistes qui voient la NSA dans leurs céréales du matin.
C'est dommage, car ce problème est absolument crucial. Il permet potentiellement (nous n'en savons rien) une exploitation de nos données, y compris à distance, et quasi-impossible à détecter. Bien évidemment, si de telles failles existent, leurs créateurs n'auront pas été stupides, et ne les auront pas codées de façon à envoyer 1 Go de données quotidienne à nsa.gov.us, toujours à la même heure… Par contre, faire passer des informations sensibles en utilisant des bits inutilisés ou anodins de paquets TCP/IP, et ce seulement lorsqu'un certain pattern de bits très particulier est rencontré en mémoire, là c'est une autre paire de manche à détecter, surtout si on rappelle que l'OS ne voit rien et ne peut rien voir : même en utilisant un outil comme Wireshark, cette faille ne serait pas détectable sur un seul ordinateur puisque les données sont modifiées après le traitement par l'OS…
Il existe des initiatives d'architectures CPU libres (RISCV par exemple) ou de portables capables de fonctionner sans (on le croit) aucun blob binaire, y compris au niveau du microcode (par exemple le Chromebook Asus C201, au support encore extrêmement préliminaire), mais, encore une fois, ces efforts sont très peu soutenus en regard du support apporté aux logiciels libres. Il y a d'ailleurs une bonne discussion sur HackerNews à ce sujet. Je ne suis pas utopiste et réalise fort bien qu'il y a toute une question de capacité de production et de financement derrière tout ça, mais ça ne m'empêche pas pour autant de penser que c'est un problème qui mérite clairement que l'on s'y attarde avec beaucoup plus d'attention que l'attitude désinvolte actuelle.
Amis LinuxFriens qui tenez à votre vie privée, êtes-vous certain que la confiance que vous accordez à votre "opérateur" est judicieusement placée?
# Intéressant
Posté par Marotte ⛧ . Évalué à 4. Dernière modification le 05 avril 2016 à 18:36.
Je pense que ce genre de code malicieux doit pouvoir être détecté à l’analyseur logique et que certains ne se privent pas d’y jeter un œil.
Comme quand tu n’as pas le code source d’un OS… tu regardes ce qu’il fait, de l’extérieur.
Toujours est-il que l’introduction d’une telle fonctionnalité dans un lot particulier, destiné à un marché particulier… disons qu’on s’arrange pour que ce soit telles personnes et pas d’autres qui utilisent ces processeurs… ça me parait plausible. Je pense que les fondeurs sont capables de le faire et que des agences gouvernementales ont déjà eu l’idée, voir l’ont appliquée (ya déjà eu le cas sur des routeurs Cisco si je ne m’abuse, mais au niveau de l’OS je crois).
À grande échelle et de manière généralisée je n’y crois pas. Ça aurait fini par se voir.
[^] # Re: Intéressant
Posté par Kalenx . Évalué à 8.
Je ne pense pas non plus que chaque processeur envoie périodiquement un rapport concernant son utilisation, ce serait effectivement beaucoup trop visible. Mais je crois qu'on ne peut pas exclure qu'il puisse le faire sous certaines conditions. Comme je le disais, ça peut par exemple être un simple pattern de bits particulier (et suffisamment long pour ne pas arriver par hasard) : lorsque ce patron est rencontré, alors le processus d'envoi se déclenche. Il suffit pour cela que l'utilisateur regarde une page web contenant une image dont les bits les moins significatifs sont soigneusement ajustés, ou d'envoyer un paquet invalide, mais d'apparence innocente à la machine…
Que certaines personnes y jettent un oeil, possible, mais je doute très fortement de la capacité de quiconque de détecter ce genre de choses. Par expérience, déboguer une communication USB3 on ne peut plus standard est déjà l'enfer, alors je n'imagine même pas ce que doit être analyser un processeur complet, avec tous les états internes possibles… Non, bien franchement, à part trouver les cas les plus patents d'erreur, une analyse logique ou liée à un programme ne peut pas révéler grand chose.
[^] # Re: Intéressant
Posté par Marotte ⛧ . Évalué à 8.
Je reconnais que ça demande du temps et des compétences pointues. Ce n’est en effet pas à la portée de tout le monde… à des années lumières pour quiconque en quelque sorte…
Je pense tout de même que les états mènent ce genre d’étude, qui rejoint l’espionnage industriel… La puce de ton concurrent tu la mets sur un banc d’analyse logique même si c’est effectivement une tâche longue et fastidieuse…
[^] # Re: Intéressant
Posté par Thomas Debesse (site web personnel) . Évalué à 2. Dernière modification le 06 avril 2016 à 18:11.
Oui mais par exemple pour un AMD, quel est l’intérêt de publier ce qu’il trouve, dans ce domaine, sur un processeur Intel ? Est-ce même le domaine dans lequel il cherche (c’est à dire que lorsqu’il trouve quelque chose dans ce domaine, y prête-il attention) ? A-t-il intérêt à révéler sa capacité à analyser un processeur concurrent ? Être discret sur ses capacités, ça fait aussi partie de sa force de frappe !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Intéressant
Posté par Marotte ⛧ . Évalué à 2.
Dans le cas où l’état se rend compte que le le dernier chipset équipant telle ou telle marque est muni d’une belle backdoor je pense effectivement qu’ils ne le crieront pas sur les toits mais mettrons des moyens en œuvre pour qu’aucun matériel muni de cette puce se retrouve dans l’administration et les PME du pays… (ainsi que retrouver et châtier ceusses qui ont voulu la leur faire à l’envers…)
Je pense pas que ça arrive souvent… mais j’ai l’impression que ça pourrait bien se passer comme ça dans l’avenir… Nous (européens) faisons fabriquer nos puces en Asie… la savoir faire a été transmis il n’ont plus besoin de nous pour en fabriquer…
[^] # Re: Intéressant
Posté par jyes . Évalué à 4.
J’en doute…
Effectivement, mais avec le savoir faire de la fabrication déménage le savoir tout court (parfois avec un léger décalage temporel). Du coup, très vite, il ne reste plus personne qui sait effectuer des tests correctement.
Pour revenir au sujet de ce journal, s’il y a une backdoor dans les processeurs Intel et AMD, je suis convaincu qu’aucune analyse technique par nos gouvernements et industriels ne saurait la détecter, la difficulté est trop énorme à moins d’une bourde gigantesque de la part de ces producteurs de processeurs. Si nos gouvernements voulaient s’assurer de l’absence de trou, il leur faudrait exiger les détails de conceptions, et envoyer des experts décortiquer toute la chaîne de la conception à la production pour vérifier que c’est bien ce qui est produit. C’est faisable, mais pas quand on fait venir tout son matériel depuis d’autres pays, achetés à des boites qui échappent largement à sa juridiction.
[^] # Re: Intéressant
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Je répondais à « l’espionnage industriel », c’est à dire ceux qui ont a priori les moyens de d’étudier et comprendre ce type de produit. Je crains que le niveau de compétence de l’état dans ce domaine ne puisse être garanti par tous les états. Et comme relevé par jyes… puisque le privé a transmis le savoir et s’est fait dépasser, il n’y a pas à attendre du privé (et encore moins du public)…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Intéressant
Posté par pushmepullme . Évalué à 2.
D'accord, la machine est malicieuse. Mais elle se trouvera généralement dans un ensemble d'équipement permettant la détection de sa corruption non ? (Dans la mesure ou cet ensemble est
biodiversifié).# De la question des exploits
Posté par pamaury . Évalué à 9.
Ces travaux, notamment sur le Management Engine (ME) de Intel, posent pour moi un problème encore plus embêtant: le code du ME est signé par Intel, on peut donc supposer qu'il ne fait pas (trop) de choses (vraiment trop) déplaisantes (encore que). Mais ce code est aussi énorme, il contient une VM Java et permet d'exécuter des modules (http://fr.slideshare.net/codeblue_jp/igor-skochinsky-enpub). Et c'est là que cela devient effrayant: si quelqu'un trouvait un exploit quelconque dans ce code, il pourrait potentiellement faire n'importe quoi sur la machine. On peut même imaginer pire: puisque le ME peut recevoir des commandes à distance (en théorie seul Intel peut le faire car il y a une clef par machine, mais bon, bug toussa), un exploit suffisamment grave pourrait permettre d'exécuter du code à distance sur n'importe quelle machine, sans que le propriétaire s'en aperçoive (même le noyau ne peut pas s'en apercevoir). C'est théorique mais vraiment très effrayant de savoir que ta machine ne peut pas booter sans un code qui contient potentiellement/probablement un backdoor.
C'est un peu du même ordre que le bug qui permettait de prendre le contrôle de n'importe quelle voiture connectée sur le réseau GSM d'une certaine marque (http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/). Sauf que le ME est inclut dans BIOS et pas désactivable, donc il faut reflasher un BIOS, ce qui n'est pas trivial.
[^] # Re: De la question des exploits
Posté par Kalenx . Évalué à 5.
En effet, et rétrospectivement j'aurais probablement dû en parler dans mon journal, c'est très pertinent.
En particulier, peu de gens savent qu'il existe, dans leur PC, certaines sections de la RAM auxquelles même le processeur (!!) n'a pas accès. On ne parle même pas de l'OS…
[^] # Re: De la question des exploits
Posté par Prosper . Évalué à 5.
Petite précision: la partie remote et résidente même pc éteint du ME n'existe que pour les chipset de type Qxxx avec la fonctionnalité intel AMT soit 0.0000001% des cartes grand publics. Et en gros c est la même chose que ce que propose HP (ilo), IBM (rsa) ou DELL (idrac).
# Lenovo x200/t400
Posté par karteum59 . Évalué à 5. Dernière modification le 06 avril 2016 à 02:28.
La problématique du Management Engine (qui peut aussi avoir une utilité dans certains contextes comme en entreprise, d'ailleurs documentée) est bien expliquée par les équipes Coreboot et Libreboot, donc ce n'est pas nouveau, et en fait, la dernière génération de machines "récentes" à pouvoir booter sans blobs binaires via Libreboot est la série Lenovo T400/X200… pas tout jeune et pas adapté à Steam mais ça fonctionne encore très correctement pour des besoins bureautique / web / media center (et si le reflashage à la main fait peur, il est également de les acheter avec Libreboot préinstallé).
[^] # Re: Lenovo x200/t400
Posté par Kalenx . Évalué à 8.
En effet, ce n'est pas nouveau, mais on ne se dirige pas vers la solution. Comme expliqué très clairement sur la page de Libreboot :
Cela fait en sorte qu'il est virtuellement impossible d'avoir un système entièrement libre sur tout PC datant d'après 2009. Pour le moment, le T400 offert n'est pas encore "ridicule" en termes de capacité (bien que nettement en deça des autres machines du marché), mais va inévitablement le devenir, puisqu'il est impossible de le remplacer—à tout le moins sur x86 :
Bref, on est loin d'être tournés vers l'avenir avec ça, même si l'effort est louable.
Par ailleurs, au-delà de ces constatations, le problème du microcode reste entier : il est en l'état impossible de savoir si MOV EAX, EBX transfère uniquement le contenu de EBX dans EAX, tel que la documentation l'indique, ou si cette instruction a aussi comme effet de bord de sauvegarder le contenu de EBX quelque part… C'est effectivement extrêmement far fetched, comme diraient les Anglais, mais pas formellement impossible : même dans ces portables "100% libre", une partie du logiciel est un blob binaire chiffré (à même le CPU, d'accord, mais blob binaire illisible néanmoins)…
[^] # Re: Lenovo x200/t400
Posté par karteum59 . Évalué à 5.
Je suis bien d'accord. Et je pense qu'il n'y a pas de solution (du moins sur base Intel/AMD. Après, on peut espérer que peut-être le monde ARM sera plus sympathique… mais c'est globalement pas gagné. Par exemple, hormis quelques exceptions il est rarement possible aux utilisateurs de Tegra d'avoir accès à la SBK et aux autres données nécessaires à nvflash)
# D'accord
Posté par reynum (site web personnel) . Évalué à 2.
Je suis tout à fait d'accord, pour commencer faisons travailler régulièrement et sérieusement la mémoire et la faculté d'analyse de notre cerveau, ensuite en s'appuyant sur les travaux des neurologues et psy* mettons en place un programme pour rendre nos enfant complètement autonome intellectuellement.
petite voix : "Ouai mais ça demande du travaille tout ça et puis il y a le bigdill et le foot à la TV"T'as raison laissons le boulo aux machines et continuons d'exceller dans la médiocrité à tendance asymptotique vers la nullité.
;-)
kentoc'h mervel eget bezan saotred
# Réponse non-technique
Posté par Michaël (site web personnel) . Évalué à 10.
Le fait que les russes et les chinois fabriquent et utilisent leurs propres circuits montre à mon avis assez bien la confiance que l'on peut faire à nos systèmes.
[^] # Re: Réponse non-technique
Posté par xcomcmdr . Évalué à 5.
s/faire/accorder
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Pour aller plus loin
Posté par Harvesterify (site web personnel) . Évalué à 3.
Cela fait déjà un certain temps que c'est connu, cette problématique du ME, notamment grâce au(x) papier(s) de Joanna Rutkowska "x86 considered harmful" (qui détaille les problèmes : http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf) et "State considered harmful" (qui propose une solution élégante : http://blog.invisiblethings.org/papers/2015/state_harmful.pdf)
Mes messages engagent qui je veux.
# Fôte
Posté par NumOpen . Évalué à 2.
interlocateur -> interlocuteur
[^] # Re: Fôte
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.