IPB

Bienvenue invité ( Connexion | Inscription )

 
Reply to this topicStart new topic
> Une nouvelle faille a été découverte dans les puces Intel, Réactions à la publication du 06/03/2020
Options
Lionel
posté 6 Mar 2020, 16:52
Message #1


BIDOUILLE Guru
*****

Groupe : Admin
Messages : 55 526
Inscrit : 14 Jan 2001
Lieu : Paris
Membre no 3



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



--------------------
C'est parce que la vitesse de la lumière est plus grande que celle du son que tant de gens paraissent brillants avant d'avoir l'air con
Go to the top of the page
 
+Quote Post
linus
posté 6 Mar 2020, 17:34
Message #2


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 798
Inscrit : 24 Jun 2004
Lieu : Grenoble
Membre no 20 409



Avec toutes ces failles, les processeurs Intel vont finir par tomber en morceaux. Bientôt l'annonce qu'ils sont également infectés par le corona virus ? :-)

Allez, une petite blague pour détendre l'atmosphère :
https://france3-regions.francetvinfo.fr/hau...us-1794673.html

Ce message a été modifié par linus - 6 Mar 2020, 18:10.
Go to the top of the page
 
+Quote Post
iAPX
posté 6 Mar 2020, 19:22
Message #3


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 15 387
Inscrit : 4 Jan 2006
Lieu : dtq
Membre no 52 877



Il faut rappeler que cette "faille" existe depuis au moins 5 ans sans qu'on ne soit sûr de rien pour les puces Intel précédentes.

Et les seuls en mesure d'exploiter cette "faille" sont des acteurs de niveau gouvernemental, notamment US.

À ce point, si j'étais dans un gouvernement quelconque (hors les USA, et encore...), je me poserais des questions pour savoir ce qui est fourni et qui ne contient pas de "failles" aujourd'hui...
À commencer justement par tous les dispositifs de sécurité coté ordinateurs et réseaux.

PS: les puces de sécurité d'Apple sont là pour assurer la sécurité qui aurait dû être confiée aux puces Intel, elles ont bien sûr leurs défauts mais pour l'instant l'implémentation semble extrêmement solide!

En addenda, les attaques sur les BIOS UEFI par des agences gouvernementales, c'est maintenant historique (et j'ai été concerné sur un iMac 5K), et seul Apple a pris des mesures drastiques pour nous en protéger, si tant est qu'il existe vraiment de la sécurité quelque-part.

Ce message a été modifié par iAPX - 6 Mar 2020, 23:18.
Go to the top of the page
 
+Quote Post
zmr
posté 6 Mar 2020, 20:08
Message #4


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 392
Inscrit : 25 Jan 2003
Lieu : Lyon
Membre no 5 811



Citation (linus @ 6 Mar 2020, 18:34) *
Avec toutes ces failles, les processeurs Intel vont finir par tomber en morceaux. Bientôt l'annonce qu'ils sont également infectés par le corona virus ? :-)

Allez, une petite blague pour détendre l'atmosphère :
https://france3-regions.francetvinfo.fr/hau...us-1794673.html

MWAHAHAHAHAHA !
laugh.gif laugh.gif laugh.gif laugh.gif
J'adore !


--------------------
iMac 27" 3,4, iMac 21", MacBookPro Retina, MacBookPro Unibody 2,4 Core 2 Duo
Nième membre du club des AIPBP (Anciens Inscrits Pas Beaucoup de Posts) Voir la liste
Go to the top of the page
 
+Quote Post
zero
posté 7 Mar 2020, 03:51
Message #5


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 12 576
Inscrit : 25 Nov 2001
Membre no 1 397



Citation (iAPX @ 7 Mar 2020, 03:22) *
Et les seuls en mesure d'exploiter cette "faille" sont des acteurs de niveau gouvernemental, notamment US.

C'etait le cas aussi pour d'autres failles dont la méthode s'est retrouvé au bout d'un moment dans la nature et que maintenent des hachers peuvent modifier la signature à loisir. Quelque soit la complexité, une fois que la méthode a fuité, ça devient accessible à toutes personnes motivées.
Go to the top of the page
 
+Quote Post
Gallows Pole
posté 7 Mar 2020, 06:58
Message #6


Macbidouilleur de vermeil !
****

Groupe : Membres
Messages : 1 443
Inscrit : 3 Feb 2004
Membre no 14 248



Salut,

L'exploitation de cette faille suppose-t-elle un accès physique à la machine ?
Ou bien est-ce quelque chose qui peut se faire à distance ?

A+

