Heartbleed

Le bug Heartbleed CVE-2014-0160 est un défaut d'implémentation grave dans la bibliothèque OpenSSL, qui permet à des attaquants de voler des données depuis la mémoire du serveur victime. Le contenu des données volées dépend de ce qui se trouve dans la mémoire du serveur. Il peut potentiellement contenir des clés privées, des clés de session TLS, des noms d'utilisateur, des mots de passe, des cartes de crédit, etc. La vulnérabilité se situe dans l'implémentation du protocole Heartbeat, utilisé par SSL/TLS pour maintenir la connexion active.

La plage de versions d'OpenSSL concernée va de 1.0.1 à 1.0.1f. La version dans la VM Ubuntu est 1.0.1.

L'attaque Heartbleed est basée sur la requête Heartbeat. Cette requête envoie simplement des données au serveur, et le serveur copie les données dans son paquet de réponse, de sorte que toutes les données sont renvoyées. Dans le cas normal, supposons que la requête contient 3 octets de données ”ABC”, le champ de longueur a donc une valeur de 3. Le serveur place les données en mémoire et copie 3 octets depuis le début des données dans son paquet de réponse. Dans le scénario d'attaque, la requête peut contenir 3 octets de données, mais le champ de longueur peut indiquer 1003. Lorsque le serveur construit son paquet de réponse, il copie depuis le début des données (c'est-à-dire “ABC”), mais il copie 1003 octets au lieu de 3 octets. Ces 1000 octets supplémentaires ne proviennent évidemment pas du paquet de requête ; ils proviennent de la mémoire privée du serveur et peuvent contenir des informations d'autres utilisateurs, des clés secrètes, des mots de passe, etc.

Ensuite, modifions le champ de longueur de la requête. Tout d'abord, comprenons comment le paquet de réponse Heartbeat est construit à partir de la figure ci-dessus. Lorsque le paquet de requête Heartbeat arrive, le serveur analyse le paquet pour obtenir la charge utile et la valeur Payload_length (surlignée ci-dessus). Ici, la charge utile est seulement une chaîne de 3 octets "ABC" et la valeur Payload_length est exactement 3. Le programme du serveur prend aveuglément cette valeur de longueur depuis le paquet de requête. Il construit ensuite le paquet de réponse en pointant vers la mémoire contenant "ABC" et copie Payload_length octets dans la charge utile de la réponse. De cette façon, le paquet de réponse contiendrait une chaîne de 3 octets "ABC".

Ensuite, lançons l'attaque Heartbleed comme illustré dans la figure ci-dessous. Gardez la même charge utile (3 octets), mais définissez le champ Payload_length sur 1003. Le serveur prendra encore aveuglément cette valeur Payload_length lors de la construction du paquet de réponse. Cette fois, le programme du serveur pointera vers la chaîne "ABC" et copiera 1003 octets depuis la mémoire dans le paquet de réponse comme charge utile. Outre la chaîne ”ABC”, les 1000 octets supplémentaires sont copiés dans le paquet de réponse, et ils peuvent contenir n'importe quoi provenant de la mémoire, comme des activités secrètes, des informations de journalisation, des mots de passe, etc.

Le code d'attaque permet de modifier la valeur Payload_length. Par défaut, la valeur est définie sur une valeur assez grande (0x4000), mais elle peut être réduite.

Le moyen le plus simple de corriger la vulnérabilité Heartbleed est de mettre à jour la bibliothèque OpenSSL vers la version la plus récente. Cependant, l'objectif est de corriger la vulnérabilité via le code source.

Format du paquet de requête/réponse Heartbeat

struct {
    HeartbeatMessageType type;  // 1 byte: request or the response
    uint16 payload_length;      // 2 byte: the length of the payload
    opaque payload[HeartbeatMessage.payload_length];
    opaque padding[padding_length];
} HeartbeatMessage;

Le premier champ (1 octet) du paquet est l'information de type, et le deuxième champ (2 octets) est la longueur de la charge utile, suivi de la charge utile effective et du remplissage. La taille de la charge utile doit correspondre à la valeur du champ de longueur de la charge utile, mais dans le scénario d'attaque, la longueur de la charge utile peut être définie sur une valeur différente. L'extrait de code suivant montre comment le serveur copie les données du paquet de requête vers le paquet de réponse.

Traitement du paquet de requête Heartbeat et génération du paquet de réponse

/* Allocate memory for the response, size is 1 byte
 * message type, plus 2 bytes payload length, plus
 * payload, plus padding
*/

unsigned int payload;
unsigned int padding = 16; /* Use minimum padding */

// Read from type field first
hbtype = *p++; /* After this instruction, the pointer
                * p will point to the payload_length field */

// Read from the payload_length field from the request packet
n2s(p, payload); /* Function n2s(p, payload) reads 16 bits
                  * from pointer p and store the value
                  * in the INT variable "payload". */

pl = p; // pl points to the beginning of the payload content

if (hbtype == TLS1_HB_REQUEST)
{
    unsigned char *buffer, *bp;
    int r;

    /* Allocate memory for the response, size is 1 byte
     * message type, plus 2 bytes payload length, plus
     * payload, plus padding
     */

    buffer = OPENSSL_malloc(1 + 2 + payload + padding);
    bp = buffer;

    // Enter response type, length and copy payload *bp++ = TLS1_HB_RESPONSE;
    s2n(payload, bp);

    // copy payload
    memcpy(bp, pl, payload);   /* pl is the pointer which
                                * points to the beginning
                                * of the payload content */
    bp += payload;

    // Random padding
    RAND_pseudo_bytes(bp, padding);

    // this function will copy the 3+payload+padding bytes
    // from the buffer and put them into the heartbeat response
    // packet to send back to the request client side.
    OPENSSL_free(buffer);
    r = ssl3_write_bytes(s, TLS1_RT_HEARTBEAT, buffer, 3 + payload + padding);
}

La vulnérabilité se situe ici

    // copy payload
    memcpy(bp, pl, payload);

Il n'y a aucune vérification pour déterminer si pl est valide ou non. Par conséquent, une brèche mémoire peut se produire.

Correctifs :

• Vérification des limites avant l'exécution de memcpy()
• Le serveur calcule la taille du paquet à l'exécution, ce qui nécessite une surcharge supplémentaire

Les correctifs ont été appliqués dans la VM mais ne sont pas présentés dans ce dépôt.

Merci pour votre intérêt, ce projet était amusant et instructif !