"AMD met un antivirus dans ses processeurs"

"AMD met un antivirus dans ses processeurs" - Carte mère - Hardware

Marsh Posté le 17-01-2004 à 12:08:02    

Citation :

Jeudi 15 Janvier 2004
AMD met un antivirus dans ses processeurs
 
 
Le premier antivirus 'hard'
Les constructeurs informatiques ont trouvé une nouvelle solution pour se protéger contre les virus, ce véritable fléau des temps modernes. Le fabriquant américain AMD va insérer un antivirus directement à l'intérieur de ses microprocesseurs.
 
En fait, cette solution est déjà en place sur les processeurs Athlon 64 bits d'AMD sortis l'an dernier. Mais pour l'instant elle ne fonctionne pas. Pour être opérationnelle, elle a besoin de la nouvelle mise à jour du système Windows de Microsoft, le service pack 2 , qui doit sortir dans la deuxième moitié de 2004. C'est un peu comme une voiture qui serait équipés d'airbags révolutionnaires sauf que pour l'instant il manque le déclencheur des airbags encore en développement?
 
La protection mise en place à l'intérieur des Athlon 64 se nomme NX (No Execution). C'est une technologie qui bloque l'exécution de code informatique dans une zone réservée de la mémoire du microprocesseur (débordement de la mémoire tampon). Or, c'est justement dans cette zone que s'exécutent généralement ce qu'on appelle les "codes malicieux", c'est-à-dire les vers informatiques et autres chevaux de Troie, toutes joyeusetés qui font fonctionner de travers nos ordinateurs?
 
Selon AMD, si cette technologie avait été appliquée en 2002 et 2003, elle aurait permis de réduire de moitié le nombre de correctifs Microsoft, ces fameux patchs qu'il faut régulièrement installer sur son ordinateur pour colmater au fur et à mesure les failles de sécurité mises à jour.
 
AMD est pour l'instant le seul fabricant à intégrer cette technologie. Son concurrent Intel prévoirait d'introduire un système similaire dans ses futurs Pentium 4 connus pour l'instant sous le nom de code Prescott.


 
source france-info
 
 
par contre je vois pas dans quelle mesure un "anti buffer overflow " -qui aparement serait geré par windows constituerais un anti virus efficace :??:


---------------
LoD 4 ever && PWC spirit|Le topak de l'iMP-450|inDATOUNEwe trust
Reply

Marsh Posté le 17-01-2004 à 12:08:02   

Reply

Marsh Posté le 17-01-2004 à 12:09:05    

fo ben des arguments pour faire vendre :o


---------------
Ma cinémathèque
Reply

Marsh Posté le 17-01-2004 à 12:09:36    

tout sa pour dire " j'té cassé intel, jlé dit avant toi", deubeul [:amarant][:amarant] :D


Message édité par totoz le 17-01-2004 à 12:10:21
Reply

Marsh Posté le 17-01-2004 à 12:29:04    

Intel intégre le même procedé dans les puce prescote.

Reply

Marsh Posté le 17-01-2004 à 12:32:07    

Super, plus besoin d'apprendre à coder, maintenant le hard fait tout !
A quand windows intégré au CPU ?

Reply

Marsh Posté le 17-01-2004 à 12:37:16    

[Albator] a écrit :

Super, plus besoin d'apprendre à coder, maintenant le hard fait tout !
A quand windows intégré au CPU ?


 
ben pas vraiment vu que la "fonction" ne sera dispo qu'avec winP sp2 donc ca reste controllé par windows


---------------
LoD 4 ever && PWC spirit|Le topak de l'iMP-450|inDATOUNEwe trust
Reply

Marsh Posté le 17-01-2004 à 12:45:11    

merci amd de penser à ma sécurité: pourquoi n'ont ils pas indiqué qu'il s'agit tout simplement d'une première implémentation de tcpa ? :??:

Reply

Marsh Posté le 17-01-2004 à 12:53:15    

j'allais le dire :d

Reply

Marsh Posté le 17-01-2004 à 13:01:40    

c'est pas les virus que ça va limiter.
 
c'est les tentatives d'exploit par buffer overflow.
 
donc sa restreint les possiblitées d'attaque c tout.
c pas un mal, et ca pose aucun problème de principe comme paladium/tcpa.
 
[Albator] >> pour dire que ça a rapport avec tcpa, tu dois pas savoir ce que c'est qu'une attaque par dépassement de tampon.
 

Reply

Marsh Posté le 17-01-2004 à 13:05:35    

AMD c'est pas japonnais??

Reply

Marsh Posté le 17-01-2004 à 13:05:35   

Reply

Marsh Posté le 17-01-2004 à 13:07:39    

bjone a écrit :