P.S. : le truc sur la "Mort subite" est excellent. Pour deux mauvaises bières, une bonne offerte :-)
Go to the top of the page
 
+Quote Post
iAPX
posté 7 Mar 2020, 15:24
Message #7


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 15 387
Inscrit : 4 Jan 2006
Lieu : dtq
Membre no 52 877



Citation (zero @ 6 Mar 2020, 22:51) *
Citation (iAPX @ 7 Mar 2020, 03:22) *
Et les seuls en mesure d'exploiter cette "faille" sont des acteurs de niveau gouvernemental, notamment US.

C'etait le cas aussi pour d'autres failles dont la méthode s'est retrouvé au bout d'un moment dans la nature et que maintenent des hachers peuvent modifier la signature à loisir. Quelque soit la complexité, une fois que la méthode a fuité, ça devient accessible à toutes personnes motivées.

+1
Go to the top of the page
 
+Quote Post
Pat94
posté 7 Mar 2020, 19:51
Message #8


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 828
Inscrit : 28 Nov 2015
Lieu : Somme
Membre no 197 274



La majorité des routines de bases servant à gérer nos binious sont écrites en assembleur et ce depuis l'origine des gammes de processeurs, et à chaque nouveau machin on repique les bibliothèques existantes, de plus à l'époque internet n'était même pas envisagé pour un usage autre que militaire, comment voulez-vous que dans tout ce bordel il ne reste pas quelques petites portes dérobées sauf à tout réécrire (même pas envisageable).

rotfl.gif rotfl.gif tongue.gif


--------------------
Mac Pro 2019 (7,1) 16 Core 3.2ghz 96 Go Ram 2 + 4 To SSD AMD RX 6800 / Mac Pro 5.1 12 Core 3.46 ghz 64 Go Ram 1+1 To SSD AMD RX 580 LE
Go to the top of the page
 
+Quote Post
iAPX
posté 7 Mar 2020, 21:39
Message #9


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 15 387
Inscrit : 4 Jan 2006
Lieu : dtq
Membre no 52 877



Citation (Pat94 @ 7 Mar 2020, 14:51) *
La majorité des routines de bases servant à gérer nos binious sont écrites en assembleur et ce depuis l'origine des gammes de processeurs, et à chaque nouveau machin on repique les bibliothèques existantes, de plus à l'époque internet n'était même pas envisagé pour un usage autre que militaire, comment voulez-vous que dans tout ce bordel il ne reste pas quelques petites portes dérobées sauf à tout réécrire (même pas envisageable).

rotfl.gif rotfl.gif tongue.gif

Il y a très peu de code écrit en assembleur, sauf dans des logiciels tournant au-dessus d'un OS pour des raisons d'optimisations et d'ailleurs je recommande chaudement l'analyse de x264 (et surtout ses portions assembleurs avec les différentes variantes vectorielles supportées) qui est ma-gni-fi-que.
Depuis Windows NT, Windows XP (un descendant de Windows NT), OS X, Linux, les BSD, Unix bien sûr (mais pas la première version!), et tous les autres, l'assembleur est banni et autorisé uniquement quand étant la seule voie permettant de réaliser certaines actions de très bas niveau.

Le langage dans lesquels les fondements de l'informatique de ces 25 dernières années ont été créé, c'est le langage C qui est omniprésent: tout ce qui n'est pas du C est bâti sur du C. point-barre.
Quand au "vieux code" en C, il est là parce qu'il a passé avec succès l'épreuve du temps, le bon code ne vieillit pas et il est totalement béton maintenant!

Les failles ne sont d'ailleurs pas dans du "vieux code", mais au-contraire dans du code récent...

Ce message a été modifié par iAPX - 8 Mar 2020, 00:25.
Go to the top of the page
 
+Quote Post
Pat94
posté 8 Mar 2020, 05:54
Message #10


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 828
Inscrit : 28 Nov 2015
Lieu : Somme
Membre no 197 274



@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. emot_012.gif
D'ailleurs cela ne me rajeunit pas. sad.gif
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.


--------------------
Mac Pro 2019 (7,1) 16 Core 3.2ghz 96 Go Ram 2 + 4 To SSD AMD RX 6800 / Mac Pro 5.1 12 Core 3.46 ghz 64 Go Ram 1+1 To SSD AMD RX 580 LE
Go to the top of the page
 
+Quote Post
ericb2
posté 8 Mar 2020, 12:26
Message #11


Macbidouilleur de vermeil !
****

Groupe : Membres
Messages : 835
Inscrit : 16 Nov 2003
Membre no 11 701



On s'éloigne du sujet initial, mais pour ceux que cela intéresse, un logiciel qui utilise de façon intensive l'assembleur, c'est OpenOffice.

