Un fichier de 6 Go a été mis en ligne sur 4chan et Github, avec du code source et des outils permettant de créer ou modifier des BIOS/UEFI, comme le rapporte Tom’s Hardware.
Intel l’a ensuite confirmé à nos confrères, en précisant : « Nous ne pensons pas que cela expose de nouvelles vulnérabilités de sécurité car nous ne nous appuyons pas sur l'obfuscation des informations comme mesure de sécurité ».
Le fondeur rappelle que ce genre de fuite est pris en charge par son programme de chasse aux bugs rémunéré. Une manière de lancer un appel à la communauté pour comprendre comment ces fichiers se sont retrouvés dans la nature ?
Commentaires (18)
Ben dans ce cas ils n’ont qu’à publier les sources officiellement ! Chiche ?
S’il n’y avait que pour des raisons de sécurité que les codes sources restaient cachés on en verrait bien plus souvent mais il est évident que ça l’est ici pour des raisons commerciales.
Il y a surement des raisons légales derrière. Et de de plus, c’est aussi un secret industriel stratégique.
Pour avoir bosser pour Intel ça risque pas. Déjà très étonnant que ce genre d’info ai pu fuiter chez eux…
J’allais dire la même chose. Ils prennent tout utilisateur de leur matériel pour un affreux lanceur d’alerte.
Ou de froid.
Plus grave, une clef privée utilisée pour signer les manifestes de démarrage utilisés par la fonction Intel Boot Guard, qui fournit une racine de confiance matérielle au début de la chaîne de démarrage (avant l’UEFI et le Secure Boot) a également fuité.
A priori ça ne concerne “que” les machines Lenovo, mais c’est ultra galère à corriger : le SHA 256 de la partie publique de la clef est configurée en dur dans le CPU via des fusibles matériels, donc il faut changer le CPU (ou les fusibles, mais ce n’est pas moins compliqué) pour corriger le problème…
Alors Pat, on peut avoir la doc concernant le bitflag du ME ou doit encore faire du reverse-eng ?
Crotte, github m’envoie baladée pour voir les sources. J’étais curieuse de voir à quoi ça pouvait ressembler.
Trouvé, en fait c’est assez facile :-)
Je ne comprends pas pourquoi les codes des UEFI ne sont pas publiés et en quoi ils seraient un secret industriel.
On avait bien l’initiative LinuxBios (je ne sais pas si c’est le bon nom) pour se passer complètement du BIOS classique (dont Linux ne se sert quasiment pas me semble), entre autres.
Vers 2011 j’avais utilisé un PC portable ASUS (de mémoire) qui avait une option de boot quasi instantané, en fait ça bootait sous un Linux façon live-distrib.
Intel n’est pas forcément propriétaire de l’intégralité du code et des technologies (brevetable au USA), ne possédant qu’un droit d’utilisation. Si c’est le cas, il ne peuvent pas fournir légalement le code. De plus, Intel a peut-être aussi intégré ses propres technologies qui lui sont stratégiques et que d’autre constructeurs pourraient l’utiliser de manière plus ou moins légale (tous les pays ne possèdent pas les même loi pour les brevets.). Intel reste une entreprises privées à but lucratif, ça ne fait pas dans l’humanitaire, l’objectif d’une tel société est par définition de réaliser de bénéfices en proposant un bien ou un service.
OK, néanmoins je persiste, on parle d’un pauvre BIOS quand même… Enfin, UEFI mais ça reste un truc basique par rapport à un noyau ou un OS complet, sans parler du CPU lui-même.
Si tu trouve ca m’intéresse.
Je suis en train de me galerer sur ce genre de problème pour des systèmes embarqués…
Un BIOS UEFI complet, c’est de l’ordre de 2M de lignes de code. C’est juste de l’ordre de grandeur du kernel Linux.
Certes, l’architecture totalement merdique du truc explique bien des choses (3 phases dites SEC/PEI/DXE, assez étanches, générant des doublons sur des fonctions qui pourraient être communes). De même le fait que ce soit un patchwork de EDK2 (largement fait par Intel et open source), des reference code Intel (là par contre les coreboot et autres doivent se contenter d’un blob binaire compilé, les RC/MRC c’est donné aux seuls vendeurs de BIOS), du code du vendeur de BIOS (AMI et autres), ca fait encore du multipliage de commonalités comme jésus pour les pains! On a même plusieurs chaînes de compilation utilisées. Du délire!
Bref, un beau tas de m…, mais il faut arrêter de penser que c’est trivial! Je dirais que tout est d’ailleurs artificiellement rendu compliqué pour préserver les business d’AMI/Insyde/Phoenix…
Puis les documentations Intel sur les sujets ou il fournit le code (init DDR etc…): Un néant!
Alors bon courage garçon!!!
2M de ligne de code ??
C’est hallucinant pour ce que c’est censé faire (même si t’as expliqué qu’il y avait beaucoup de duplication de code).
Ça compile en quelle taille de ROM (je dis ROM même si c’est de l’EEPROM ou de la Flash en réalité) ?
Le noyau Linux fait beaucoup plus que 2M, enfin ça dépend ce que tu prends en compte.
C’est du travail itératif à chaque carte mère je suppose, ça ne doit pas être si compliqué (surtout par rapport à un noyau).
En général, les bootflash SPI font 64MB. Mais il n’y a pas que le BIOS dedans. Il y a les FW variables selon la plateforme, dont le ME, de l’environnement… Pour ce qui est des différences RC entre plateformes c’est assez énorme. En prime Intel a une façon un peu spécifique de faire l’init DDR: Là ou d’autres contrôleurs font tout en HW (en gros, on configure le multiplexage d’adresses, les timings etc… On file le go, attends la fin des calibrations et roule) Intel fait tout en soft (un bios compilé en mode debug complet te sort des km de traces, en particulier sur l’init DDR avec toutes les marges de bruit. Le diagramme de l’oeuil en résumé): C’est juste énorme et comme c’est quasiment pas documenté (chez Intel code fourni, même si pas à tout le monde, => doc minimaliste) bonjour pour refaire cela sans être chez Intel.
Ici la fuite ne vient pas forcément d’eux d’ailleurs: Vendeur de BIOS, client de ces vendeurs ayant acheté les sources/outils de développement car il avait des besoins spécifiques à ajouter… Ces sources ont quand même un peu de diffusion même si le mode de fonctionnement d’Intel qui consiste à imposer de sous traiter le démarrage les limite plus qu’ailleurs.
Merci pour toutes ces infos en tous cas
C’est un drôle de monde le monde Wintel (parce que ces histoires de BIOS au départ c’est aussi lié à MS-DOS puis Windows, dont l’ACPI pourri).
Rien qu’en voyant la tronche de leur assembleur, on comprend qu’ils font des trucs alambiqués.
Quand t’as fait de l’assembleur 68000 (jeu d’instruction simple, propre et orthogonal) et que tu vois du code 8086 ensuite, mon Dieu…
Pareil avec le PPC qui avait succédé au 68k au milieu des années 90 dans l’embarqué. J’avais commencé sur du Motorola 68340 (pour du VME/VXI, c’était le choix logique vu que le bus fond de panier était quasiment un bus 68k: Quelques adaptations avec un ispLSI logique codée en direct à l’époque du FPGA balbutiant et 90% d’une carte contrôleur était fait!), alors côté HW… Avant de passer côté SW (bas niveau) sur la série des (Motorola puis Freescale puis NXP) PowerQUICC et QorIQ (pas les LSx basé ARM, les Px/Bx): Après presque 20 ans de PPC, revenir sur de l’Intel fait vraiment se boucher le nez. Quelle horreur de voir un truc pareil durer encore. Le pire c’est que j’ai une impression assez proche d’ARM, quand je compare le passage du 32 au 64 bits côté PPC (jeu d’instruction quasi inchangé, intelligence de design fort différente de ARM qui cumule désormais jeu 32 bits/réduit/64bits ; heureusement Jazelle n’a pas pris sinon on aurait 4 jeux d’instruction au lieu de 3).
Je sais pas si RISC-V arrivera assez tôt pour que j’ai le temps de le voir?