Les processeurs Intel x86 souffriraient d'un défaut
Qui exposerait la mémoire noyau et impacterait surtout sur le marché serveur

Le , par Christian Olivier, Chroniqueur Actualités
Des rapports circulant depuis quelques jours sur la toile font état d’une vulnérabilité qui affecterait de manière spécifique (c’est encore spéculatif) les processeurs modernes de l’entreprise américaine Intel (génération ≥ Pentium Pro). Cette vulnérabilité pourrait être considérée comme majeure parce qu’elle mettrait en exergue un éventuel problème de sécurité sur les processeurs Intel suffisamment grave pour obliger Microsoft et Linus Torvalds à produire à la hâte des patchs spécifiques pour leurs OS respectifs.

Si au départ la vulnérabilité, telle qu’elle avait été rapportée, avait pu faire croire que l’ensemble des processeurs exploitant l’architecture x86 64-bits étaient concernés, une déclaration récente d’AMD a permis de voir un peu plus clair dans cette affaire.

« Les processeurs AMD ne sont pas concernés par les attaques contre lesquelles les techniques d’isolation de la table du noyau protègent. La microarchitecture AMD n’autorise pas les références mémoire, y compris les exécutions spéculatives, qui tentent d’accéder à des données à privilèges plus élevés alors qu’elles s’exécutent dans un mode privilégié inférieur quand cet accès est susceptible d’entraîner une erreur », pouvait-on lire dans le communiqué de la firme de Sunnyvale.

On pourrait donc supposer que la firme de Sunnyvale dispose d’informations encore sous embargo pour clamer ne pas être concernée même s’il faut éviter de tirer des conclusions hâtives tant que toute la lumière n’aura pas été faite sur cette affaire et les détails rendus publics. Au passage, il faut signaler que les processeurs basés sur les architectures ARM/RISC ne semblent pas être affectés.


L’exécution spéculative est essentiellement une forme de préemption qui tente de prédire quel code va être exécuté après un branchement, puis de l’extraire et de l’exécuter avant que l’ordre réel n’arrive. Les processeurs modernes ont une architecture en pipeline : ils traitent un grand nombre d'instructions simultanément, en avançant un petit peu dans chacune à chaque cycle. Si un branchement est mal prédit, tout le pipeline doit être vidé : la perte en performance est loin d'être négligeable. Cette technique a ses avantages, mais elle présente également un risque non négligeable pour la sécurité, car aucune vérification de privilège n’est présente au niveau du noyau du système d'exploitation.