Plus précisément, on utilise l'assembleur pour servir de "proxy" entre les API Java, Python, UNO et le C++, ou un autre langage éventuellement. L'assembleur permet la traduction des entités dans les2 sens, et c'est tellement rapide que c'est transparent pour l'utilisateur. La difficulté, c'est d'écrire la partie assembleur :-)

Un autre endroit où c'est utilisé (toujours dans OpenOffice), c'est pour la manipulation des refcount (sorte de GC maison) qui permet d'éviter les fuites de mémoires).

La contrepartie, c'est qu'il y a un assembleur par couple OS / processeur, soit une grosse vingtaine de cas traités à maintenir !

Dans les sources d'OpenOffice, tout est dans le module "bridge".


Pour ceux qui veulent avoir une idée de ce à quoi ça ressemble, peuvent essayer avec la commande :

Code
gcc -S  -o test.asm   prog1.c

L'option "-S" de gcc correspond à la 2ème étape de la compilation (après le parsing du code, servant à inclure toutes les macros, et à vérifier la syntaxe et la sémantique utilisée).

À titre d'exemple, avec le code ci-dessous contenu dans le fichier progr1.c , et contenant


Code
#include <stdio.h>
#include <stdlib.h>
#include <math.h>

/* au cas où une macroserait nécessaire */
#ifndef M_PI
#define M_PI    3.14159265358979323846
#endif

int somme( int valeur1 , int valeur2)
{

    return (valeur1 + valeur2);
}

int main( void)
{
    int result = 0;

    result = somme(3,2);
    fprintf(stdout, "La somme de 3 et 2 vaut %d et de 25 et 18  vaut %d \n", result, somme(25,18));
    fprintf(stdout, "Le cos de 60° vaut %.2f \n", cos(60.0*M_PI/180.0));

    return EXIT_SUCCESS;
}


Le fichier .asm obtenu - lisible par un humain, et compréhensible - sera ensuite transformé en langage machine (le tout en hexadécimal), non lisible par un humain, et ensuite lié à la libC du système (4ème et dernière étape de la compilation).

En fait, quand j'ai commencé à programmer, on utilisait l'assembleur, et avec l'habitude on lisait directement le code machine. Je me souviens encore de la galère qui consistait à calculer les sauts quand on devait le faire à la main (au début seulement)