[Albator] >> pour dire que ça a rapport avec tcpa, tu dois pas savoir ce que c'est qu'une attaque par dépassement de tampon.


 
Je vois, dans ce cas-là, voici un petit exercice:
1) expliquer ce qu'est un "débordement de tampon"
2) donner un exemple réaliste "d'attaque" par débordement de tampon
3) expliquer comment une technologie intégrée à un CPU peut bloquer ce genre d'attaque
4) justifier le fait que ça nécessite Windows XP SP2
5) prouver que cette technologie ne permet pas de débordement comme TCPA/Palladium
 
A vos copies :hello:

Reply

Marsh Posté le 17-01-2004 à 13:12:41    

bah alors si tu sais ce que c'est qu'un débordement de tampon, tu dois comprendre pourquoi je comprends pas le rapport avec Palladium.
ceci dit j'ai pas été voir dans les datasheets comment ils comptaient s'y prendre :D

Reply

Marsh Posté le 17-01-2004 à 13:14:41    

totoz a écrit :

tout sa pour dire " j'té cassé intel, jlé dit avant toi", deubeul [:amarant][:amarant] :D


 :lol:  
Le pire, c'est que c'est ca...
Et qu'autant intel qu'amd le font!


Message édité par Julien31 le 17-01-2004 à 13:15:02
Reply

Marsh Posté le 17-01-2004 à 13:18:23    

bjone a écrit :

bah alors si tu sais ce que c'est qu'un débordement de tampon, tu dois comprendre pourquoi je comprends pas le rapport avec Palladium.
ceci dit j'ai pas été voir dans les datasheets comment ils comptaient s'y prendre :D


 
Le rapport direct, en effet.
Je t'avoue que c'est surtout les points 4 et 5 qui me font me poser des questions ... Lorsque l'OS et le CPU commencent à "collaborer" pour savoir si le PC a le droit d'exécuter tel ou tel code, ça me rappelle furieusement TCPA quand même ...

Reply

Marsh Posté le 17-01-2004 à 13:19:19    

héhé lol....
 
ça me rapelles la sorite du Pentioum 1, y en avaient causés sur RTeul :D (spa moi, c'était mes parents qui écoutaient ça à l'époque)

Reply

Marsh Posté le 17-01-2004 à 13:19:37    

Julien31 a écrit :


 :lol:  
Le pire, c'est que c'est ca...
Et qu'autant intel qu'amd le font!

bah wai :D tout sa sa reste des gamineries a l'echelle mondial :D

Reply

Marsh Posté le 17-01-2004 à 13:22:41    

[Albator] a écrit :


 
Je vois, dans ce cas-là, voici un petit exercice:
1) expliquer ce qu'est un "débordement de tampon"
google est ton ami (j'ai l'idée générale de ce que c'est donc je saurais pas te l'expliquer exactement don cje m'aventure pas là-dessus :D)
2) donner un exemple réaliste "d'attaque" par débordement de tampon
apparemment blaster fonctionne comme ça (c'est ce que j'ai lu)
3) expliquer comment une technologie intégrée à un CPU peut bloquer ce genre d'attaque
tout passe par le CPU donc si un programme quelconque tente d'écrire sur une zone protégée, il devrait pouvoir le repérer et l'empecher
4) justifier le fait que ça nécessite Windows XP SP2
parceque c'est nouveau et donc que winXp ne sait pas encore le gérer (tout comme l'USB2 nécessite le SP1 , c'est pas pour autant qu'on va crier au TCPA)
5) prouver que cette technologie ne permet pas de débordement comme TCPA/Palladium
il n'est absolument pas question ici de regarder ce que tu as sur ton dur ni controler ce que tu télécharges ou quoi que ce soit mais éviter des accès mémoire foireux
 
A vos copies :hello:


Message édité par darth21 le 17-01-2004 à 13:23:53

---------------
TZR un jour…  |  gamertag: cropNcut
Reply

Marsh Posté le 17-01-2004 à 13:23:10    

[Albator] a écrit :


 
Le rapport direct, en effet.
Je t'avoue que c'est surtout les points 4 et 5 qui me font me poser des questions ... Lorsque l'OS et le CPU commencent à "collaborer" pour savoir si le PC a le droit d'exécuter tel ou tel code, ça me rappelle furieusement TCPA quand même ...


 
bin je verrais des ptits à cotés drôles du style:
t'as une exception qui est lancé par le cpu lors de "débordements", puis dans le journal système t'as un chti message du style "hoannnn l'application trucmuche a été victime d'un tentative de débordement nagnga à l'offset bidule....".
 
ça pourrait être sympa :D
 
pi à priori leur truc je sais comme ça marche trop, mais si ça se base sur déjà l'addresse de retour poussé par call puis utilisée par ret, ça permet de ché pas jeler le process qui a une adresse de retour de poluée, avec un message d'avertissement "le process gnagna est pas clair, le sida y passera pas par moa"