Le problème réside dans le fait que vous pouvez exploiter cette fonctionnalité pour exécuter de manière spéculative un code qui devrait être normalement bloqué en stoppant l’exécution du code avant qu’une vérification puisse être effectuée. Cela signifie en gros qu’une application de niveau 3 (droits normaux) peut lire les données du noyau de niveau 0 (réservé à l'exécution du noyau) en utilisant une exécution spéculative, car la vérification de privilège ne sera pas effectuée avant que le code ne soit exécuté.

Tout serait parti d’un article de blog paru en juillet 2017. Son auteur y décrivait une expérience dans laquelle il tente d’accéder à la mémoire protégée utilisée par le noyau à partir de l’espace utilisateur, l’espace mémoire utilisé par les programmes classiques, en exploitant les mécanismes d’exécution spéculative intégrés dans les CPU x86 64-bits modernes.

Ces processeurs disposent d’unités spécialisées dans la gestion de la mémoire (MMU) qui permettent de contrôler les accès qu’un CPU fait à la mémoire de l’ordinateur. Ils peuvent fonctionner suivant au moins deux modes de fonctionnement, dont un mode noyau qui n’impose pas de restrictions sur les instructions exécutées, et un mode utilisateur qui limite ce que peuvent faire les instructions.

Habituellement, le système d’exploitation met en œuvre cette distinction en faisant fonctionner les autres programmes en mode utilisateur et en se réservant le mode noyau. Cette distinction entre espace utilisateur et espace noyau est à la base du contrôle d’accès qui empêche les instructions des applications de l’espace utilisateur d’accéder à une zone mémoire ne leur appartenant pas. On parle aussi de lecture d’une adresse mémoire non autorisée lorsque ce dysfonctionnement survient. Cette situation débouche rapidement sur une trappe du noyau et, en général, la fermeture du programme incriminé. Il faut noter que la trappe est déclenchée par une interruption matérielle et le mécanisme de protection mémoire ne peut être implémenté efficacement de façon logicielle.


L’auteur du blog a essayé de s’attaquer à ce mécanisme en tentant d’exploiter l’intervalle de temps pendant lequel une instruction non autorisée est exécutée et génère une interruption. Même s’il a précisé ne pas avoir réussi à lire la mémoire protégée grâce à sa méthode, il s’est rendu compte que le chargement mémoire interdit est bel et bien effectué par le CPU même si le processeur ne copie jamais l’information dans le registre. Il a remarqué que l’exécution spéculative se poursuivait dans les unités d’exécutions internes du CPU jusqu’à ce que l’interruption soit effective et que cette situation pouvait favoriser la survenue d’attaques potentielles basées, par exemple, sur les temps d’exécution des instructions pour déterminer les adresses mémoires utilisées par le noyau.

Qu’il soit possible, à partir d’un programme utilisateur, de déterminer les adresses mémoire utilisées par le noyau est une situation qui ne devrait pas se produire. Différentes techniques ont d’ailleurs été mises au point depuis des années pour respecter ce principe, l’une des méthodes les plus efficaces à l’heure actuelle étant l’ASLR (Address Space Layout Randomization). Cette dernière attribue un caractère aléatoire aux adresses mémoires utilisées par les applications et le noyau.

Cette « vulnérabilité matérielle » (parce que liée au fonctionnement spécifique des CPU modernes d’Intel comme semble le confirmer le mémo d’AMD) permettrait d’exploiter des processus en espace utilisateur en contournant la MMU et d’accéder à la mémoire noyau. Le problème étant matériel, dans la partie non reconfigurable du processeur, il ne serait apparemment pas envisageable de recourir à un patch via microcode pour corriger cette faille de sécurité.

La seule façon de contourner cette fonctionnalité au niveau logiciel serait d’utiliser une technique d’isolation de la table de correspondance (entre les adresses en mémoire virtuelle et en mémoire physique) du noyau (en anglais, KPTI) : cela rendrait le noyau complètement aveugle et le retirerait de l’espace mémoire virtuel jusqu’à ce qu’un appel système survienne. Il faudrait donc laisser aux éditeurs d’OS le soin de concevoir ces patchs via le système d’exploitation pour leurs produits respectifs.

À ce propos, il faut signaler que, durant ces derniers mois, KAISER, une nouvelle solution de sécurité proactive dédiée au noyau Linux, a vu le jour. Cette solution, qui a été renommée par la suite KPTI (Kernel Page Table Isolation), est censée limiter de manière significative l’impact d’éventuelles failles présentes ou à venir et mieux protéger les espaces mémoire du noyau. Il permettrait notamment de séparer les tables qui pointent vers les pages mémoires utilisées par le noyau de toutes les autres. Le 30 décembre dernier, Linus Torvalds a intégré KPTI directement dans la version 4.15-rc6 du noyau Linux et recommandé l’intégration de ce patch dans tous les noyaux encore maintenus, ce qui pourrait laisser penser que le problème devait être suffisamment grave pour que de telles mesures soient adoptées. Microsoft aurait également préparé des correctifs similaires à KPTI pour le noyau de Windows depuis novembre dernier.

Le problème avec ces patchs, c’est qu’ils introduisent une pénalité de temps pour le système et qu’ils ont un impact non négligeable sur les performances de certains types d’applications. Celles qui effectuent beaucoup d’appels aux instructions système devraient être les plus affectées. Pour une utilisation non serveur, tout semble pointer vers un impact nul ou infinitésimal. Côté serveur l’impact serait plus large et pourrait affecter massivement les infrastructures cloud où la virtualisation, très gourmande en appels système, est largement utilisée.

Source : Cyber WTF, AMD, Twitter info patch Windows, WccfTech

Et vous ?

Qu’en pensez-vous ?

Voir aussi

Les processeurs Intel x86 souffrent d'un défaut qui permet d'installer des logiciels malveillants dans l'espace protégé des puces


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de disedorgue disedorgue - Expert éminent https://www.developpez.com
le 04/01/2018 à 11:23
A priori, AMD est ARM sont aussi concernés.
Avatar de codec_abc codec_abc - Membre averti https://www.developpez.com
le 04/01/2018 à 11:24
Ce n'est plus du tout spéculatif. Google a publié les papiers de recherche qui expliquent les vulnérabilités ont étés publiés. La plus grave (Meltdown), n'affecte que les processeurs Intel tandis que la moins facilement exploitable (Spectre) fonctionne sur pas mal de processeurs (Intel, AMD et ARM).

Lien: Spectre et Meltdown

En bonus, la mauvaise fois ultime d'Intel. Juste pour ça, mon prochain CPU sera un AMD, car foirer un design sur un CPU c'est déjà pas génial mais répondre "Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers." le jour de la publication de la faille c'est juste nous prendre pour des cons.
Avatar de RyzenOC RyzenOC - Inactif https://www.developpez.com
le 04/01/2018 à 11:26
Depuis ce matin il semble que ce problème impacte aussi les cpu ARM et IBM Power 8/9.
AMD serait aussi un peu touché (Spectre) mais moins que intel.

A titre personnel je n'appliquerais pas le patch sur mes serveur linux. La perte de perf est trop importante et la faille est quand même difficilement exploitable pour un hacker. Il faut réunir quand même pas mal de condition pour l'exploiter.
Avatar de codec_abc codec_abc - Membre averti https://www.developpez.com
le 04/01/2018 à 11:36
Si tu parles de Meltdown, j'ai pas l'impression que la faille soit dur a exploiter, il suffit juste d'un programme en user-space. Si tu as des données un tant soit peu importante c'est stupide de ne pas appliquer le patch.
Avatar de Ryu2000 Ryu2000 - Membre extrêmement actif https://www.developpez.com
le 04/01/2018 à 12:09
Citation Envoyé par Christian Olivier Voir le message
Qu’en pensez-vous ?
Il parait qu'après la correction la perte de performance peut être entre 5 et 30%.

Avec un peu de chance Intel va baisser le prix de ces processeurs.
Je me trouverais bien un Intel Core i7-7700K (4.2 GHz / Quad Core / Cache 8 Mo).
Mais 330€ ça fait encore une peu mal ^^

Avec ça Dolphin devrait bien tourner j'imagine.

Ou alors un AMD Ryzen 7 1700X (3.4 GHz / Octo Core / Cache 20 Mo).
Mais les performances monocœurs sont moins bonnes.
Avatar de Michael Guilloux Michael Guilloux - Chroniqueur Actualités https://www.developpez.com
le 04/01/2018 à 12:50
Les grands éditeurs et fournisseurs de cloud s'activent pour patcher leurs produits
contre les vulnérabilités dans les puces d'Intel et autres fabricants

AWS, Microsoft et Google ainsi que d'autres fournisseurs ont informé leurs clients qu'ils risquent d'être confrontés à des interruptions et à une dégradation de performance à cause de leurs efforts pour accélérer la correction des bogues critiques présents dans de nombreux processeurs. Les bogues en question sont causés par des problèmes de conception de microprocesseurs qui pourraient potentiellement permettre à un code malveillant de lire le contenu de la mémoire du noyau d'un ordinateur. Ces problèmes affectent notamment les puces Intel qui dominent le marché des serveurs cloud, mais également des puces conçues par AMD et ARM, contrairement à ce que l’on pensait au début.

Ce problème a été découvert « tard l’année dernière » par l’équipe Project Zero de Google. Les principaux fournisseurs, qui ont été informés des vulnérabilités, ont eu également le temps de préparer des correctifs pour leurs produits et commencer à les déployer, mais il reste encore du travail à faire. Avec la divulgation de ces failles hier, elles n’ont plus donc le temps d’aller à leur rythme, mais doivent accélérer le processus pour éviter que des hackers commencent à exploiter les failles. Dans différents communiqués, AWS, Microsoft et Google ont informé leurs clients de ce qui a déjà été fait à leur niveau et d’éventuelles précautions à prendre.

Google

Dans un communiqué, Google affirme que depuis la découverte de la vulnérabilité affectant les microprocesseurs modernes, ses équipes d'ingénierie s'efforcent de protéger les clients contre la vulnérabilité de l'ensemble de la gamme de produits Google, y compris Google Cloud Platform (GCP), les applications G Suite et les produits Google Chrome et Chrome OS. Google dit également avoir collaboré avec les fabricants de matériel et de logiciels de l'industrie pour protéger leurs utilisateurs et le Web en général.

En ce qui concerne ses produits en particulier, Google affirme que « toutes les applications G Suite ont déjà été mises à jour pour bloquer tous les vecteurs d'attaque connus. Les clients et les utilisateurs de G Suite n'ont besoin d'aucune action pour se protéger de cette vulnérabilité. GCP a également déjà été mis à jour pour éviter toutes les vulnérabilités connues », mais « les clients qui utilisent leurs propres systèmes d'exploitation avec les services GCP pourraient avoir besoin d'appliquer des mises à jour supplémentaires à leurs images ». Enfin, Google fait savoir que les clients qui utilisent le navigateur Chrome, y compris G Suite ou GCP, peuvent tirer parti de la fonctionnalité d'isolation de sites pour renforcer leur sécurité sur les plateformes de bureau, y compris Chrome OS.

Amazon

Concernant la vulnérabilité, AWS indique qu'elle existe depuis plus de 20 ans dans les architectures de processeurs modernes telles que Intel, AMD et ARM sur des serveurs, desktops et périphériques mobiles ; avant d'ajouter que « tout sauf un petit pourcentage à un chiffre des instances de la flotte Amazon EC2 est déjà protégé ». Pour ce qui est des instances restantes, leur protection sera terminée « dans les prochaines heures » d'après Amazon. Le géant du cloud précise toutefois que si les mises à jour effectuées par AWS protègent l'infrastructure sous-jacente, afin d'être entièrement protégées contre ces problèmes, les clients doivent également patcher les systèmes d'exploitation de leur instance. Au passage, des mises à jour pour Amazon Linux sont disponibles et des instructions pour la mise à jour des instances existantes sont fournies.

Microsoft

Alors que Microsoft publiait son communiqué hier, la firme de Redmond a tenu à préciser qu'elle n'a reçu aucune information indiquant que ces vulnérabilités ont été utilisées pour attaquer les clients Azure. Et d'ajouter que « la majorité de l'infrastructure Azure a déjà été mise à jour pour corriger cette vulnérabilité. Certains aspects d'Azure sont toujours en cours de mise à jour et nécessitent un redémarrage des machines virtuelles des clients pour que la mise à jour de sécurité soit appliquée », explique Microsoft.

Beaucoup des clients Azure ont reçu une notification au cours des dernières semaines à propos d'une maintenance planifiée sur Azure et ont déjà redémarré leurs machines virtuelles pour appliquer le correctif. Pour ceux-ci, aucune autre action n'est requise. Avec la divulgation publique de la faille de sécurité mercredi, Microsoft a accéléré son calendrier de maintenance planifiée et a déjà commencé à redémarrer automatiquement les machines virtuelles restantes, comme l'entreprise l'a annoncé hier.

La majorité des clients Azure ne devraient pas voir d'impact notable sur les performances avec cette mise à jour. Seul « un petit groupe » de clients peut avoir un impact sur les performances de mise en réseau, mais cela peut être résolu en activant Azure Accelerated Networking (Windows, Linux), qui est une fonctionnalité gratuite disponible pour tous les clients Azure. Microsoft précise aussi que cette mise à jour de l'infrastructure Azure corrige la vulnérabilité révélée au niveau de l'hyperviseur et ne nécessite pas de mise à jour de vos images de machine virtuelle Windows ou Linux.

En ce qui concerne Windows, Microsoft a également réagi rapidement avec une mise à jour pour toutes les versions de Windows. Ce qu'il est important de savoir, cependant, c'est que seul Windows 10 reçoit automatiquement la mise à jour aujourd'hui, tandis que Windows 7 et Windows 8.1 se verront proposer la mise à jour avec le Patch Tuesday, la semaine prochaine. Les utilisateurs peuvent aussi l'installer manuellement via Microsoft Update Catalog.

DigitalOcean

DigitalOcean, un autre fournisseur cloud travaille également pour la protection de ses clients. « Depuis que nous avons appris ce problème, nous avons activement analysé et suivi l'activité du noyau Linux et notre équipe de développement a travaillé avec diligence pour obtenir autant d'informations que possible d'Intel. Malheureusement, l'embargo strict imposé par Intel a considérablement limité notre capacité à établir une compréhension globale de l'impact potentiel. »

« Sur la base de nos investigations et des informations que nous avons reçues jusqu'à présent, nous pensons qu'il peut être nécessaire de redémarrer les Droplets des clients affectés. Si les redémarrages s'avèrent être la bonne marche à suivre pour les utilisateurs de DigitalOcean, nous planifierons la maintenance urgente et aviserons les clients touchés. Nous continuons à surveiller cette situation et travaillons avec Intel pour obtenir plus de détails. »

Linux

La bonne nouvelle pour les linuxiens est que les développeurs de Linux ont déjà corrigé le noyau pour y faire face. Mais il y a aussi une mauvaise nouvelle ; c'est que le correctif va entraîner une baisse de performance d'au moins 5 %, et les applications peuvent voir leurs performances être beaucoup plus impactées. C'est le cas par exemple de PostgreSQL, comme cela est expliqué dans un message dans sa liste de diffusion.

« Les versions à venir du noyau Linux (et apparemment aussi de Windows et autres) incluront une nouvelle fonctionnalité qui a apparemment été implémentée avec hâte pour contourner un bogue matériel Intel. Le correctif va être fusionné dans la prochaine version du noyau Linux et est en train d'être intégré dans les anciennes versions. Intégrer une nouvelle entité complexe et envahissante dans une ancienne version indique que cela concerne un problème important », explique Andres Freund de l'équipe de développement de PostegreSQL. Avant d'annoncer que « le correctif entraînera malheureusement des régressions de performances » pour la base de données populaire. En ce qui concerne l'impact exact, dans certains cas, PostgreSQL pourrait connaitre un ralentissement d'au moins 17 % d'après des tests d'Andres Freund.

Sources : Google, AWS, Microsoft, Liste de diffusion PostgreSQL, DigitalOcean

Et vous ?

Qu'en pensez-vous ?
Avatar de abriotde abriotde - Membre éprouvé https://www.developpez.com
le 04/01/2018 à 14:05
il suffit juste d'un programme en user-space
Oui enfin c'est surtout que techniquement c'est assez difficile à exploiter, il semble falloir analyser tous l'espace d'adressage pour réussir à déterminer des adresse noyau (et a priori faire planter son programme des millions de fois) et ensuite arriver à comprendre qu'est-ce qu'il y a derrière ces adresses... la pluspart des malware n'ont pas envie de se casser la tête avec ça, il y a d'autres failles à exploiter plus facilement avant. Récupérer les données bancaires leur suffit
Par contre pour ceux qui se pencheront dessus, l'avantage que cela procure au programme c'est de pouvoir alors avoir un accès root mais plus que ça, pouvoir s'installer dans le système d'amorçage de l'ordinateur ou en mémoire noyau à un endroit ou il ne pourra pas être détecter par un anti-virus qui lui tourne en espace utilisateur (en root).
Alors il est vrai que ce n'est pas la peine de paniquer car ce sera peu exploiter et pas tout de suite mais ceux qui l'exploiteront auront tous de même un sacré avantage.
Avatar de RyzenOC RyzenOC - Inactif https://www.developpez.com
le 04/01/2018 à 14:20
Citation Envoyé par codec_abc Voir le message
Si tu parles de Meltdown, j'ai pas l'impression que la faille soit dur a exploiter, il suffit juste d'un programme en user-space. Si tu as des données un tant soit peu importante c'est stupide de ne pas appliquer le patch.
comme la dit abriotde c'est pas aussi simple.
le bogue ne semble pas permettre une lecture directe des données dans l'espace d'adressage réservé au noyau, mais il permet en revanche de déduire du comportement du CPU, lorsqu'il exécute une séquence de code bien particulière et en observant le temps qui lui est nécessaire pour l'exécuter, s'il y a ou non des données du noyau à une adresse virtuelle.

De là à en tirer une exploitation ( "exploit" ) pratique pour lire des informations précises (clefs, mots de passe) ou encore modifier les données du noyau, il y a encore beaucoup de boulot...

Bref, la rustine de contournement (qui impacte les performances de *tous* les appels système et de *toutes* les interruptions matérielles) est très largement inutile

Il faut comprendre que ce genre de problème ne date pas d'hier

- attaque: buffer-overflow + accès en mémoire (appli, lib, kernel, driver ...)
- solution: isolation de la mémoire user et de la mémoire kernel (switch de mode)

- problème: cette solution est lente (switch de mode => reset des caches mémoires)
- solution: on supprime l'isolation mais on controle les accès en mémoire kernel (privilèges).

- attaque: buffer-overflow + contournement de privilège + accès aux structures du kernel
- solution KASR (Kernel ASR): impossible de prédire l'adresse des structures du kernel...

- bug: (sous embargo) on peut "prédire" les adresses des structures du kernel
- solution: on revient au mode isolation kernel/user

- problème: cette solution est toujours aussi lente :transpi:
- solution: ???
Avatar de codec_abc codec_abc - Membre averti https://www.developpez.com
le 04/01/2018 à 14:50
Citation Envoyé par abriotde Voir le message
Oui enfin c'est surtout que techniquement c'est assez difficile à exploiter, il semble falloir analyser tous l'espace d'adressage pour réussir à déterminer des adresse noyau (et a priori faire planter son programme des millions de fois) et ensuite arriver à comprendre qu'est-ce qu'il y a derrière ces adresses... la pluspart des malware n'ont pas envie de se casser la tête avec ça, il y a d'autres failles à exploiter plus facilement avant. Récupérer les données bancaires leur suffit
Par contre pour ceux qui se pencheront dessus, l'avantage que cela procure au programme c'est de pouvoir alors avoir un accès root mais plus que ça, pouvoir s'installer dans le système d'amorçage de l'ordinateur ou en mémoire noyau à un endroit ou il ne pourra pas être détecter par un anti-virus qui lui tourne en espace utilisateur (en root).
Alors il est vrai que ce n'est pas la peine de paniquer car ce sera peu exploiter et pas tout de suite mais ceux qui l'exploiteront auront tous de même un sacré avantage.
Comme dit dans le papier, il existe des techniques qui permettent de supprimer l'exception qui fait planter le programme, donc non le programme de plantera pas des millions de fois.

Aussi, il n'y pas pas besoin de dumper toute la mémoire car et la plupart des programmes (surtout natif) ont souvent des patterns d'allocations bien déterministe ce qui rend beaucoup plus rapide la recherche et l'analyse de la mémoire pour un programme malveillant. Bref, Meltdown n'est pas clairement pas impossible a mettre en œuvre, loin de la même. Pour rappel on a déjà eu Stuxnet qui consistait quand même a faire un virus qui reprogrammais les automates des centrifugeuses des centrales iraniennes pour ralentir leur programme nucléaire. Donc ça m'étonnerait que certaines organisation ne s'intéresse pas à cette faille qui leur laisse la porte ouverte a tout PC équipé d'un CPU Intel de moins de 10 ans.
Avatar de MiaowZedong MiaowZedong - Membre extrêmement actif https://www.developpez.com
le 04/01/2018 à 16:14
Citation Envoyé par codec_abc Voir le message
Ce n'est plus du tout spéculatif. Google a publié les papiers de recherche qui expliquent les vulnérabilités ont étés publiés. La plus grave (Meltdown), n'affecte que les processeurs Intel tandis que la moins facilement exploitable (Spectre) fonctionne sur pas mal de processeurs (Intel, AMD et ARM).

Lien: Spectre et Meltdown

En bonus, la mauvaise fois ultime d'Intel. Juste pour ça, mon prochain CPU sera un AMD, car foirer un design sur un CPU c'est déjà pas génial mais répondre "Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers." le jour de la publication de la faille c'est juste nous prendre pour des cons.
"Moins facile à exploiter", c'est vite dit. Spectre requiert certes un ralentissement qui sera visible de l'utilisateur, et un code complexe, mais potentiellement un JavaScript executé dans le browser sans rien demander à l'utilisateur pourrait piller des cookies d'authentification ou des mots de passe. Et pour le ralentissement (qui ferait sans doute rebooter sa machine à l'utilisateur lambda), les papiers précisent qu'il "y a de la place pour optimiser". Et encore heureux que ce soit difficile à executer, parce que ce n'est pas loin d'être la faille ultime.
Contacter le responsable de la rubrique Accueil