@Pat94 : un processeur, ça comprend surtout le langage machine, non ? (l'assembleur, c'est juste une surcouche, écrite pour faciliter la création des programmes. Mais pour les couches du dessus, je suis d'accord)

Ce message a été modifié par ericb2 - 8 Mar 2020, 12:31.
Go to the top of the page
 
+Quote Post
iAPX
posté 8 Mar 2020, 13:23
Message #12


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 15 387
Inscrit : 4 Jan 2006
Lieu : dtq
Membre no 52 877



Je vais éviter de m'empêtrer dans des débats stérile pour savoir qui a commencé avant l'autre, si même je sais ce qu'est du langage d'assemblage, du langage machine, et les erreurs glissées à droite et à gauche.

En revanche les problèmes des CPU Intel sont du à du code récent et non du vieux code en C ou en Assembleur qui sont en béton.
Sauf à avoir un scénario Orwellien, ou plutôt à la Ken Thompson pour sa réception de son prix Turing, tout cela est totalement équivalent, expliquant au-passage la prépondérance du C sur lequel aujourd'hui tout est bâti.

Qu'il existe des bugs, voir qu'elles soient exploitables comme des failles, sur tout logiciel constitué de plus de 100 000 lignes de codes (loc) au total est attendu, je dirais même statistiquement normal, même avec les meilleures normes de l'industrie (avionique, embarqué, etc.).
Même si cette backdoor "faille" pourrait bénéficier à certains agents de niveau gouvernementaux, comme les failles matérielle Intel de 20 ans sur l'hyperviseur (renommé de manière marketing VM Manager, comme VMware, VirtualBox, etc.).

Le problème ici est que c'est dans une ROM qui pour des raisons évidentes ne peut être changée, que ça ne pouvait être mis dans une mémoire pouvant être MàJ puisque étant la première étape du démarrage de la CPU pour créer la chaîne de confiance (Trust, le concept pas le groupe), et que celle-ci est maintenant totalement rompue sur 5 générations de CPU Intel au moins.

À partir d'un certain niveau, on ne peut plus faire confiance à un ordinateur équipé de tout le fatras de sécurité Intel, et à mesure que le temps passera et que les possibilités d'exploitation augmenteront mais aussi seront accessible à de plus en plus d'acteurs malveillants, de moins en moins d'utilisateurs pourront faire confiance à ces mêmes machines.
Le problème d'une backdoor "faille" est que lorsqu'elle est découverte, alors les ennemis aussi l'utilisent, et l'ensemble de la société y perd de la sécurité.

Ce message a été modifié par iAPX - 8 Mar 2020, 13:25.
Go to the top of the page
 
+Quote Post
chombier
posté 8 Mar 2020, 21:01
Message #13


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 6 581
Inscrit : 20 Mar 2003
Membre no 6 765



Citation (iAPX @ 8 Mar 2020, 13:23) *
(Trust, le concept pas le groupe)

laugh.gif
Antisocial ? Trust my microcode. biggrin.gif


--------------------
késtananafout' (:
Go to the top of the page
 
+Quote Post
zero
posté 9 Mar 2020, 07:46
Message #14


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 12 576
Inscrit : 25 Nov 2001
Membre no 1 397



Citation (Pat94 @ 8 Mar 2020, 13:54) *
@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.
Go to the top of the page
 
+Quote Post
Pat94
posté 9 Mar 2020, 17:13
Message #15


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 828
Inscrit : 28 Nov 2015
Lieu : Somme
Membre no 197 274



Désolé ma mémoire doit me tromper, dans mes souvenirs (ancien, 1975) on utilisait de l'assembleur avec des entrées en hexadécimal pour générer le code machine, j'ai fait l'amalgame, mais dans tous les cas, c'était très chiant de mémoire de jouer avec les registres des binious.


--------------------
Mac Pro 2019 (7,1) 16 Core 3.2ghz 96 Go Ram 2 + 4 To SSD AMD RX 6800 / Mac Pro 5.1 12 Core 3.46 ghz 64 Go Ram 1+1 To SSD AMD RX 580 LE
Go to the top of the page
 
+Quote Post
patrick_a_a
posté 11 Mar 2020, 16:31
Message #16


Nouveau Membre


Groupe : Membres
Messages : 37
Inscrit : 13 Jul 2004
Membre no 20 964



Citation (zero @ 9 Mar 2020, 08:46) *
Citation (Pat94 @ 8 Mar 2020, 13:54) *
@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.


--------------------
Patrick, amateur de Mac depuis 1985. 3,3 planètes, hélas.
Membre du club des AIPBP (Anciens Inscrits Pas Beaucoup de Posts) Voir la liste
Go to the top of the page
 
+Quote Post
malloc
posté 11 Mar 2020, 16:54
Message #17


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 2 548
Inscrit : 5 Sep 2004
Membre no 23 103



Ouh la transpiration que vous avez du faire pendant le flashage et le premier power-up....


--------------------
AMF: Ne possède pas d'actions Apple. Ne touche aucune rémunération, directe ou indirecte, d'Apple. Intervient ici depuis 20 ans à titre personnel. Ne partage pas son compte avec des tiers. N'a aucun lien avec les rédacteurs du blog MacBidouille.
Mes messages sont parfois édités par la modération dans le texte, et ce sans trace visible. Ce qui apparaît sous mon nom peut ne pas provenir de moi.
Go to the top of the page
 
+Quote Post
iAPX
posté 12 Mar 2020, 00:01
Message #18


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 15 387
Inscrit : 4 Jan 2006
Lieu : dtq
Membre no 52 877



Tout ça pour ça!

Et pendant ce temps là c'est le SGX qui vient de sauter, mauvaise semaine pour Intel.
Go to the top of the page
 
+Quote Post
Pat94
posté 12 Mar 2020, 09:02
Message #19


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 828
Inscrit : 28 Nov 2015
Lieu : Somme
Membre no 197 274



Apple à la solution pour résoudre ce petit problème c'est "KALAMATA" dit dans les milieux autorisés "la calamité", en résumé cela transforme le mac en super iPhone avec une puce ARM en processeur, et pour les fondus du code machine un peu de travail en perspective pour adapter certains programme (enfin c'est ce que Apple espère). tongue.gif

Ce message a été modifié par Pat94 - 12 Mar 2020, 12:15.


--------------------
Mac Pro 2019 (7,1) 16 Core 3.2ghz 96 Go Ram 2 + 4 To SSD AMD RX 6800 / Mac Pro 5.1 12 Core 3.46 ghz 64 Go Ram 1+1 To SSD AMD RX 580 LE
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
2 utilisateur(s) sur ce sujet (2 invité(s) et 0 utilisateur(s) anonyme(s))
0 membre(s) :

 



Nous sommes le : 31st July 2025 - 00:15