Une nouvelle faille a été découverte dans les puces Intel, Réactions à la publication du 06/03/2020

[Lionel]

La société de sécurité Positive Technologies a annoncé avoir découvert une faille de sécurité touchant l'essentiel des processeurs Intel.
La faille est présente dans les modules Converged Security et Management Engine, qui sont destinés à s'assurer que certains composants logiciels sont fiables. Ces fonctions gravées dans les puces permettent par exemple de s'assurer avant leur exécution que l'EFI ou le Bios sont légitimes, elles sont aussi utilisés par Microsoft System Guard et BitLocker pour les mêmes raisons.
Dans certaines conditions, il est possible de tromper le processeur et d'exécuter du code malveillant avant que ces fonctions ne soient enclenchées.
La faille est contenue dans une ROM non modifiable. Il n'est donc pas possible de l'éliminer. Intel, prévenu depuis un moment, a mis en place des atténuations mais elles ne sont pas parfaites.

Dans la pratique, un attaquant (très motivé) pourrait par exemple installer un keylogger sur la couche la plus basse de la machine, impossible à détecter même par des antivirus.


Il y a cependant peu de chance que l'énergie nécessaire à compromettre une machine soit déployée en dehors de projets d'espionnage de haut vol.

Dans l'immédiat, on ignore si cela aura un impact sur les Mac dotés d'une puce de sécurité Apple.

Lien vers le billet original

[Pat94]

@IAPX

Un processeur ne comprend qu'un langage c'est l'assembleur, tous les compilateurs C, C+ et tous les autres n'ils ne servent qu'à faciliter la programmation, et ils sortent du code en assembleur qui est le SEUL langage que comprend le processeur.
Il semblerait que tu n'as pas connu le début de la micro et son histoire, là où il fallait se taper tout en assembleur dit aussi code machine, et tout écrire en hexadécimal. avec que des langages évolués arrivent avec leurs compilateurs.
D'ailleurs cela ne me rajeunit pas.
Le petit souci pour effectuer des corrections de ce code machine est que celui-ci est rentré en"dur" dans des Rom interne des binious donc non modifiable, et ce pour le bonheur des pirates divers et variés.



Ce message a été modifié par Pat94 - 8 Mar 2020, 08:42.

[zero]

@IAPX

Un processeur ne comprend qu'un langage c'est l'assembleur, tous les compilateurs C, C+ et tous les autres n'ils ne servent qu'à faciliter la programmation, et ils sortent du code en assembleur qui est le SEUL langage que comprend le processeur.

Non, c'est seulement le langage machine que les CPU comprennent. L'assembleur est aussi un langage créé pour faciliter la programmation. Le C est un langage principalement créé pour faciliter le portage.

[patrick_a_a]

@IAPX

Un processeur ne comprend qu'un langage c'est l'assembleur, tous les compilateurs C, C+ et tous les autres n'ils ne servent qu'à faciliter la programmation, et ils sortent du code en assembleur qui est le SEUL langage que comprend le processeur.

Non, c'est seulement le langage machine que les CPU comprennent. L'assembleur est aussi un langage créé pour faciliter la programmation. Le C est un langage principalement créé pour faciliter le portage.

Quand nous avons découvert le C, habitués au Pascal, Ada, Lisp et autres, nous l'avons qualifié de "assembleur portable" au début des années 80.

Pour moi, le vrai langage machine est le binaire, l'hexadécimal est déjà une écriture permettant une meilleure lisibilité. D'ailleurs, sur certains minis que nous utilisions (DEC PDP), la représentation la plus courante était l'octal.

Ainsi, l'exercice le plus trapu que j'ai réalisé était, dans le cadre d'écriture de firmware, la programmation avec des EPROM effaçables via UV dont le stock était épuisé.
Mes collègues avaient laissés les dernières "cramer" sous les UV (plus de 20 minutes au lieu de 10 max) et les notres étaient en fin de vie.
D'où la seule solution :
prendre nos EPROM déjà programmées, qui ne pouvaient accepter que des écritures de 0 à la place des 1, trouver des séquences binaires permettant de patcher les 1 pour remplacer l'instruction par un JUMP vers une section encore vierge de l'EPROM (à programmer avec l'ancien code remplacé par le JUMP et les instructions suivantes, puis les instructions remplaçantes et enfin un JUMP à la suite du code initial correct).

Nous avons appliqué ce petit jeu 3 ou 4 fois pour avoir un prototype démontrable !

Jeu à ne pas conseiller aux excités du clavier ...

Ce message a été modifié par patrick_a_a - 11 Mar 2020, 16:32.