Side-Channel Attacks : Spectre, Meltdown et Rowhammer

Les attaques par canaux auxiliaires (side-channel attacks) exploitent les fuites d'information physiques des systèmes informatiques — temps d'exécution, consommation énergétique, émissions électromagnétiques, comportement du cache CPU — pour extraire des secrets cryptographiques et contourner les isolations logicielles. Spectre, Meltdown et Rowhammer ont révolutionné la sécurité informatique en démontrant que les optimisations matérielles (exécution spéculative, prédiction de branchements, densité DRAM) créent des vulnérabilités fondamentales impossibles à corriger par le seul logiciel. Ce guide technique couvre l'ensemble du spectre des attaques side-channel modernes, depuis les fondements théoriques jusqu'aux techniques d'exploitation pratiques, en passant par les mitigations déployées et leurs contournements. Les architectes sécurité, les chercheurs en cryptographie et les développeurs de systèmes critiques trouveront ici une référence complète avec des exemples de code et des analyses de CVE.

Taxonomie des Attaques Side-Channel

Les attaques par canaux auxiliaires se classifient selon le type de fuite exploitée :

Attaques Cache : Fondamentaux

Les caches CPU sont des mémoires rapides hiérarchiques (L1, L2, L3) qui stockent les données récemment accédées. Le principe des attaques cache est simple : un cache hit (donnée présente dans le cache) est significativement plus rapide qu'un cache miss (donnée absente, chargée depuis la RAM). En mesurant le temps d'accès à une adresse mémoire, un attaquant peut déterminer si cette adresse a été récemment accédée — par lui-même ou par un autre processus partageant le cache.

Flush+Reload : La Technique Canonique

Flush+Reload exploite le partage de pages physiques entre processus (via les bibliothèques partagées ou la déduplication mémoire) :

// Flush+Reload : mesurer si une ligne de cache a été accédée
#include <x86intrin.h>

#define CACHE_HIT_THRESHOLD 80  // cycles

void flush_reload(void *addr) {
    unsigned int junk;
    
    // 1. FLUSH : évict la ligne de cache
    _mm_clflush(addr);
    _mm_mfence();
    
    // 2. Attendre que la victime exécute son code
    // (La victime accède ou non à addr selon le secret)
    
    // 3. RELOAD : mesurer le temps d'accès
    uint64_t t1 = __rdtscp(&junk);
    volatile uint8_t val = *(volatile uint8_t *)addr;
    uint64_t t2 = __rdtscp(&junk);
    
    uint64_t delta = t2 - t1;
    if (delta < CACHE_HIT_THRESHOLD) {
        // Cache HIT → la victime a accédé à cette adresse
        printf("Accès détecté ! (%lu cycles)\n", delta);
    } else {
        // Cache MISS → la victime n'a PAS accédé à cette adresse
    }
}

Spectre Variant 1 : Bounds Check Bypass (CVE-2017-5753)