Reply

Marsh Posté le 17-01-2004 à 13:27:25    

[Albator] a écrit :


 
Je vois, dans ce cas-là, voici un petit exercice:
1) expliquer ce qu'est un "débordement de tampon"
2) donner un exemple réaliste "d'attaque" par débordement de tampon
3) expliquer comment une technologie intégrée à un CPU peut bloquer ce genre d'attaque
4) justifier le fait que ça nécessite Windows XP SP2
5) prouver que cette technologie ne permet pas de débordement comme TCPA/Palladium
 
A vos copies :hello:


1) c'est un buffer overflow
2) blaster
3) en empéchant d'éxecuter du code dans la zone "donnée" de la mémoire
4) il faut que l'OS gère cette fonctionnalité
5) ben heuuuu.... je vois pas comment ça pourrait dériver ... si tu as des exemples, je t'en prie partage les


---------------
"I wonder if the internal negative pressure in self pumping toothpaste tubes is adjusted for different market altitudes." John Carmack
Reply

Marsh Posté le 17-01-2004 à 13:28:34    

à la base le principe de la collaboration OS/CPU, c'est la base du principe des MMU, du mode protégé et du système de pagination des x86 quand même. donc si une extension est rajouté à l'archi x86 au niveau du mode protégé, le noyau doit être actualisé en conséquence, ce qui est valable autant pour zindozs que linuze...

Reply

Marsh Posté le 17-01-2004 à 21:15:26    

Alors voyons voir un peu de quoi il retourne ...
Bon déja, l'article cité plus haut n'est pas clair du tout, mais bon, c'est France Info, je comprends qu'ils détaillent pas trop l'aspect technique ...
 
Pour ce que j'entendais par "collaboration OS/CPU", il reste à voir dans quel sens la communication a lieu.
Si comme l'indique bjone, le CPU peut remonter à l'OS des infos comme quoi il a bloqué l'exécution de code suite à un débordement de tampon, d'accord, c'est utile (mais je trouve quand même bizarre que le hard doive combler des lacunes du soft ...)
 
Maintenant ce qui m'inquiète, c'est la communication dans l'autre sens: que l'OS puisse interdire si directement l'exécution de code au CPU.  
 
Voici le futur de la sécurité informatique:
 
Etape 1: l'OS interdit l'exécution de code malicieux lors de débordement de tampon.
Etape 2: mise à jour de l'OS, maintenant il demande au CPU de n'exécuter aucun code, sauf le code spécialement autorisé.
Etape 3: encore une mise à jour de l'OS, maintenant seul le code signé numériquement sera autorisé
...
Ca vous rappelle rien ?


Message édité par [Albator] le 17-01-2004 à 21:22:54
Reply

Marsh Posté le 17-01-2004 à 21:18:21    

serryi a écrit :

AMD c'est pas japonnais??


 
 :whistle:

Reply

Marsh Posté le 17-01-2004 à 21:19:22    

+1 pour la pensée d'Albator.
 
Il restera Linux ou les mods pour désactiver ca quand ton cpu refuzera de décodé un MP3 si t'as pas une license dl avec wmp :eek:

Reply

Marsh Posté le 17-01-2004 à 21:58:35    

vrai que la reflexion d'albator ne manque pas de justesse (vrai aussi qu'on en entend plus parler de tcpa?? ça serait une astuce pour faire passer la pilule...)


---------------
Faut arrêter de prendre les cons pour des gens.. RIP USA...
Reply

Marsh Posté le 18-01-2004 à 00:56:19    

[Albator] a écrit :

Alors voyons voir un peu de quoi il retourne ...
Bon déja, l'article cité plus haut n'est pas clair du tout, mais bon, c'est France Info, je comprends qu'ils détaillent pas trop l'aspect technique ...
 
Pour ce que j'entendais par "collaboration OS/CPU", il reste à voir dans quel sens la communication a lieu.
Si comme l'indique bjone, le CPU peut remonter à l'OS des infos comme quoi il a bloqué l'exécution de code suite à un débordement de tampon, d'accord, c'est utile (mais je trouve quand même bizarre que le hard doive combler des lacunes du soft ...) Parce que faut être vachement fortiche pour trouver une faille de sécurité dans le microcode d'un processeur.
 
Maintenant ce qui m'inquiète, c'est la communication dans l'autre sens: que l'OS puisse interdire si directement l'exécution de code au CPU.
L'OS n'a pas besoin d'interdire quoi que ce soit au processeur,
c'est le processeur qui détecte de lui même les parties de code dangereux et qui en interdit l'exécution. Le cpu est autonome dans ce processus et la mise à jour du système n'est nécessaire que pour gérer les nouveaux codes d'erreurs renvoyé par le processeur et ainsi alerter l'utilisateur.

 
Voici le futur de la sécurité informatique:
 