Spectre v1 exploite l'exécution spéculative du processeur : quand une branche conditionnelle n'est pas encore résolue, le CPU exécute spéculativement le chemin le plus probable (basé sur l'historique de branchement). Si la spéculation est incorrecte, les résultats architecturaux sont annulés — mais les effets microarchitecturaux (lignes de cache chargées) persistent et sont observables via Flush+Reload.

// Code vulnérable à Spectre v1
uint8_t array1[256];
uint8_t array2[256 * 512];  // Probe array
size_t array1_size = 16;

// Fonction avec bounds check contournable par spéculation
void victim_function(size_t x) {
    if (x < array1_size) {              // Bounds check
        uint8_t secret = array1[x];      // Accès spéculatif OOB si x >= 16
        uint8_t dummy = array2[secret * 512]; // Encode le secret dans le cache
    }
}

// Attaque :
// 1. Entraîner le branch predictor avec des valeurs valides (x < 16)
// 2. Évict array1_size du cache (pour retarder la résolution du bounds check)
// 3. Appeler victim_function(malicious_x) où malicious_x pointe vers le secret
// 4. Le CPU exécute spéculativement : lit array1[malicious_x] (le secret)
//    puis accède à array2[secret * 512] (encode dans le cache)
// 5. Flush+Reload sur array2 pour extraire la valeur du secret

Spectre Variant 2 : Branch Target Injection (CVE-2017-5715)

Spectre v2 cible la prédiction de branchements indirects (BTB — Branch Target Buffer). L'attaquant entraîne le BTB pour qu'une instruction de branchement indirect (jmp [rax], call [rbx]) soit spéculativement redirigée vers un gadget choisi. Ce gadget exécute spéculativement du code qui fuite des données via le cache. Spectre v2 est particulièrement dangereux dans les contextes de virtualisation (guest-to-host) et dans les interpréteurs JIT (JavaScript).

Mitigation principale : les retpolines (return trampolines) remplacent les branches indirectes par des séquences utilisant ret et la pile, contournant le BTB. Mais les retpolines ont un coût de performance de 5-15% et sont contournées par les attaques sur le RSB (Return Stack Buffer) comme SpectreRSB.

Meltdown : Lecture de Mémoire Kernel (CVE-2017-5754)

Meltdown exploite une faille plus fondamentale que Spectre : sur les processeurs Intel (et certains ARM), une instruction de lecture en userspace accédant à la mémoire kernel est exécutée spéculativement avant que la vérification de permissions ne déclenche une exception. Le résultat de la lecture (la donnée kernel) est transitoirement disponible dans les registres du pipeline et peut être encodé dans le cache via un accès dépendant. Mitigation : KPTI (Kernel Page Table Isolation) sépare les tables de pages — le kernel n'est pas mappé dans l'espace d'adressage utilisateur.

MDS : Microarchitectural Data Sampling

Les attaques MDS (2019) exploitent les buffers internes du CPU (line fill buffer, load port, store buffer) qui peuvent contenir des données d'autres contextes de sécurité :

• RIDL (Rogue In-Flight Data Load) : lit des données depuis le line fill buffer, permettant la lecture de données d'autres processus, VMs, ou du kernel.
• Fallout : exploite le store buffer pour lire des données récemment écrites par d'autres contextes.
• ZombieLoad : lit des données de chargements avortés (faulting loads) depuis le line fill buffer.
• TAA (TSX Asynchronous Abort) : exploite les aborts TSX pour accéder aux données dans les buffers internes.

Rowhammer : Bit-Flips dans la DRAM

Rowhammer est une vulnérabilité physique de la mémoire DRAM : l'activation répétée (martèlement) d'une rangée de cellules DRAM cause des bit-flips dans les rangées adjacentes. Ce phénomène est dû à l'interférence électrique entre les cellules densément empaquetées. L'attaquant peut provoquer des bit-flips dans des données qu'il ne contrôle pas — y compris les tables de pages (PTE), les métadonnées de fichiers, et les structures de sécurité du kernel.

// Rowhammer : martèlement de rangées DRAM
void rowhammer(void *addr_a, void *addr_b) {
    // addr_a et addr_b sont dans des rangées DRAM différentes
    // mais adjacentes à la rangée victime
    for (int i = 0; i < 1000000; i++) {
        // Accéder alternativement aux deux adresses
        *(volatile char *)addr_a;
        *(volatile char *)addr_b;
        // Flush pour forcer l'accès DRAM à chaque itération
        _mm_clflush(addr_a);
        _mm_clflush(addr_b);
    }
    // Les rangées entre addr_a et addr_b peuvent avoir des bit-flips
}

Exploitation Pratique de Rowhammer

Les exploits Rowhammer pratiques incluent :

• Rowhammer.js : Rowhammer depuis JavaScript dans le navigateur, sans accès à clflush. Utilise les évictions de cache via des accès mémoire calculés pour atteindre la DRAM.
• Flip Feng Shui : combine Rowhammer avec la déduplication mémoire (KSM) dans les VMs. L'attaquant crée des pages identiques aux pages de la victime, le KSM les fusionne, puis un bit-flip corrompt la page partagée.
• RAMBleed : utilise Rowhammer pour lire (pas seulement écrire) la mémoire du kernel en observant quels bits flippent en fonction des données de la rangée victime.
• TRRespass : contourne les mitigations TRR (Target Row Refresh) des DDR4 en utilisant des patterns de martèlement non-uniformes (many-sided Rowhammer).
• Half-Double : Rowhammer à distance — les bit-flips affectent des rangées non directement adjacentes, contournant les mitigations basées sur la distance.

Timing Attacks sur les Implémentations Cryptographiques

Les implémentations cryptographiques naïves leakent des informations via le temps d'exécution. Exemples classiques :

• Timing attack sur RSA : le temps de l'exponentiation modulaire dépend des bits de la clé privée (square-and-multiply). Mitigation : exponentiation en temps constant avec Montgomery multiplication.
• AES T-table attack : les implémentations AES basées sur des lookup tables ont des temps d'accès dépendants de la clé via le cache. Mitigation : implémentations bitsliced ou AES-NI hardware.
• Padding oracle (Bleichenbacher, Vaudenay) : les messages d'erreur différents pour "padding invalide" vs "MAC invalide" permettent de déchiffrer des messages RSA-PKCS#1 v1.5 et CBC-mode.

Power Analysis : SPA et DPA

Les attaques par analyse de consommation ciblent principalement les cartes à puce et les systèmes embarqués :

• SPA (Simple Power Analysis) : une seule trace de consommation suffit pour identifier les opérations (multiplication vs squaring dans RSA).
• DPA (Differential Power Analysis) : analyse statistique de milliers de traces pour extraire les bits de clé AES/DES. Exploite la corrélation entre la consommation et le poids de Hamming des données.
• CPA (Correlation Power Analysis) : variante de DPA avec un modèle de fuite plus précis (modèle de Hamming weight ou Hamming distance).

Mitigations et Coûts de Performance

Les mitigations des attaques side-channel ont un impact significatif sur les performances :

FAQ — Questions Fréquentes