Etape 1: l'OS interdit l'exécution de code malicieux lors de débordement de tampon.
Etape 2: mise à jour de l'OS, maintenant il demande au CPU de n'exécuter aucun code, sauf le code spécialement autorisé.
Etape 3: encore une mise à jour de l'OS, maintenant seul le code signé numériquement sera autorisé
...
Ca vous rappelle rien ?


 
Non le pb c'est que les auteurs de virus trouveront bien un autres moyens => champ d'action de cette technologie assez limité.
 
Et puis le deuxième hic c'est que tout un tas de programme codé à la va comme je te pousse vont déclenché tout un tas de fausses alertes. C'est le principal défault des antivirus Hardware ils ne savent pas faire le tri entre les alerte "normale" et les vrais attaques de virus. ( Ceux qui ont un jour activé l'antivirus du bios doivent le savoir ).

Reply

Marsh Posté le 18-01-2004 à 13:54:52    

l'antivirus du bios est pas hardware, il s'intercale devant les services du bios pour filtrer les écritures sur le secteur de boot.
enfin les antivirus de bios s'est un peu dladaub :D

Reply

Marsh Posté le 18-01-2004 à 13:59:25    

bjone a écrit :

l'antivirus du bios est pas hardware, il s'intercale devant les services du bios pour filtrer les écritures sur le secteur de boot.
enfin les antivirus de bios s'est un peu dladaub :D


 
surtout que ça créé des soucis a l'install des os

Reply

Marsh Posté le 18-01-2004 à 19:18:41    

[Albator] a écrit :

Alors voyons voir un peu de quoi il retourne ...
Bon déja, l'article cité plus haut n'est pas clair du tout, mais bon, c'est France Info, je comprends qu'ils détaillent pas trop l'aspect technique ...
 
Pour ce que j'entendais par "collaboration OS/CPU", il reste à voir dans quel sens la communication a lieu.
Si comme l'indique bjone, le CPU peut remonter à l'OS des infos comme quoi il a bloqué l'exécution de code suite à un débordement de tampon, d'accord, c'est utile (mais je trouve quand même bizarre que le hard doive combler des lacunes du soft ...)


Le hard et le soft comblent mutuellement les lacunes de l'autre et ce sera tant qu'on aura pas de systemes parfait (C.A.D jamais). L'intéret d'intégrer ça au CPU c'est que ça le rends indépendant d'éventuelles failles de sécurité de l'OS et donc bien plus difficile (voir impossible) à contourner.
 
Enfin, si tu préfère avoir des blaster et compagnie, c'est comme tu le sens [:spamafote]

[Albator] a écrit :


Maintenant ce qui m'inquiète, c'est la communication dans l'autre sens: que l'OS puisse interdire si directement l'exécution de code au CPU.  


Etant donné que sur les systemes multitache préemptif c'est l'OS qui controle tout le code executé par le CPU, ce que tu indique existe déjà dans tout OS qui se respecte.
 

[Albator] a écrit :


Voici le futur de la sécurité informatique:
 
Etape 1: l'OS interdit l'exécution de code malicieux lors de débordement de tampon.
Etape 2: mise à jour de l'OS, maintenant il demande au CPU de n'exécuter aucun code, sauf le code spécialement autorisé.
Etape 3: encore une mise à jour de l'OS, maintenant seul le code signé numériquement sera autorisé
...
Ca vous rappelle rien ?


ce que tu cite apartient déjà au présent, ça dépends juste des domaines d'application. Dans certain domaine militaires par exemple, on serait à l'étape 4 ou 5 selon ta classification [:spamafote]


---------------
"I wonder if the internal negative pressure in self pumping toothpaste tubes is adjusted for different market altitudes." John Carmack
Reply

Marsh Posté le 19-01-2004 à 12:34:24    

mareek a écrit :


Le hard et le soft comblent mutuellement les lacunes de l'autre et ce sera tant qu'on aura pas de systemes parfait (C.A.D jamais). L'intéret d'intégrer ça au CPU c'est que ça le rends indépendant d'éventuelles failles de sécurité de l'OS et donc bien plus difficile (voir impossible) à contourner.
 


 
ben si le control de cette fontion se fait par l'os (ce qui semble sous entendu dans la news) alors elle ne servirais pas a grand chose nan :??:
 


---------------
LoD 4 ever && PWC spirit|Le topak de l'iMP-450|inDATOUNEwe trust
Reply

Marsh Posté le 19-01-2004 à 12:36:43    

bin nan, puisque ça suppose que l'état initial du soft est sain.

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed