Or, deux collègues de Sysdream, Stéfan Leberre (Heurs) et Damien Cauquil (Virtualabs), viennent de trouver une méthode permettant de la contourner sous certaines conditions. Leur article ainsi que leur Proof Of Concept est disponible sur le site de Sysdream :

• L’article Bypassing SEHOP
• Proof Of Concept fonctionnant sous Windows 7

Pour cet article, on se propose d’écrire un driver qui effectuera ce hook et qui détournera RDTSC afin de rendre les valeurs 11223344 et 55667788 respectivement dans EAX et EDX lorsqu’on l’appelle. Je présente en premier lieu la théorie nécessaire pour l’attaque, puis décris comment l’implémenter sous Linux. Enfin, je détaille une difficulté majeure à laquelle on peut faire face sur les distributions récentes telles qu’ArchLinux : le flag TIF_NOTSC.

L’instruction RDTSC et le flag TSD

RDTSC signifie « ReaD TimeStamp Counter », autrement dit elle permet de lire le compteur de temps du processeur, incrémenté à chaque cycle d’horloge. Ce compteur n’est autre que le MSR IA32_TIME_STAMP_COUNTER (cf manuel 3B d’Intel, section 18.11). Celui-ci fait 64 bits et est retourné dans EDX et EAX lors de l’appel à RDTSC. Les applications classiques s’en servent généralement pour :

• Effectuer des mesures de performance (benchmark) sans passer par les fonctions du noyau
• Générer des nombres pseudo-aléatoires, à cause du caractère à priori non prévisible de ce compteur (surtout des bits de poids faible)
• Détecter des débogueur en mesurant des deltas entre deux instructions fixes ; si un débogueur est présent et qu’un breakpoint a été posé (ou que le mode step-by-step a été utilisé), le temps écoulé sera beaucoup plus long donc il est facile à l’application de quitter.

Cependant, ce n’est pas exactement comme cela qu’est décrit l’instruction RDTSC dans le manuel 2B d’Intel. En effet, on peut y lire le pseudo-code suivant :

IF (CR4.TSD = 0) or (CPL = 0) or (CR0.PE = 0)
THEN EDX:EAX ? TimeStampCounter;
ELSE (* CR4.TSD = 1 and (CPL = 1, 2, or 3) and CR0.PE = 1 *)
#GP(0);
FI;

On y apprend que le registre CR4 possède un flag TSD qui, s’il est activé, provoquerait une exception lorsque RDTSC est appelé dans un ring supérieur à 0 (mode protégé). Cette exception est la General Protection Fault, notée #GP et définie à l’index 13 dans l’IDT (table des interruptions). L’OS traite cette exception par une routine du noyau qui n’est généralement pas prévue pour gérer ce cas, donc on aura par défaut droit à un crash du programme ayant appelé RDTSC. Sous Linux, cela se traduit par l’envoi d’un signal SIGSEGV au processus, causant une segmentation fault.

IDT hooking

Pour hooker RDTSC, il faut donc dans un premier temps mettre à 1 le flag TSD (bit 2) de CR4 pour déclencher une #GP. Mais ce que nous voulons, c’est appeler notre fonction et non celle du noyau lors de l’exception. Il va donc falloir patcher l’IDT en remplaçant l’adresse du handler 13 par le notre ; autrement dit, faire du IDT hooking.

L’IDT recense des descripteurs explicités à la section 5.11 du manuel 3A d’Intel. Les descripteurs suivant plus ou moins le même format :

Descripteur d'interruption

Comme d’habitude dans la doc Intel, le schéma se lit de bas en haut et de droite à gauche (little endian, quand tu nous tiens…). A la mode des autres descripteurs propres à l’architecture x86, on constate que le champ Offset est découpé en deux parties : poids forts et poids faibles. C’est ce champ qui pointe vers le handler à exécuter lors de l’exception. Il suffit de remplacer sa valeur par l’adresse d’une de nos fonctions, et nous pourrons alors détourner le flux d’exécution lors d’un appel ring 3 à RDTSC.

Trouver l’IDT

Pour pouvoir faire un hook de l’IDT, il faut d’abord savoir la trouver. En fait, il est nécessaire de préciser que pour les processeurs multi-coeur, il n’y a pas une seule IDT mais plusieurs :  une par cœur. Il est donc en théorie nécessaire de hooker toutes les IDT pour éviter les problèmes. Pour connaître l’IDT référencée par un cœur, il suffit d’utiliser l’instruction SIDT sur ce cœur. Cette instruction est accessible en ring 3 ; voici un code qui l’illustre. Cependant, si vous utilisez Linux dans une machine virtuelle telle que VirtualBox, il se peut que vous rencontriez des problèmes en fonction de vos options de virtualisation. En effet, l’instruction SIDT n’est pas toujours bien émulée par l’hyperviseur et il se peut que la valeur qu’elle retourne soit erronée. Préférez-donc la solution suivante si vous tenez à faire vos tests dans une VM.

Même si un procceseur peut avoir plusieurs IDT, Linux n’en utilise qu’une car chaque cœur référence la même. Celle-ci est définie dans le noyau par le symbole idt_table. Pour connaître son adresse, tentez :

grep idt_table /proc/kallsyms

Le premier champ retourné est l’addresse de l’IDT. Si cela ne vous renvoie rien, il vous faudra à la place utiliser le fichier /boot/Symbol.map, généré à la compilation du noyau. Il se peut que son nom soit quelque peu différent ; par exemple sous Ubuntu il suit le format /boot/System.map-$(uname -r) alors que sous ArchLinux il s’appelle /boot/System.map26.

Conception du handler

Une bonne conception du nouveau handler d’interruption est cruciale pour éviter de rendre instable tout le système. En effet, #GP est utilisée non seulement pour RDTSC mais aussi à chaque fois qu’un check de privilèges échoue (pour une bonne ou une mauvaise raison) dans l’OS, autrement dit un sacré paquet de fois… Autant dire qu’il est préférable de laisser l’OS gérer ces cas là tout seul.

Pour cela, il va falloir filtrer dans un premier temps les #GP dues à RDTSC et celles dues à une autre instruction. Détecter l’instruction fautive est facile vu que l’EIP a été empilé ; il suffit de le regarder, d’examiner ce qu’il pointe et de comparer cette valeur à l’opcode de RDTSC : 0F 31, soit 0x310F en mot de 16 bits little endian. Si cela ne correspond pas, on saute sur le handler de base de l’OS pour ne pas tout crasher.

Ce n’est pas tout : les programmes ring 3 de l’OS aussi utilisent RDTSC. Si nous leur rendons des valeurs comme 0×11223344, ils risquent d’avoir un comportement plutôt imprévisible, surtout s’ils s’en servent comme base de temps. J’ai d’ailleurs testé sous Linux ; Cron a segfaulté instantanément et la machine est devenue inutilisable en quelques secondes.

Bref, il faut se débrouiller pour rendre la bonne valeur à ces programmes. La solution est d’émuler RDTSC dans le driver, et de transmettre les résultats dans EAX et EDX au ring 3. Mais comment savoir quand retourner les bonnes et valeurs et les fakes ? La solution la plus simple qui m’est venue à l’esprit est d’utiliser le PIDs du processus courant, en supposant que l’on connaisse le PID à hooker. Pour transmettre au driver le PID du processus en question, on peut utiliser des IOCTLs, justement prévues pour la communication ring 3 – ring 0. Une fois que l’on a le PID, il suffit de consulter le PID courant et on peut savoir si on doit émuler RDTSC ou forger les valeurs.

Récupération du PID courant

Nous avons quasiment tout ce qu’il faut pour implémenter cette attaque sous Linux. La seule chose qu’il nous manque, c’est un moyen dé récupérer le PID du processus courant lorsque l’on est dans un handler d’interruption. Après lecture en diagonale du chapitre 7 d’Understanding The Linux Kernel 3rd edition, on constate qu’il existe une macro nommée current qui permet de récupérer un pointeur vers le descripteur de processus courant. Après avoir testé cette macro, je me suis rendu compte qu’elle ne marche en fait pas dans le contexte d’un handler d’interruption. Il faut utiliser à la place la fonction current_thread_info() qui marche à tous les coups. A partir de là, récupérer le PID est très simple, via l’expression suivante : current_thread_info()->task->pid.

Implémentation 1

Nous pouvons maintenant implémenter l’attaque. Je l’ai réalisé sans problèmes particulier sur une Ubuntu 9.04 avec un noyau 2.6.28, sur processeur AMD dualcore. Les sources sont disponibles plus bas ; voici les points principaux.

//Typedefs
typedef unsigned char u_int8;
typedef unsigned short u_int16;
typedef unsigned int u_int32;
typedef unsigned long long int u_int64;

/**
 * An IDT entry. Cf Intel SDM 3A
 */
typedef struct {
 u_int16 low_offset;
 u_int16 selector;
 u_int8 unused_lo;
 u_int8 segment_type:4;
 u_int8 system_segment_flag:1;
 u_int8 DPL:2;
 u_int8 P:1;
 u_int16 hi_offset;
} __attribute__((packed)) IDTENTRY_ST, *P_IDTENTRY_ST;

Dans un premier temps, on déclare la structure d’un descripteur d’interruption. On fera particulièrement attention à bien spécifier __attribute__((packed)) pour spécifier au compilateur de ne pas faire de padding entre les champs. La fonction effectuant le hook est ci-après :

//Interrupt handlers
u_int32 old_int_handler, new_int_handler2;

void HookOneIDT (P_IDTENTRY_ST _p_IDT, u_int32 _interrupt_number,
                 u_int32* _old_address, u_int32 _new_address)
{
 asm("cli\n\t");

 *_old_address =  ((_p_IDT[_interrupt_number].hi_offset << 16)
                | (_p_IDT[_interrupt_number].low_offset));
 _p_IDT[_interrupt_number].hi_offset = (_new_address >> 16) & 0xFFFF;
 _p_IDT[_interrupt_number].low_offset = (_new_address & 0xFFFF);

 asm("sti\n\t");
}

Rien de particulier ici, à part une désactivation temporaires des interruptions. D’ailleurs, pour être plus rigoureux, il aurait fallu les désactiver sur tous les cœurs, mais comme cette fonction sera appelée avec interrupt_number = 13, qui n’est de toutes façon pas masquable, il n’y a pas de risque.

Le nouveau handler d’interruption est codé à part dans un fichier assembleur. Il s’agit en fait d’un squelette qui sauvegarde le contexte et appelle une fonction C, pour des raisons de commodité :

.globl interrupt_handler

//The interrupt handler.
//This function must be naked. Since it's not possible with gcc on x86 platforms, we put it in a separate asm file.
interrupt_handler: 

 //Save registers
 pusha
 pushf

 //Call our hook function and  the parameter
 //Since convention call of my_func_handler is fastcall, parameter has to be in %ecx
 mov %esp, %ecx
 call my_func_handler

 //Check the return value
 cmp $1, %eax

 //If 1, throw the exception away
 je  my_exit

 //Otherwise, restore registers
 popf
 popa

 //Jump to the original handler
 jmpl * old_int_handler

my_exit:

 //Restore registers
 popf
 popa

 //Pop interrupt error code
 add $4, %esp

 //Return from interrupt
 iret

La fonction appelée, my_func_handler, doit déterminer la nature de l’exception et la traiter si besoin en détournant RDTSC. On utilise son code de retour pour savoir si l’on repasse la main au handler par défaut de Linux, ou si on se contente de retourner en userland.

//Opcode for RDTSC : 0F 31 => 31 OF in little endian
#define RDTSC_OPCODE 0x310F

//Size of RDTSC instruction
#define RDTSC_SIZE   2

/**
 * Interrupt stack structures
 */
typedef struct
{
 u_int32 edi;
 u_int32 esi;
 u_int32 ebp;
 u_int32 esp;
 u_int32 ebx;
 u_int32 edx;
 u_int32 ecx;
 u_int32 eax;
} PUSHA_ST, *P_PUSHA_ST;

typedef struct
{
 u_int32 error_code;  // !! Check Intel Manuals to see if the error code is present or not
 u_int32 eip;
 u_int32 cs;
 u_int32 eflags;
 u_int32 esp;
 u_int32 sp;
} INT_STACK_HARD_ST, P_INT_STACK_HARD_ST;

typedef struct
{
 u_int32              eflags;

 PUSHA_ST             pusha_st;
 INT_STACK_HARD_ST    int_stack_hard_st;

} MY_INT_STACK_ST, *P_MY_INT_STACK_ST;

/**
 * Return current PID
 */
unsigned int GetCurrentPID (void)
{
 // !!! The 'current' macro doesn't work in interrupt context !
 // !!! We have to use current_thread_info()->task instead
 return current_thread_info()->task->pid;
}

/**
 * Function called by the interrupt handler.
 *  !! WARNING !! Don't call printk() inside, or the kernel will freeze !
 *
 * @param stack pointer to the stack
 * @return 0 if this is a normal #GP exception,
 * 1 if it is due to our RDTSC hook
 */
u_int32  __attribute__((__fastcall__))
         my_func_handler (P_MY_INT_STACK_ST stack)
{
 //nb_interrupts++;+
 asm volatile("lock incl nb_interrupts\n\t");

 //Detect if the instruction that triggered the exception is RDTSC
 if(* (u_int16*) stack->int_stack_hard_st.eip == (u_int16) RDTSC_OPCODE)
 {
 //Check who is executing RDTSC
 if(GetCurrentPID() == pid_to_hook)
 {
 //Change EAX and EDX with magic values
 stack->pusha_st.eax = 0x11223344;
 stack->pusha_st.edx = 0x55667788;
 }
 else
 {
 //Perform a normal call to RDTSC
 RDTSC_ST rdtsc;
 RDTSC(&rdtsc);

 stack->pusha_st.eax = rdtsc.eax;
 stack->pusha_st.edx = rdtsc.edx;
 }

 //Increment EIP
 stack->int_stack_hard_st.eip += RDTSC_SIZE;

 return 1;
 }
 else
 {
 return 0;
 }

}

Il y a plusieurs détails qui ont leur importance. D’une part,on définit des structures correspondant à l’état de la pile lors de l’appel à cette fonction. Cela inclut les registres généraux pushés par PUSHA ainsi que les valeurs pushés automatiquement par le processeur. Il faut faire attention à bien inverser leur ordre relativement aux specifications d’Intel, vu que la pile croît des addresses hautes vers les basses. On récupère l’EIP empilé, on déréférence ce pointeur et on compare le mot de 16 bits avec l’opcode de RDTSC renversé (vu qu’il se trouve en mémoire, donc en little-endian). On émule RDTSC su besoin, et on n’oublie pas d’incrémenter EIP afin de sauter par dessus l’instruction lors du retour. On notera que le debug de cette fonction n’est pas trivial, car il est impossible d’utiliser des fonctions comme printk() à l’intérieur.

Voici désormais la partie relative aux IOCTLs. Je n’ai pas détaillé cette partie précédemment car elle fait plutôt partie d’un choix d’implémentation.

#include <linux/ioctl.h>

//The device name in /proc/devices
#define DEVICE_NAME        "rdtsc_exploit"

//The name of the device file in /dev
#define DEVICE_FILE_NAME   "/dev/rdtsc_exploit"

//IOCTL command codes
#define IOCTL_SET_PID    _IOWR(0, 0, unsigned int)

//Device major and minor numbers
static dev_t g_device_num;

//Count the number of hooked interrupts
extern volatile unsigned int nb_interrupts;

//The file_operation structure, to link the device
//to the appropriate handlers
static struct file_operations g_fops = {
 .owner   = THIS_MODULE,
 .ioctl   = my_ioctl,
};

//Char device structure
static struct cdev g_device;

Sous Linux, pour pouvoir communiquer avec un module en utilisant des IOCTLs, il faut créer un périphérique virtuel en mode caractère (char device) et lui assigner un handler l’ioctl. Ce device possèdera un numéro majeur dynamiquement alloué par le noyau. Pour le numéro mineur, nous choisissons simplement 0. Une fois ces ressources allouées, nous enregistrons le device ce qui a pour effet de le faire apparaître dans /proc/devices. Tout ce procédé est fort bien décrit aux chapitres 3 et 6 de Linux Device Drivers, 3rd edition, livre libre que je vous conseille vivement.

/**
 * Create the device
 */
int create_device (void)
{
 //Allocate the device major and minor
 if(alloc_chrdev_region(&g_device_num, 0, 1, DEVICE_NAME))
 {
 printk(KERN_INFO "ERROR: alloc_chrdev_region FAILED\n");
 return -1;
 }

 //Initialise the device
 cdev_init(&g_device, &g_fops);

 //Fill in some fields (optional)
 g_device.owner = THIS_MODULE;
 g_device.ops = &g_fops;

 //Register the device into the kernel
 if(cdev_add(&g_device, g_device_num, 1))
 {
 printk(KERN_INFO "ERROR: cdev_add FAILED\n");
 return -1;
 }

 printk(KERN_INFO "Device registrated successfully - name = %s, "
                  "major = %d, minor = %d\n", DEVICE_NAME,
                  MAJOR(g_device_num), MINOR(g_device_num));

 return 0;
}

/**
 * Delete the device
 */
void delete_device (void)
{
 //Unregister the device
 cdev_del(&g_device);

 //Unregister the device number
 unregister_chrdev_region(g_device_num, 1);
}

Ces deux fonctions réalisent la création et la suppression du device.

Pour manipuler le flag TSD de CR4, on cree les fonctions suivantes :

//Flag of CR4 that disable RDTSC in userland
#define FLAG_DISABLE_USER_RDTSC 0x4

/**
 * Get CR4 value
 */
u_int32 GetCR4 (void)
{
 u_int32 res = 0;

 asm volatile (
 "push %%eax\t\n"
 "mov %%cr4, %%eax\t\n"
 "mov %%eax, %0\t\n"
 "pop %%eax\t\n"
 : "=m"(res));

 return res;
}

/**
 * Set CR4 value
 */
void SetCR4 (u_int32 _new_cr4)
{
 asm volatile(
 "push %%eax\t\n"
 "mov %0, %%eax\t\n"
 "mov %%eax, %%cr4\t\n"
 "pop %%eax\t\n"
 : : "m" (_new_cr4));
}

/**
 * Enable userland calls to RDTSC
 */
void EnableUserRDTSC (void)
{
 SetCR4(GetCR4() & ~FLAG_DISABLE_USER_RDTSC);
}

/**
 * Disable userland calls to RDTSC
 */
void DisableUserRDTSC (void)
{
 SetCR4(GetCR4() | FLAG_DISABLE_USER_RDTSC);
}

On notera au passage la syntaxe assez inhabituelle de l’assembleur inline de GCC, notemment les doubles % nécessaires puisque l’on utilise des références (%0), ainsi que les \n\t en fin de ligne. Et bien entendu, les arguments inversés par rapport à la syntaxe officielle d’Intel.

Lors du chargement du driver, il suffira de hooker l’IDT et de positionner le flag CR4.TSD. Cependant, cette dernière opération doit être faite sur tous les coeurs. On utilisera donc la macro on_each_cpu().

//Hook the General Protection Fault handler (0x0D)
#define INTERRUPT_VECTOR_TO_HOOK 0x0D

#include <linux/module.h>  /* Needed by all modules */
#include <linux/kernel.h>  /* Needed for KERN_ALERT */
#include <linux/init.h>     // Needed for the macros

#include "../include/defines.h"
#include "hook.h"
#include "device.h"

static int module_load(void)
{
 Hook();
 create_device();

 //Must return 0, otherwise the module is not loaded
 return 0;
}

static void module_unload(void)
{
 delete_device();
 UnHook();
}  

module_init(module_load);
module_exit(module_unload);

/**
 * Hook
 */
void Hook ()
{
 //Get the IDT address (all CPUS use the same)
 P_IDTENTRY_ST pIDT = GetIDTSoft();

 printk(KERN_INFO "interrupt_handler = %08x\n", (u_int32) interrupt_handler);

 //Hook interrupt handler
 HookOneIDT(pIDT, INTERRUPT_VECTOR_TO_HOOK,
            &old_int_handler, (u_int32) interrupt_handler);

 //Hook RDTSC
 on_each_cpu(DisableUserRDTSC, 0, 0);
}

/**
 * Unhook
 */
void UnHook ()
{
 //Unhook RDTSC
 on_each_cpu(EnableUserRDTSC, 0, 0);

 //Unhook interrupt handler
 HookOneIDT(GetIDTSoft(), INTERRUPT_VECTOR_TO_HOOK,
            &new_int_handler2, old_int_handler);
}

Dans mon prototype, je récupère l’adresse de l’IDT en userland dans le Makefile…

IDT_ADDRESS = "0x`grep idt_table /boot/System.map-2.6.28-11-generic
               | cut -d ' ' -f 1`"

… que je passe en paramètre à GCC lors de la compilation avec le flag -D. Le module la récupère comme une constante pré-processeur :

/**
 * Get a pointer to the IDT - the soft way.
 * Works perfectly in VMs, but we either have to hardcode the IDT offset,
 * or read it from userland ('grep idt_table /proc/kallsyms'
 * or 'grep idt_table /boot/System.map').
 */
P_IDTENTRY_ST GetIDTSoft (void)
{
 P_IDTENTRY_ST pIDT = 0;

 pIDT = (P_IDTENTRY_ST) IDT_ADDRESS;

 return pIDT;
}

En userland, il faudra transmettre le PID à hooker au device, ce qui se fait par le code suivant :

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include <fcntl.h>
#include <sys/ioctl.h>

#include "defines.h"

int main(int ac, char **av)
{

 //int i;
 int fd;
 int pid_to_hook;

 if(ac != 2)
 {
 printf("Usage: set_pid pid\n");
 printf("Set the pid to hook.\n\n");
 exit(0);
 }

 pid_to_hook = atoi(av[1]);

 if(pid_to_hook <= 0)
 {
 fprintf(stderr, "Error, pid must be > 0.\n");
 exit(1);
 }

 //Open the device in order to communicate with the driver
 fd = open(DEVICE_FILE_NAME, O_RDONLY);

 if(fd == -1)
 {
 printf("Error: %s does not exist!\n", DEVICE_FILE_NAME);
 exit(1);
 }

 //Send IOCTLs to the driver to set the pid do hook
 if(ioctl(fd, IOCTL_SET_PID, pid_to_hook))
 {
 fprintf(stderr, "Error setting the pid.\n");
 }
 else
 {
 printf("pid set successfully.\n");
 }

 //Close the device
 close(fd);

}

Enfin, la routine de traitement de l’IOCTL qui sert à récupérer le PID dans le module est relativement simple :

/**
 * IOCTL handler
 */
int my_ioctl (struct inode * _inode, struct file * _file,
              unsigned int _ioctl_num, unsigned long _ioctl_param)
{
 struct task_struct *task;

 switch(_ioctl_num)
 {
 //Set the PID
 case (IOCTL_SET_PID):

 pid_to_hook = (unsigned int) _ioctl_param;

 break;

 default:
 printk(KERN_INFO "rdtsc_exploit: ERROR: Unsupported ioctl code: "
                  "%08x.\n", _ioctl_num);
 }
 return 0;
}

Test

Après avoir compilé le tout, on charge le module :

# insmod module/rootkit.ko
# grep rdtsc_exploit /proc/devices
250 rdtsc_exploit
# mknod /dev/rdtsc_exploit c 250 0

On lance le programme exécutant RDTSC dans un shell à part :

$ exe/rdtsc/rdtsc
Press <Enter> to call rdtsc. Press q to quit.

RDTSC result (edx : eax) = (0000126d : 8c1cc9a2)

RDTSC result (edx : eax) = (0000126d : a38e75be)

Puis on envoie son PID au module avec :

# exe/set_pid/set_pid $(pidof rdtsc)
pid set successfully.

Et on revient au terminal précédent, en constatant que le hook fonctionne bien :

RDTSC result (edx : eax) = (55667788 : 11223344)

RDTSC result (edx : eax) = (55667788 : 11223344)

RDTSC result (edx : eax) = (55667788 : 11223344)

On n’oubliera pas de décharger le module avec :

# rmmod rootkit
# rm /dev/rdtsc_exploit

Problème avec ArchLinux

En testant l’implémentation précédente avec deux distributions ArchLinux de noyaux 2.6.29 et 2.6.30, j’ai constaté qu’ell ne marchait tout simplement pas. En faisant plusieurs tests, je constate que le handler de #GP est bien hooké, mais RDTSC ne l’est pas du tout car le programme de test affiche toujours des valeurs normales. J’affiche la valeur de CR4.TSD à plusieurs reprises, et je vois que de temps en temps, il repasse à 0, ce qui expliquerait pourquoi RDTSC n’est pas détournée.

Après plusieurs recherches, je tombe sur ce blog, qui pointe du doigt quelques bizarreries du noyau Linux concernant justement le flag TSD. Apparemment, il serait possible de l’activer ou non pour certains processus seulement. Il s’agit du Thread Information Flag TIF_NOTSC définit dans le fichier arch/x86/include/asm/thread_info.h du noyau. Ce flag est plus ou moins l’équivalent du flag TSD, mais dans le contexte de chaque processus. Il est possible de le définir avec l’appel système prctl en utilisant l’option PR_SET_TSC. La valeur PR_TSC_ENABLE revient à positionner TSD = 0, tandis que PR_TSC_SIGSEGV est équivalent à TSD = 1.

Ces flags existent déjà dans les noyaux 2.6.28 d’Ubuntu 9.04 ; je n’ai pas encore bien saisi pourquoi ceuxi-ci sont effectivement appliqués sur ArchLinux. Le blog cité précédemment parle de l’option de configuration CONFIG_SECCOMP du noyau, présente sur ArchLinux, mais visiblement désactivée ia le flag TIF_SECCOMP qui vaut 0 pour tous les processus. Je vais continuer mes recherches de ce côté… Si toutefois vous avez des explications, je suis preveur .

Implémentation 2

En attendant, il reste tout de même effectuer le hook de RDTSC. Il suffit de positionner le flag TIF_NOTSC du processus en question à PR_TSC_SIGSEGV. Cela peut se faire en appelant prctl, mais cette technique n’est pas vraiment convenable car un hook se doit d’être extérieur au processus. La technique consiste donc à émuler le fonctionnement de cet appel système au sein de notre module. Il nous suffit de parcourir la liste chainée des processus, d’isoler celui qui a le bon PID, et à positionner son flag. Cela revient à modifier la fonction my_ioctl() comme ceci :

/**
 * IOCTL handler
 */
int my_ioctl (struct inode * _inode, struct file * _file,
              unsigned int _ioctl_num, unsigned long _ioctl_param)
{
   struct task_struct *task;

   switch(_ioctl_num)
   {
      //Set the PID
      case (IOCTL_SET_PID):

         pid_to_hook = (unsigned int) _ioctl_param;
         printk(KERN_INFO "rdtsc_exploit: pid_to_hook = "
                          "%d.\n", pid_to_hook);

         for_each_process(task) {
            if(task->pid == pid_to_hook){
               test_and_set_ti_thread_flag(task_thread_info(task), TIF_NOTSC);
               printk("TIF_NOTSC set for process %d\n", task->pid);
            }
         }

      break;

      default:
         printk(KERN_INFO "rdtsc_exploit: ERROR: Unsupported ioctl code: "
                          "%08x.\n", _ioctl_num);
   }
   return 0;
}

La macro for_each_process() définie dans linux/sched.h permet d’itérer très simplement sur les threads du système. On utilise la fonction test_and_set_ti_thread_flag() afin de positionner le flag TIF_NOTSC du thread en question. On notera qu’il n’y a même plus besoin de modifier à la main CR4 à l’initialisation.

Sources

Téléchargez les sources

Les sources incluent l’implémentation 2, sachant que celle-ci fonctionne aussi bien sur les deux distributions que j’ai testées (Ubuntu et ArchLinux). Les lignes spécifiques à la 1ère implémentation sont commentées, donc vous pouvez toujours jouer avec et voir le résultat que vous obtenez.

Pour compiler, invoquez simplement make à la racine de rdtsc_exploit. Si jamais cela ne compile pas, éditez le fichier module/Makefile, et indiquez le bon chemin vers votre fichier /boot/System.map. Vérifiez également que le fichier module/handler.S a bien un S majuscule concernant son extension.

Les fichiers fournis sont organisés comme ceci :

• module/ contient les sources du module
• exe/ contient deux sources d’exécutables :
  • rdtsc : programme de test exécutant RDTSC à chaque appui sur une touche. Il contient aussi un fichier de test du noyau, disable-tsc-test.c, que j’ai jugé intéressant de garder pour des tests. A compiler séparément.
  • set_pid : programme prenant en paramètre le PID de rdtsc et l’envoyant au module par ioctl
• scripts/ contient trois scripts permettant d’automatiser le chargement du module et la création du device. load_hook.sh et unload_hook.sh appellent en réalité load.sh, capable de charger/décharger un module et créer/détruire son device.

Applications

Pour terminer, voici quelques possibilités offertes par le hook de RDTSC :

• Empoisonnement des générateurs de nombres pseudo-aléatoires : Certaines applications utilisent RDTSC comme source d’aléa, pour générer des valeurs pseudo-aléatoires qui peuvent par exemple être utilisées pour la génération de clé de chiffrement. En forçant à RDTSC à renvoyer des valeurs bien précise, on peut injecter des valeurs bien précises dans l’algorithme de génération et pouvoir prédire plus facilement son résultat.
• Anti-anti-debuging : Comme dit au premier paragraphe, une technique d’anti-debug consiste à utiliser RDTSC pour estimer le temps passé entre deux instructions et le comparer à une valeur seuil. Une technique d’anti-anti-debug peut donc être de hooker RDTSC et de retourner des valeurs plausibles à l’application, en masquant le fait que celle-ci est en train de se faire déboguer. C’est précisément ce que fait le plugin Olly Advanced d’OllyDbg.
• Communication offusquée entre une application et un driver : Puisqu’avec cette technique RDTSC est exécutée en ring 3 et provoque une exception #GP en ring 0, c’est un moyen de donner la main à un driver afin qu’il effectue des opérations « ni vu ni connu », dans le sens ou il n’y a aucun appel explicite vers fonction noyau dans l’application ring 3.

Conclusion

Cette technique n’est pas nouvelle, mais encore assez peu connue (enfin sans doute pas des reversers :p). Cependant, elle peut se révéler très intéressantes dans de multiples occasions. Si je devais donner un conseil, ce serait d’éviter de l’utiliser en ring 3, pour deux raisons principales de sécurité :

• Il existe des générateurs aléatoires reconnus comme fiables, il est donc préférable de les utiliser plutôt que de se faire son propre algorithme.
• L’OS fournit généralement des appels systèmes permettant d’appeler RDTSC en ring 0 et de retourner sa valeur (cf NtQueryPerformanceCounter() sous Windows). Comme l’appel est en ring 0, la méthode de hook décrite précédemment ne marche plus.

Références

• The Art of Unpacking, Marc Vincent Yason, BlackHat 2007
• Intel Software Devloper’s Manuals 2B, 3A
• Understanding the Linux kernel, 3rd edition, Daniel Pierre Bovet, Marco Cesati, O’Reilly
• Nibbles – SMP : IDT et GDT, j0rn
• Linux Device Drivers, 3rd edition, Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman, O’Reilly
• CR0′s blog : Time-stamp counter disabling oddities in the Linux kernel
• Man prctl

PR_SET_TSC

Le pourquoi du BSOD

Avant de mettre les mains dans le cambouis, il est intéressant de comprendre pourquoi Windows affiche un écran bleu. Cet écran maléfique est affiché lorsque quelque chose d’assez sérieux s’est produit au niveau du noyau. Cela peut être aussi bien matériel que logiciel (parfois les deux). Par exemple : un driver tente d’accéder à une zone mémoire non existante ou protégée. Si vous essayez de faire cela avec un programme en en mode utilisateur, celui-ci crashera en affichant un message d’erreur Windows (ou une segmentation fault sous Linux). En mode noyau, l’équivalent est le BSOD sous Windows (Kernel Panic sous Linux) et vous n’avez pas d’autre choix que de rebooter votre bécane. Eh oui, on ne plaisante pas avec le kernel. Voici un exemple de driver qui provoquera un écran bleu à coup sûr :

* (unsigned int *) 0 = 0;

Ce code essaye d’écrire 0 à l’adresse mémoire virtuelle 0, qui est invalide. Par conséquent, le processeur déclenchera un défaut de page, ce qui provoque un écran bleu puisque son descripteur est invalide. Il y a plein d’autres manières de provoquer un écran bleu, mais cela dépasse le cadre de cet article.

Reversing de la routine du BSOD

Le code de la routine affichant le BSOD se situe dans le kernel Windows, dans ntoskrnl.exe (ou ntkrnlpa.exe si vous avez la PAE). Après avoir débuggé une machine virtuelle et provoqué un écran bleu volontairement grâce au code donné ci-dessus, je m’aperçois que la VM s’est arrêtée dans la routine KeBugCheckEx. J’ouvre ntoskrnl.exe avec IDA PRO et désassemble cette routine.

public _KeBugCheckEx@20
_KeBugCheckEx@20 proc near

BugCheckCode= dword ptr  8
BugCheckParameter1= dword ptr  0Ch
BugCheckParameter2= dword ptr  10h
BugCheckParameter3= dword ptr  14h
BugCheckParameter4= dword ptr  18h

mov     edi, edi
push    ebp
mov     ebp, esp
push    0
push    [ebp+BugCheckParameter4]
push    [ebp+BugCheckParameter3]
push    [ebp+BugCheckParameter2]
push    [ebp+BugCheckParameter1]
push    [ebp+BugCheckCode]
call    _KeBugCheck2@24 ; KeBugCheck2(x,x,x,x,x,x)
pop     ebp
retn    14h
_KeBugCheckEx@20 endp

Cette fonction est très courte, elle ne fait qu’empiler des paramètres et appeler la routine KeBugCheck2. Cette dernière est par contre très longue. Comme mon but n’est pas de la reverser intégralement mais juste isoler la partie qui m’intéresse, je parcours rapidement son graphe avec IDA. Vu le nom des fonctions appelées, cette routine récupère des informations auprès des drivers sur le crash qui vient d’avoir lieu.

Couleur de fond

A peu près au milieu de la fonction, on tombe sur ce code :

call    _InbvAcquireDisplayOwnership@0 ; InbvAcquireDisplayOwnership()
call    _InbvResetDisplay@0 ; InbvResetDisplay()
push    4
push    1DFh
mov     ebx, 27Fh
push    ebx
push    esi
push    esi
call    _InbvSolidColorFill@20 ; InbvSolidColorFill(x,x,x,x,x)

Apparemment, on a affaire à des appels de fonction gérant l’affichage. On commence par faire un reset de l’affichage, puis on appelle la routine InvbSolidColorFill. Les paramètres qui lui sont passés sont les suivants (je rappelle que l’ordre est inversé, selon la convention d’appel utilisé) :

• deux arguments égaux à 0 (si on cherche un peu plus haut on trouve un xor esi,esi donc esi = 0)
• 0x27F = 639
• 0x1DF = 479
• 4

Etant astucieux, on se rend compte que 639 = 640 – 1 et 479 = 480 – 1. Hors, 640 x 480 correspond exactement à la résolution de l’écran bleu. Avec les deux paramètres 0 qui précèdent, ces valeurs correspondent aux bornes (gauche, haute, droite, et basse) de la zone de l’écran à remplir. La couleur de remplissage est précisée par le dernier paramètre, qui vaut 4. En cherchant un peu sur Google, on se rend compte que le code couleur utilisé par cette fonction est sur 4 bits : IBGR soit Intensity, Blue, Green and Red. 4 en décimal équivaut à 0100 en binaire, soit 1 pour le bleu et 0 pour le reste. Voilà donc pourquoi l’écran bleu est bleu !

Si on désassemble la fonction InvbSolidColorFill, on se rend compte qu’assez rapidement, celle-ci appelle la fonction VidSolidColorFill. Il s’agit d’une fonction importée par ntoskrnl.exe depuis bootvid.dll, le module chargé de la vidéo lors du boot. Son code est relativement peu clair, aussi j’ai préféré jeter un coup d’oeil aux sources de ReactOS, qui est nettement plus lisible. Pour ceux qui ne connaissent pas, il s’agit d’un projet visant à recoder Windows en Open Source. Voici le code de la fonction dans ReactOS (qui doit être très similaire dans Windows) :

VOID NTAPI
VidSolidColorFill(IN ULONG Left, IN ULONG Top,
                  IN ULONG Right, IN ULONG Bottom,
                  IN UCHAR Color)
{
    int y, x;

	for (y = Top; y <= Bottom; y++)
	{

            for (x = Left; x <= Right; x++)
            {
                //
                // Draw the pixel
                //
                VidpSetPixel(x, y, Color);
            }
	}
}

Comme vous pouvez le voir, on peut difficilement faire plus simple. Une fonction chargée de fixer la couleur d’un pixel est appelée dans une double boucle, ce qui a pour effet de remplir l’écran.

Couleur du texte

Revenons au code de KeBugCheck2. Juste après le code qui remplit l’écran, on a ceci :

push    0Fh
call    _InbvSetTextColor@4 ; InbvSetTextColor(x)

Vu le nom de la fonction, on peut se douter que celle-ci fixe la couleur du texte du BSOD. 0xF = 0b1111 = blanc. Que demander de plus ?

Patching à chaud pour changer les couleurs

Que diriez vous de personnaliser la couleur du BSOD sur votre système ? Je n’ai personnellement jamais aimé le bleu, je préfère le rouge (plus sexy pour un message d’erreur !). Quand au texte, du jaune devrait faire l’affaire…

Pour des raisons de sécurité, je vous déconseille fortement d’éditer l’exécutable de votre noyau (ntoskrnl.exe) car une erreur peut être vraiment fatale. Je préfère nettement opérer en mémoire, afin qu’un simple reboot efface les modifications. D’autre part, comme on s’apprête à débugger Windows et à le faire planter, il faut opérer sur une deuxième machine. Munissez vous d’une VM (VirtualBox pour ma part) que vous bootez en mode debug (flag /debug du boot.ini) avec Windbg lancée en parallèle sur votre machine. Pour ceux qui débutent, je vous conseille de lire cet article d’0vercl0ck qui vous expliquera comment tout configurer comme il faut. Prêt ? C’est parti !

Une fois Windows démarré, freezez le avec Ctrl+Pause sous Windbg. Commençons par localiser ou se trouve l’appel à InvbSolidColorFill dans KeBugCheck2. Sous IDA, on effectue un petit calcul d’offset pour savoir ou se trouve le push 4 par rapport au début de KeBugCheck2. Chez moi, j’ai un offset de 0x60D. Dans Windbg, je tape donc u KeBugCheck2+0x60d. Cependant, ça ne tombe pas juste ; j’atterris après ce bout de code (facile de le constater avec IDA). C’est sans doute à cause du fait que j’ai des mises à jours différentes sur ma machine et dans ma VM. Je remonte donc petit à petit et je finir par arriver sur l’instruction qui m’intéresse :

kd> u KeBugCheck2+0x5e4
nt!KeBugCheck2+0x5e4:
8053342e e8da9fffff      call    nt!InbvResetDisplay (8052d40d)
80533433 6a04            push    4
80533435 68df010000      push    1DFh
8053343a bb7f020000      mov     ebx,27Fh
8053343f 53              push    ebx
80533440 56              push    esi
80533441 56              push    esi
80533442 e84aa0ffff      call    nt!InbvSolidColorFill (8052d491)

Il suffit de patcher la valeur située à l’adresse 80533434 pour changer la couleur du BSOD ! Pour ma part, je choisis le rouge, soit 0b0001 = 1. Je tape donc ceci dans Windbg (eb = edit byte) :

kd> eb 80533434 01

Vérifions cela en désassemblant à nouveau :

kd> u KeBugCheck2+0x5e4
nt!KeBugCheck2+0x5e4:
8053342e e8da9fffff      call    nt!InbvResetDisplay (8052d40d)
80533433 6a01            push    1
80533435 68df010000      push    1DFh
8053343a bb7f020000      mov     ebx,27Fh
8053343f 53              push    ebx
80533440 56              push    esi
80533441 56              push    esi
80533442 e84aa0ffff      call    nt!InbvSolidColorFill (8052d491)

Super, ça semble avoir marché. Faisons de même avec la couleur du texte !

kd> u KeBugCheck2+0x5fd
nt!KeBugCheck2+0x5fd:
80533447 6a0f            push    0Fh
80533449 e8d1a0ffff      call    nt!InbvSetTextColor (8052d51f)

Je veux du jaune, je remplace donc le 0x0F par un 0x0B soit 0b1011 (mélange clair de vert et rouge).

kd> eb 80533448 0B
kd> u KeBugCheck2+0x5fd
nt!KeBugCheck2+0x5fd:
80533447 6a0b            push    0Bh
80533449 e8d1a0ffff      call    nt!InbvSetTextColor (8052d51f)

Nikel. Il ne reste plus qu’à provoquer un écran bleu ! Pour ce faire à partir de Windbg, c’est très simple : il suffit de mettre eip à 0. On tape juste r eip = 0 et on débloque la machine avec la commande g. Windows crashe instantanément et Windbg reprend la main. Attendez quelques secondes que les symboles se rechargent, appuyez sur Ctrl+Pause pour arrêter l’opération de diagnostique de crash, et retapez g pour voir apparaître votre beau BSOD personnalisé. En ce qui me concerne, c’est plutôt un RSOD (Red Screen Of Death) !

Red Screen Of Death

C’est ti pas mignon tout ça ? Pour ceux qui par malheur verraient leur écran s’afficher puis disparaître à cause d’un reboot instantané, refaites la manip en n’oubliant pas au préalable de désactiver les reboots sur crash système en faisant un clic droit sur le poste de travail, propriétés, avancé, paramètres de démarrage et récupération, puis décochez la case « redémarrer automatiquement ».

Conclusion

J’espère que cet article vous aura plu et que vous allez dès à présent tuner votre BSOD pour rendre jaloux vos amis. Pour ceux qui voudraient aller plus loin, sachez qu’il est également possible de modifier le texte affiché sur l’écran… Après, vous pouvez intégrer tout ça dans un driver qui se chargera d’effectuer le patching lui-même. C’est ce que fait le programme BSOD Hack (cf en bas). Et si vous en avez le courage, vous pouvez même faire un petit hook inline (detour patching) afin de rediriger un crash vers votre propre routine. J’ai entendu dire que certains avaient réussi à charger et afficher une image de bière lors d’un crash, si ça peut vous donner des idées…

Références

• BSOD Hack

Privilèges des processeurs x86

Avant d’aborder le sujet, il est nécessaire de bien comprendre une subtilité des processeurs x86 : les niveaux de privilèges. Un processeur est censé exécuter du code machine produit par un compilateur / assembleur. Le code qui s’exécute à un instant t a accès à certains privilèges qui dépendent du niveau de privilège dans lequel se trouve le processeur. Ce niveau, aussi appelé ring, ou anneau, est un entier codé sur deux bits. Il peut donc prendre 4 valeurs : 0, 1, 2, et 3. Plus ce nombre est petit, plus les privilèges sont élevés ; plus il est grand, plus ils sont restreints. Le ring 0 est appelé mode superviseur, ou kernelland,et c’est sous ce mode que tournent 99% des noyaux d’OS (Windows et Linux en font partie). Les programmes utilisateurs s’exécutent quant à eux en ring 3, appelé mode utilisateur ou userland.

Le niveau de privilège courant du processeur est appelé CPL (Current Privilege Level). En interne, le CPL est stocké dans les deux premiers bits des registres CS et SS. La règle générale est la suivante : il n’est pas possible d’exécuter des instructions nécessitant un niveau de privilège inférieur au CPL. De même, il n’est pas directement possible de demander au processeur de changer le CPL vers un niveau inférieur. On peut donc se demander : comment est-ce possible d’appeler une routine du noyau depuis un code utilisateur ? C’est là tout l’objet de cet article…

Un programme d’exemple

Afin d’analyser comment se déroule un appel système, nous allons commencer par coder un programme d’exemple en C.

#include <stdio.h>
#include <stdlib.h>
#include <windows.h>

int main(int argc, char *argv[])
{
    HANDLE handle;
    WIN32_FIND_DATA findData;

    handle = FindFirstFile(".", &findData);

    printf("Handle = %dn", handle);

    getchar();

    return 0;
}

Ce programme appelle l’API Windows FindFirstFile. Cette fonction prend en paramètre un nom de dossier et retourne un handle vers le premier fichier de ce dossier. Je suis d’accord : ce programme ne sert pas à grand chose, à part appeler une API Windows, mais c’est justement le but.

Tracing en userland

Pour information, j’ai réalisé tous ces tests sur un Windows XP SP3 français, avec Dev-C++ et GCC 3.4.2. Une fois le programme compilé, on peut utiliser un débogeur pour suivre l’exécution du programme. Lançons OllyDbg et observons le main() du programme :

00401290  /$ 55             PUSH EBP
00401291  |. 89E5           MOV EBP,ESP
00401293  |. 81EC 78010000  SUB ESP,178
00401299  |. 83E4 F0        AND ESP,FFFFFFF0
0040129C  |. B8 00000000    MOV EAX,0
004012A1  |. 83C0 0F        ADD EAX,0F
004012A4  |. 83C0 0F        ADD EAX,0F
004012A7  |. C1E8 04        SHR EAX,4
004012AA  |. C1E0 04        SHL EAX,4
004012AD  |. 8985 A4FEFFFF  MOV DWORD PTR SS:[EBP-15C],EAX
004012B3  |. 8B85 A4FEFFFF  MOV EAX,DWORD PTR SS:[EBP-15C]
004012B9  |. E8 82040000    CALL syscalls.00401740
004012BE  |. E8 1D010000    CALL syscalls.004013E0
004012C3  |. 8D85 A8FEFFFF  LEA EAX,DWORD PTR SS:[EBP-158]           ; |
004012C9  |. 894424 04      MOV DWORD PTR SS:[ESP+4],EAX             ; |
004012CD  |. C70424 0030400>MOV DWORD PTR SS:[ESP],syscalls.00403000 ; |ASCII "fg"
004012D4  |. E8 E7050000    CALL <JMP.&KERNEL32.FindFirstFileA>      ; FindFirstFileA
004012D9  |. 83EC 08        SUB ESP,8
004012DC  |. 8945 F4        MOV DWORD PTR SS:[EBP-C],EAX             ; |
004012DF  |. 8B45 F4        MOV EAX,DWORD PTR SS:[EBP-C]             ; |
004012E2  |. 894424 04      MOV DWORD PTR SS:[ESP+4],EAX             ; |
004012E6  |. C70424 0330400>MOV DWORD PTR SS:[ESP],syscalls.00403003 ; |ASCII "Handle = %d"
004012ED  |. E8 4E050000    CALL <JMP.&msvcrt.printf>                ; printf
004012F2  |. E8 39050000    CALL <JMP.&msvcrt.getchar>               ; [getchar
004012F7  |. B8 00000000    MOV EAX,0
004012FC  |. C9             LEAVE
004012FD  . C3             RETN

Je rappelle que nous sommes à présent dans un programme utilisateur, donc en userland. Il est facile de le vérifier en regardant la valeur de CS. Chez moi, c'est 0x2B, soit 0b101011. Les deux premiers bits (poids faible) sont bien 0b11, correspondant au ring 3.

L'appel à FindFirstFile se trouve en 004012D4, après que les paramètres aient été mis sur la pile. Après avoir placé un breakpoint sur le call (F2), et lancé l'exécution (F9), le programme s'arrête dessus. On fait un step in (F7) pour suivre le call.

004018C0   $-FF25 B8504000  JMP DWORD PTR DS:[<&KERNEL32.FindFirstFileA>]

Nous nous situons à présent dans une zone appelée trampoline. Cette zone fait référence à l’IAT (Import Address Table) de l’exécutable, qui contient les adresses des fonctions importées. Pour faire le parallèle avec Linux, le trampoline est l’équivalent de la section .plt, et l’IAT joue le même rôle que la section .got. Pour plus d’informations sur ces sections je vous conseille de lire cet article.

Le jump fait référence à un pointeur situé en 004050B8, qui contient l’adresse de la fonction FindFirstFileA. On rappuie sur F7 pour suivre l’appel. On arrive alors dans la section .text de kernel32.dll, qui a été chargée à l’exécution.

7C813869 > 8BFF             MOV EDI,EDI
7C81386B   55               PUSH EBP
7C81386C   8BEC             MOV EBP,ESP
7C81386E   81EC 6C020000    SUB ESP,26C
...
7C813894   56               PUSH ESI
7C813895   56               PUSH ESI
7C813896   56               PUSH ESI
7C813897   8D8D ACFDFFFF    LEA ECX,DWORD PTR SS:[EBP-254]
7C81389D   51               PUSH ECX
7C81389E   56               PUSH ESI
7C81389F   FF70 04          PUSH DWORD PTR DS:[EAX+4]
7C8138A2   E8 66B2FFFF      CALL kernel32.FindFirstFileExW

On s’aperçoit que cette fonction en appelle une autre, FindFirstFileExW, toujours dans kernel32. Pourquoi ? Simplement parce que la plupart des fonctions internes de Windows utilisent un encodage Unicode, et non pas ASCII. Dans la convention Windows, les fonctions se terminant par un A gèrent l’ASCII, et celles en W gèrent l’Unicode. En interne, les fonctions ASCII convertissent les paramètres passés en Unicode, et appèlent les fonctions Unicode correspondantes. C’est le call que nous venons de voir. Suivons le.

7C80EB0D > 8BFF             MOV EDI,EDI
7C80EB0F   55               PUSH EBP
7C80EB10   8BEC             MOV EBP,ESP
7C80EB12   81EC CC020000    SUB ESP,2CC
...
7C80EC66   57               PUSH EDI
7C80EC67   8D85 90FDFFFF    LEA EAX,DWORD PTR SS:[EBP-270]
7C80EC6D   89B5 40FDFFFF    MOV DWORD PTR SS:[EBP-2C0],ESI
7C80EC73   8B35 1410807C    MOV ESI,DWORD PTR DS:[<&ntdll.NtOpenFile>] ; ZwOpenFile
7C80EC79   50               PUSH EAX
7C80EC7A   C785 34FDFFFF 18>MOV DWORD PTR SS:[EBP-2CC],18
7C80EC84   FFD6             CALL ESI
...
7C80ED46   FFB5 90FDFFFF    PUSH DWORD PTR SS:[EBP-270]
7C80ED4C   FF15 2812807C    CALL DWORD PTR DS:[<&ntdll.NtQueryDirectoryFile>]

On voit que cette fonction réalise plusieurs appels (ici je n’en n’ai affiché que 2 mais il y en a d’autres) dans ntdll.dll, une autre DLL chargée. Continuons notre traçing en explorant l’appel à ZwOpenFile.

7C91D580 > B8 74000000      MOV EAX,74
7C91D585   BA 0003FE7F      MOV EDX,7FFE0300
7C91D58A   FF12             CALL DWORD PTR DS:[EDX]  ; ntdll.KiFastSystemCall
7C91D58C   C2 1800          RETN 18

Transition vers le mode noyau

Nous sommes à présent dans ntdll.dll, dans la fonction ZwOpenFile exportée par la dll. Comme vous le voyez, la fonction est très courte. La première instruction place 0×74 dans EAX, qui correspond au numéro de la fonction du noyau qui va être appelée. On a ensuite un appel à une fonction nommée KiFastSystemCall. C’est elle qui va réaliser le passage en mode noyau, à l’aide des instructions suivantes :

7C91E4F0 > 8BD4             MOV EDX,ESP
7C91E4F2   0F34             SYSENTER
7C91E4F4 > C3               RETN

C’est précisément SYSENTER qui réalise la transition. Mais que fait donc cette instruction ? On ouvre le manuel Intel 2B au chapitre 4.1, instruction SYSENTER. On y apprend que cette instructionpermet d’exécuter des appels systèmes. Historiquement, les appels systèmes étaient exécutés en utilisant les interruptions logicielles, avec l’instruction INT 2E sous Windows (et INT 80 sous Linux). SYENTER étant plus rapide, elle a succédé à l’ancienne méthode, qui reste toutefois disponible pour des raisons de compatibilité.

Contrairement aux interruptions, SYSENTER n’utilise pas de table de pointeurs, mais des registres spéciaux du processeur, appelés MSR (pour Model Specific Register). Ces registres sont assez particuliers ; ils possèdent un numéro et sont accessibles en lecture et écriture via les instructions rdmsr et wrmsr. SYSENTER en utilise 3 :

• IA32_SYSENTER_CS (0×174) correspond à la valeur à charger dans CS quand SYSENTER sera appelé
• IA32_SYSENTER_ESP (0×175) sera quant à lui chargé dans ESP
• IA32_SYSENTER_EIP (0×176) sera chargé dans EIP

Ainsi, ces trois registres définissent tout ce qu’il faut pour exécuter un bout de code en mode en mode noyau, puisque CS (et donc ses deux premiers bits, encodant le CPL) sera changé.

Ces registres ne sont pas lisibles en mode utilisateur ; il faut impérativement être en ring 0 pour les lire. Pour cela, utilisons Windbg, le débogueur noyau de Microsoft. Il se télécharge ici, vous trouverez également des informations pour la configuration des symboles sur cette page.

Lançons Windbg en local kernel debugging (Cltrl K puis local). Dans l’invite de commande, tapons :

lkd> rdmsr 174
msr[174] = 00000000`00000008
lkd> rdmsr 176
msr[176] = 00000000`80541520

Nous voyons donc que IA32_SYSENTER_CS = 0×8 (donc avec un niveau de privilège à 0) et IA32_SYSENTER_EIP = 80541520. Au passage, on notera que cette adresse est supérieur à 80000000, c’est à dire en mode noyau, puisque Windows divise l’espace d’adressage de tout processus en 2 : 2 Go pour l’utilisateur (de 00000000 à 7FFFFFFF) et 2 Go pour le noyau (de 80000000 à FFFFFFFF). Regardons ce qui se trouve en 80541520 :

lkd> u 80541520 80541520+100     //desassemble les 100 premiers octets
nt!KiFastCallEntry:
80541520 b923000000      mov     ecx,23h
80541525 6a30            push    30h
80541527 0fa1            pop     fs
80541529 8ed9            mov     ds,cx
8054152b 8ec1            mov     es,cx
...
80541600 8b3f            mov     edi,dword ptr [edi]
80541602 8b1c87          mov     ebx,dword ptr [edi+eax*4]
80541605 2be1            sub     esp,ecx
80541607 c1e902          shr     ecx,2
8054160a 8bfc            mov     edi,esp
8054160c 3b3534215680    cmp     esi,dword ptr [nt!MmUserProbeAddress (80562134)]
80541612 0f83a8010000    jae     nt!KiSystemCallExit2+0x9f (805417c0)
80541618 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
8054161a ffd3            call    ebx

On voit que la fonction s’appelle KiFastCallEntry et se trouve dans le module nt qui correspond à ntoskrnl.exe, un des exécutables du noyau.

Après plusieurs vérifications de paramètres, la fonction KiFastCallEntry charge une table dans EDI (après les « … »). Il s’agit de la SSDT (Service System Dispatch Table), une table très importante du noyau qui a un rôle similaire à la table d’interruptions (IDT). Elle sert à dispatcher les appels systèmes vers la bonne fonction. Le symbole correspondant à la SSDT se nomme KiServiceTable, et est exporté par le noyau. Voici le début de son contenu :

lkd> dds KiServiceTable
80504450  805a4614 nt!NtAcceptConnectPort
80504454  805f0adc nt!NtAccessCheck
80504458  805f4312 nt!NtAccessCheckAndAuditAlarm
8050445c  805f0b0e nt!NtAccessCheckByType
80504460  805f434c nt!NtAccessCheckByTypeAndAuditAlarm

Souvenez-vous : juste avant le SYSENTER, on a placé le numéro d’appel système dans EAX. Ce registre va être utilisé ici afin de servir d’index dans cette table et de trouver le pointeur de la fonction à appeler. L’instruction suivante multiplie justement EAX par 4 (la taille d’une entrée dans la table) et l’ajoute à l’adresse de début de la table contenu dans EDI. Le résultat est place dans EBX. Et quelques instructions plus loin, on trouve… un call EBX

Faisons le calcul nous même : nous connaissons le numéro d’appel système (0×74) :

lkd> dds KiServiceTable+0x74*4
80504620  8057a182 nt!NtOpenFile

Bingo, voila la fonction NtOpenFile : c’est elle qui sera exécutée lors du call EBX.

Retour en userland

Notre reversing peut s’arrêter ici. Nous n’allons pas désassembler cette fonction car ce n’est pas le but de l’article. Concernant le retour de l’appel système, on peut, en désassemblant la suite de KiFastCallEntry , voir que la fonction KiServiceExit va être appelée. A son tour, elle appelle une des deux fonctions KiSystemCallExit ou KiSystemCallExit2. La première revient en mode utilisateur en utilisant l’instruction IRET, et l’autre le fait en utilisant SYSEXIT (c’est celle là qui sera appelée dans notre cas). Cette instruction rebascule en userland et restaure EIP. On se retrouve alors dans ZwOpenFile, de ntdll.

Conclusion

Au travers de cet article, nous avons tracé l’exécution d’un programme utilisateur afin de comprendre comment il passe en mode noyau afin d’exécuter des instructions privilégiées.  Nous avons vu comment fonctionne l’instruction SYSENTER et le rôle de la SSDT.

On peut alors imaginer plusieurs hooks possibles exploitant ce schéma de fonctionnement. Au niveau utilisateur, on peut hooker l’entrée de l’IAT correspondant à la fonction à appeler. En mode noyau, il y a plusieurs possibilités. La première serait de remplacer l’adresse de la fonction à appeler dans la SSDT par une autre fonction qui appelle l’originale et effectue un filtrage en entrée et en sortie. Une autre serait de modifier carrément le registre IA32_SYSENTER_EIP en le faisant pointer sur une autre routine de traitement. L’équivalent pour les vieilles versions de Windows utilisant les interruptions serait de modifier le registre IDTR contenant l’adresse de la table des interruptions, ou bien de hooker l’entrée 2E dans cette table. Enfin, une dernière solution, radicale mais fonctionnelle, serait de faire un hook inline de la fonction pointée, en remplaçant ses premiers octets par un call d’une autre fonction. Comme vous le voyez, les possibilités de hook sont innombrables, les plus « profondes » étant bien souvent les plus indétectables…

Références

• Ivanlef0u’s Blog – SSDT Hooking Reinvented
• Ivanlef0u’s Blog – SYSENTER, stepping into da ring0
• Rootkits – Subverting the Windows Kernel, Greg Hoglund et Jamie Butler
  
• Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 2B, Chapitre 4.1, Instruction SYSENTER
• Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, Chapitre 4.5
• Debugging Tools for Windows
• Debugging Tools and Symbols: Getting Started

Au programme : plongeon dans les bas fonds de l’architecture x86 d’Intel, et plus précisément toutes les fonctionnalités de protection, dont certaines sont parfois méconnues (ou pas). Ce n’est pas sans me rappeler certaines parties de mes cours de système suivis à l’INSA et au RIT, mais avec une forte dose de concret en plus…

Cette fois-ci, une grosse partie du code s’exécutera en mode noyau (ring 0), ce qui va me faire goûter aux joies de la programmation de drivers et des Blue Screen Of Death de Windows. D’ailleurs au niveau de l’OS, je travaille principalement Windows pour le moment, mais dans l’idéal, le projet devrait aussi être porté sous Linux.

De plus, qui dit sécurité des données et confidentialité dit… cryptographie ! Le module que je vais développer devra intégrer des primitives de base permettant d’encrypter les données sensibles et de les décrypter au moment voulu.

Enfin, ce stage va être l’occasion pour moi de redécouvrir les techniques utilisées par les rootkits, principalement le hooking et la furtivité. Autant dire que je me sens comme un poisson dans l’eau…

Bien entendu, ayant signé une charte de confidentialité, je ne pourrais pas divulguer tout ce que je fais dans les moindres détails, mais je compte bien publier ici quelques articles concernant des sujets ou projets du domaine public que mon stage m’aura fait découvrir.

Rappels théoriques

Tout d’abord, il convient de faire quelques rappels sur la compilation et l’édition de liens des binaires. Quand on compile un programme qui fait appel à des fonctions situées dans d’autres bibliothèques (telles que la librairie standard), l’édition de liens peut être faite de deux façons différentes. La première méthode, dite statique, consiste à intégrer à l’exécutable toutes les librairies dont il a besoin pour fonctionner. A l’exécution, tous les symboles sont donc résolus, et les appels sont immédiats. Si cette méthode a été la plus utilisée dans les versions anciennes des OS, elle est toutefois largement dépassée. En effet, il s’agit d’un gouffre à espace disque, puisqu’elle oblige à dupliquer chaque librairie autant de fois qu’il y a d’exécutables qui l’utilisent. Les exécutables générés sont donc volumineux, puisqu’il suffit par exemple d’un simple appel à printf() pour que toute la librairie standard du C soit intégrée à l’exécutable !

Depuis les versions « récentes » de Linux, c’est la deuxième méthode d’édition de liens, dite dynamique, qui est utilisée par défaut. Avec cette méthode, chaque librairie est compilée une fois pour toute dans une librairie dynamique, ou partagée (shared) ayant l’extension .so (équivalent des .dll sous Windows). Lorsque l’on compile un programme qui y fait référence, on y insère juste le nom du symbole (fonction ou variable) dont il a besoin, ainsi que le nom de la librairie. C’est à l’exécution du programme que l’éditeur de liens dynamique (ou dynamic linker), nommé ld.so, charge les libraires nécessaire et effectue la résolution des symboles manquants en temps réel. C’est donc la vitesse d’exécution qui s’en retrouve pénalisée, même si nous verrons que cette perte est toutefois relative car compensée par un système de mise en cache des adresses.

Enfin, il convient de clarifier la notion de PIC, ou Position Independant Code. Un code exécutable est dit PIC s’il peut être mappé à l’importe quelle région mémoire tout en pouvant s’exécuter convenablement. Dans de tels exécutables, aucune adresse absolue ne doit apparaître, puisque si l’exécutable se retrouve translaté en mémoire, les adresses absolues ne seront plus valides. Dans Linux, les librairies dynamiques sont en PIC. C’est le linker dynamique, ld.so, qui les charge en mémoire à l’exécution, et leur place en mémoire peut varier d’une exécution à une autre. Ainsi, l’adresse des fonctions de la libraire standard, telles que printf(), changent de place à chaque exécution. Pourtant, un programme qui utilise printf() n’est compilé qu’une seule fois. Comment les processus arrivent-ils donc à s’exécuter tout en prenant en compte cette variation d’adresses ? C’est là tout l’objectif de cet article…

Un programme de test

Place à la pratique ! Dans la suite, je considérerais que nous somme sur une Ubuntu Hardy (noyau 2.6.24), avec gcc 4.2.3 et gdb 6.8. Nous allons utiliser le programme en C suivant :

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(){
  char c1[] = "chaine1";
  char c2[] = "chaine2";

  int res = strcmp(c1, c2);

  printf("c1 == c2 ? %dn", res);

  return 0;
}

Pour illustrer ce que nous venons de voir, compilons-le avec les deux méthodes, statique et dynamique :

$ gcc -o bin_str bin_str.c
$ gcc -static -o bin_str_static bin_str.c

Notez au passage que gcc linke les exécutable dynamiquement par défaut, et que l’option -static permet de forcer l’édition de liens statique. A l’exécution, les deux produisent exactement le même résultat :

$ ./bin_str
c1 == c2 ? -1
$ ./bin_str_static
c1 == c2 ? -1

Cependant, quand on compare la taille des exécutables…

$ ls -lh bin_str bin_str_static
-rwxrwxrwx 1 root root 6,6K 2008-07-21 19:12 bin_str
-rwxrwxrwx 1 root root 545K 2008-07-21 19:12 bin_str_static

On constate que le binaire lié statiquement (545K) est 80 fois plus volumineux que le binaire lié dynamiquement (qui ne pèse que 6.6K) ! En effet, c’est toute la librairie standard qui a été incorporée au binaire durant l’édition de liens.

Lançons-les avec gdb et désassemblons le main de chacun :

$ gdb ./bin_str_static
(gdb) disas main
Dump of assembler code for function main:
...
0x0804823b <main+75>:   call   0x804dd70 <strcmp>
...
0x08048251 <main+97>:   call   0x8048c70 <printf>
...
(gdb) quit

$ gdb ./bin_str
(gdb) disas main
Dump of assembler code for function main:
...
0x0804844f <main+75>:   call   0x8048364 <strcmp@plt>
...
0x08048465 <main+97>:   call   0x8048344 <printf@plt>
...

On constate que dans le binaire lié statiquement, printf() et strcmp() ont bien été intégrées dans la région .text de l’exécutable. Dans le binaire lié dynamiquement, les deux appels n’ont cependant pas lieu dans la .text, mais dans une région spécifique à l’édition de lien dynamique : la .plt. La PLT, pour Procedure Linkage Table, est une table sertvant à faire le lien avec les fonctions situées dans des bibliothèques dynamiques.

La PLT et la GOT

Dans la suite, on ne travaillera évidemment qu’avec le binaire lié dynamiquement. Listons les régions actuellement mapées dans l’espace mémoire de l’exécutable:

(gdb) info files
...
0x080482e4 - 0x08048314 is .init
0x08048314 - 0x08048374 is .plt
0x08048380 - 0x0804852c is .text
0x0804852c - 0x08048548 is .fini
0x08048548 - 0x0804856f is .rodata
0x08048570 - 0x08048574 is .eh_frame
0x08049574 - 0x0804957c is .ctors
0x0804957c - 0x08049584 is .dtors
0x08049584 - 0x08049588 is .jcr
0x08049588 - 0x08049658 is .dynamic
0x08049658 - 0x0804965c is .got
0x0804965c - 0x0804967c is .got.plt
0x0804967c - 0x08049688 is .data
0x08049688 - 0x0804968c is .bss

La région .plt est donc mappée entre les adresses 0×08048314 et 0×08048374. Il est important de noter que cette section se trouve à des adresses fixes. On vérifie au passage que les adresses appelées par les deux calls du main (0×8048364  pour strcmp et 0×8048344 pour printf) appartiennent bien à cette zone. Désassemblons à présent la région .plt :

(gdb) disas 0x08048314 0x08048374
Dump of assembler code from 0x8048314 to 0x8048374:
0x08048314 <_init+48>:  pushl  0x8049660
0x0804831a <_init+54>:  jmp    *0x8049664
0x08048320 <_init+60>:  add    %al,(%eax)
0x08048322 <_init+62>:  add    %al,(%eax)
0x08048324 <__gmon_start__@plt+0>:      jmp    *0x8049668
0x0804832a <__gmon_start__@plt+6>:      push   $0x0
0x0804832f <__gmon_start__@plt+11>:     jmp    0x8048314 <_init+48>
0x08048334 <__libc_start_main@plt+0>:   jmp    *0x804966c
0x0804833a <__libc_start_main@plt+6>:   push   $0x8
0x0804833f <__libc_start_main@plt+11>:  jmp    0x8048314 <_init+48>
0x08048344 <printf@plt+0>:      jmp    *0x8049670
0x0804834a <printf@plt+6>:      push   $0x10
0x0804834f <printf@plt+11>:     jmp    0x8048314 <_init+48>
0x08048354 <__stack_chk_fail@plt+0>:    jmp    *0x8049674
0x0804835a <__stack_chk_fail@plt+6>:    push   $0x18
0x0804835f <__stack_chk_fail@plt+11>:   jmp    0x8048314 <_init+48>
0x08048364 <strcmp@plt+0>:      jmp    *0x8049678
0x0804836a <strcmp@plt+6>:      push   $0x20
0x0804836f <strcmp@plt+11>:     jmp    0x8048314 <_init+48>
End of assembler dump.

Globalement, on constate que la section .plt est composée de plusieurs sous-sections de taille égale (0×10 soit 16 octets), que nous appellerons entrées. L’entrée 0 (composée des 4 premières instructions) est un peu spéciale ; nous y reviendrons plus tard. Les autres entrées, à compter de la 1 jusqu’à la dernière, sont composées de 3 instructions qui suivent toujours le même schéma. Un premier jmp a lieu, dont l’adresse de saut n’est pas explicitement donnée dans l’instruction, mais par l’intermédiaire d’un pointeur. Par exemple, dans le cas de l’entrée 3 correspondant à printf, l’adresse de saut se trouve dans les 4 octets pointés par l’adresse 0×8049670 qui fait donc office de pointeur. On remarque que la 2ème instruction de l’entrée 0 comporte aussi un jmp avec pointeur. En regardant de plus près chaque pointeur, y compris celui de l’entrée 0 (0×8049664), on s’aperçoit qu’ils se trouvent tous les uns à la suite des autres. En effet, on a ici : 0×8049664, 0×8049668, 0x804966c, 0×8049670, 0×8049674, et 0×8049678. Pour savoir où se trouvent ces pointeurs, il suffit de regarder à nouveau la liste des sections mappées en mémoire :

(gdb) info files
...
0x0804957c - 0x08049584 is .dtors
0x08049584 - 0x08049588 is .jcr
0x08049588 - 0x08049658 is .dynamic
0x08049658 - 0x0804965c is .got  <=====
0x0804965c - 0x0804967c is .got.plt

Ces adresses se situent donc dans la section nommée .got.plt. Les régions nommées ici .got et .got.plt font en réalité partie d’une table, que l’on nomme la GOT, pour Global Offset Table. Le rôle de cette table sera explicité dans la suite.

Affichons maintenant son contenu. Étant donné que cette région contient des pointeurs, il s’agit de données et non d’instructions ; pour afficher son contenu il convient donc d’utiliser l’instruction x de gdb, et non pas disas. De plus, la commande précédente nous indique que la section fait 0×20 = 32 octets de long, soit 8 pointeurs de 4 octets.

(gdb) x/8x 0x0804965c
0x804965c <_GLOBAL_OFFSET_TABLE_>:      0x08049588      0x00000000
                                        0x00000000      0x0804832a
0x804966c <_GLOBAL_OFFSET_TABLE_+16>:   0x0804833a      0x0804834a
                                        0x0804835a      0x0804836a

Je rappelle que pour le moment, le programme n’a pas encore été lancé. Le contenu de cette section est fixe, du moins avant chaque exécution. Il est tout à fait possible de le voir en utilisant d’autres outils tels que objdump.

Comme nous venons de le voir, les entrées de la PLT référencent des pointeurs situés dans la GOT. Pour comprendre le rôle de ces deux tables, regardons comment se déroule un appel à strcmp(). Cette fonction est située dans l’entrée 3 de la PLT :

0x08048364 <strcmp@plt+0>:      jmp    *0x8049678
0x0804836a <strcmp@plt+6>:      push   $0x20
0x0804836f <strcmp@plt+11>:     jmp    0x8048314 <_init+48>

Le 1er jmp référence un pointeur (0×8049678) situé dans la GOT. Voyons ce qu’il contient :

(gdb) x 0x8049678
0x8049678 <_GLOBAL_OFFSET_TABLE_+28>:   0x0804836a

Sa valeur veut 0x0804834a, qui correspond… à une adresse de la PLT, et plus précisément à l’adresse de l’instruction juste après le jmp. En d’autres termes, lorsque strcmp() sera appelée, on saute dans la PLT, et on exécute le 1er jmp, qui se contente de sauter sur l’instruction suivante. Cela peut paraître inutile à première vue, mais nous verrons l’astuce qui se cache derrière plus tard. Continuons le fil de l’exécution : après ce 1er jmp, on rencontre un push, qui empile une certaine valeur, ici 0×20. Enfin, on rencontre un jmp, et en examinant l’adresse de saut on s’aperçoit qu’il nous emmène sur l’entrée 0 de la PLT.

Une fois sur l’entrée 0, on rencontre deux instructions (les deux suivantes ne sont pas vraiment des instructions, mais correspondent aux opcodes 0×0000) :

0x08048314 <_init+48>:  pushl  0x8049660
0x0804831a <_init+54>:  jmp    *0x8049664

On commence par empiler une valeur, qui se révèle être l’entrée 1 de la GOT. On effectue ensuite un jmp sur le contenu d’un pointeur, se situant lui aussi dans la GOT mais à l’entrée 2. Pour le moment, ce pointeur ne contient que des zéros, vu que l’exécution n’a pas encore commencée. Plaçons un breakpoint sur l’appel à strcmp(), et examinons la valeur du pointeur.

(gdb) b *0x0804844f         //Correspond au call   0x8048364 <strcmp@plt>
Breakpoint 1 at 0x804844f

(gdb) r
Starting program: /media/echange/Hacking/Reversing_Linux/plt_got/bin_str

Breakpoint 1, 0x0804844f in main ()
Current language:  auto; currently asm

(gdb) x 0x8049664
0x8049664 <_GLOBAL_OFFSET_TABLE_+8>:    0xb7f12c40

On constate qu’une fois le programme lancé, la valeur du pointeur a été modifiée. C’est la procédure de lancement de l’exécutable qui a en fait initialisé cette valeur. Où pointe-t-elle ?

(gdb) info files
...
0x08049658 - 0x0804965c is .got
0x0804965c - 0x0804967c is .got.plt
0x0804967c - 0x08049688 is .data
0x08049688 - 0x0804968c is .bss
0xb7f000f4 - 0xb7f001b4 is .hash in /lib/ld-linux.so.2
0xb7f001b4 - 0xb7f00298 is .gnu.hash in /lib/ld-linux.so.2
0xb7f00298 - 0xb7f00468 is .dynsym in /lib/ld-linux.so.2
0xb7f00468 - 0xb7f005fc is .dynstr in /lib/ld-linux.so.2
0xb7f005fc - 0xb7f00636 is .gnu.version in /lib/ld-linux.so.2
0xb7f00638 - 0xb7f00700 is .gnu.version_d in /lib/ld-linux.so.2
0xb7f00700 - 0xb7f00760 is .rel.dyn in /lib/ld-linux.so.2
0xb7f00760 - 0xb7f00788 is .rel.plt in /lib/ld-linux.so.2
0xb7f00788 - 0xb7f007e8 is .plt in /lib/ld-linux.so.2
0xb7f007f0 - 0xb7f157af is .text in /lib/ld-linux.so.2  <=====
0xb7f157b0 - 0xb7f158e1 is __libc_freeres_fn in /lib/ld-linux.so.2
0xb7f15900 - 0xb7f19320 is .rodata in /lib/ld-linux.so.2
0xb7f19320 - 0xb7f1941c is .eh_frame_hdr in /lib/ld-linux.so.2
0xb7f1941c - 0xb7f19850 is .eh_frame in /lib/ld-linux.so.2
0xb7f1acc0 - 0xb7f1af28 is .data.rel.ro in /lib/ld-linux.so.2
0xb7f1af28 - 0xb7f1afe0 is .dynamic in /lib/ld-linux.so.2
0xb7f1afe0 - 0xb7f1afe8 is .got in /lib/ld-linux.so.2
0xb7f1aff4 - 0xb7f1b014 is .got.plt in /lib/ld-linux.so.2
0xb7f1b020 - 0xb7f1b5b0 is .data in /lib/ld-linux.so.2
0xb7f1b5b0 - 0xb7f1b5b4 is __libc_subfreeres in /lib/ld-linux.so.2
0xb7f1b5b4 - 0xb7f1b668 is .bss in /lib/ld-linux.so.2
0xb7d9c174 - 0xb7d9c194 is .note.ABI-tag in /lib/tls/i686/cmov/libc.so.6
0xb7d9c194 - 0xb7d9fcbc is .gnu.hash in /lib/tls/i686/cmov/libc.so.6
0xb7d9fcbc - 0xb7da8a8c is .dynsym in /lib/tls/i686/cmov/libc.so.6
0xb7da8a8c - 0xb7dae274 is .dynstr in /lib/tls/i686/cmov/libc.so.6
...

La région contenant cette adresse d’est rien d’autre que la .text du linker dynamique, ld.so ! On se trouve dans la fonction du linker permettant d’appeler la véritable fonction strcmp().

La résolution des symboles

Mais comment le linker sait-il qu’il faut appeler strcmp() et pas une autre fonction ? Tout simplement grâce au push 0×20 précédent : 0×20 correspond en fait à un offset correspondant ici à strcmp(). Les instructions de la PLT l’ont empilé afin de le passer en paramètre à la fonction du linker.

Désassemblons cette fonction :

(gdb) disas 0xb7ff6c40 0xb7ff6c40+28
//Le +28 a été trouvé en tatonnant jusqu'à trouver un ret
Dump of assembler code from 0xb7f12c40 to 0xb7f12c5c:
0xb7f12c40:     push   %eax
0xb7f12c41:     push   %ecx
0xb7f12c42:     push   %edx
0xb7f12c43:     mov    0x10(%esp),%edx
0xb7f12c47:     mov    0xc(%esp),%eax
0xb7f12c4b:     call   0xb7f0d350
0xb7f12c50:     pop    %edx
0xb7f12c51:     mov    (%esp),%ecx
0xb7f12c54:     mov    %eax,(%esp)
0xb7f12c57:     mov    0x4(%esp),%eax
0xb7f12c5b:     ret    $0xc
End of assembler dump.

Cette fonction est relativement courte ; elle ne fait en réalité qu’appeler la véritable fonction de résolution des adresses. Lorsqu’elle est appelée, le sommet de pile contient une adresse (correspondant à GOT[1], qui a été pushée à l’entrée 0 de la PLT), et juste en dessous se trouve l’index de strcmp, soit 0×20. Vérifions en plaçant un breakpoint au début et en examinant la pile :

(gdb) b *0xb7f12c40
Breakpoint 2 at 0xb7f12c40

(gdb) c
Continuing.

Breakpoint 2, 0xb7f12c40 in ?? () from /lib/ld-linux.so.2

(gdb) x/2x $esp
0xbfbf50b4:     0xb7f1b668      0x00000020

Vérifions que le 1er pointeur correspond bien à l’entrée 1 de la GOT :

(gdb) x 0x8049660
0x8049660 <_GLOBAL_OFFSET_TABLE_+4>:    0xb7f1b668

Bingo ! On a bien en sommet de pile l’adresse contenue dans GOT[1] et juste en dessous l’index de strcmp(), 0×20.

Revenons au code de cette fonction.

(gdb) disas 0xb7f12c40 0xb7f12c40+28
Dump of assembler code from 0xb7f12c40 to 0xb7f12c5c:
0xb7f12c40:     push   %eax
0xb7f12c41:     push   %ecx
0xb7f12c42:     push   %edx
0xb7f12c43:     mov    0x10(%esp),%edx
0xb7f12c47:     mov    0xc(%esp),%eax
0xb7f12c4b:     call   0xb7f0d350
0xb7f12c50:     pop    %edx
0xb7f12c51:     mov    (%esp),%ecx
0xb7f12c54:     mov    %eax,(%esp)
0xb7f12c57:     mov    0x4(%esp),%eax
0xb7f12c5b:     ret    $0xc
End of assembler dump.

Elle commence par 3 push, permettant de sauvegarder des registres. Ainsi, nos deux valeurs en sommet de pile vont être décalées de 3*4 = 12 octets. Juste après ces 3 push, on a deux mov. Le premier place dans %edx une valeur située sur la pile à l’offset 0×10 soit 16 = 4 * 4 octets. Il s’agit donc de l’index de strcmp(), 0×20. Le second place dans %eax la valeur suivante, soit celle de GOT[1]. Puis un appel de fonction a lieu.

On arrive alors dans une fonction relativement complexe, qui se situe toujours dans la section .text de ld.so. C’est elle qui est chargée d’effectuer la résolution des symbolesen recherchant dans les librairies. Si vous essayez de la désassembler, vous constaterez qu’elle est relativement longue et complexe. Comme ici le but n’est pas d’être exhaustif, je ne la détaillerai pas. En plus, je n’ai pas encore eu le courage de la reverser dans sesmoindres détails…

Continuons donc. Plaçons un breakpoint juste après le call de cette fonction, en 0xb7f12c50.

(gdb) b *0xb7f12c50
Breakpoint 3 at 0xb7f12c50

(gdb) c
Continuing.

Breakpoint 3, 0xb7f12c50 in ?? () from /lib/ld-linux.so.2

Les instructions suivantes manipulent des registres. Dans le cadre de cet article, seules deux instructions sont intressantes :

0xb7f12c54:     mov    %eax,(%esp)
et
0xb7f12c5b:     ret    $0xc

Le mov place la valeur de %eax en sommet de pile, tandis que le ret ordonne au CPU de continuer l’exécution du code à l’adresse située sur le sommet de pile. Autrement dit, juste après le call de la fonction de résolution des symboles, on saute sur l’adresse contenue dans %eax ! Regardons ce que vaut ce registre…

(gdb) info registers
eax            0xb7e0dd20       -1210000096
ecx            0x0      0
edx            0x8049678        134518392
ebx            0xb7ee6ff4       -1209110540
esp            0xbfbf50a8       0xbfbf50a8
ebp            0xbfbf50f8       0xbfbf50f8
esi            0xb7f1ace0       -1208898336
edi            0x0      0
eip            0xb7f12c50       0xb7f12c50
...

Que peut bien représenter l’adresse 0xb7e0dd20 ?

(gdb) info files
...
0xb7d9c174 - 0xb7d9c194 is .note.ABI-tag in /lib/tls/i686/cmov/libc.so.6
0xb7d9c194 - 0xb7d9fcbc is .gnu.hash in /lib/tls/i686/cmov/libc.so.6
0xb7d9fcbc - 0xb7da8a8c is .dynsym in /lib/tls/i686/cmov/libc.so.6
0xb7da8a8c - 0xb7dae274 is .dynstr in /lib/tls/i686/cmov/libc.so.6
0xb7dae274 - 0xb7daf42e is .gnu.version in /lib/tls/i686/cmov/libc.so.6
0xb7daf430 - 0xb7daf730 is .gnu.version_d in /lib/tls/i686/cmov/libc.so.6
0xb7daf730 - 0xb7daf770 is .gnu.version_r in /lib/tls/i686/cmov/libc.so.6
0xb7daf770 - 0xb7db2140 is .rel.dyn in /lib/tls/i686/cmov/libc.so.6
0xb7db2140 - 0xb7db2188 is .rel.plt in /lib/tls/i686/cmov/libc.so.6
0xb7db2188 - 0xb7db2228 is .plt in /lib/tls/i686/cmov/libc.so.6
0xb7db2230 - 0xb7eb2d84 is .text in /lib/tls/i686/cmov/libc.so.6  <=====
0xb7eb2d90 - 0xb7eb3de8 is __libc_freeres_fn in /lib/tls/i686/cmov/libc.so.6
0xb7eb3df0 - 0xb7eb4082 is __libc_thread_freeres_fn in /lib/tls/i686/cmov/libc.so.6
0xb7eb40a0 - 0xb7ecf090 is .rodata in /lib/tls/i686/cmov/libc.so.6
0xb7ecf090 - 0xb7ecf0a3 is .interp in /lib/tls/i686/cmov/libc.so.6
0xb7ecf0a4 - 0xb7ed1c90 is .eh_frame_hdr in /lib/tls/i686/cmov/libc.so.6
0xb7ed1c90 - 0xb7ee1544 is .eh_frame in /lib/tls/i686/cmov/libc.so.6
0xb7ee1544 - 0xb7ee19b0 is .gcc_except_table in /lib/tls/i686/cmov/libc.so.6
0xb7ee19b0 - 0xb7ee4d28 is .hash in /lib/tls/i686/cmov/libc.so.6
0xb7ee51ec - 0xb7ee51f4 is .tdata in /lib/tls/i686/cmov/libc.so.6
...

Tiens, elle se trouve dans la .text… Par hasard, ce ne serait pas l’adresse de strcmp ?

(gdb) p strcmp
$1 = {<text variable, no debug info>} 0xb7e0dd20 <strcmp>

Eh si ! Autrement dit, la fonction de résolution des symboles a résolu correctement strcmp et a placé son adresse dans %eax.

Et la GOT dans tout ça ?

Nous venons de voir le cheminement (d’un point de vue assez haut niveau) d’un appel de fonction situé dans une bibliothèque partagée. Comme on a pu le constater, chaque appel de fonction entraîne à priori une résolution de symbole, ce qui paraît fastidieux. Fort heureusement, par défaut, ld.so ne résoud pas un symbole à chaque fois qu’on tente d’y accéder, mais uniquement la 1ère fois. Par exemple, si vous avez 10 appels à strcmp() dans un programme, le 1er appel entraînera une résolution, et l’adresse de strcmp() sera gardée en mémoire pour les 9 appels suivant. C’est ce que l’on appelle l’évaluation fainéante : on ne fait que le minimum d’opération, et juste à temps.

Où et comment les adresses des symboles sont-elles gardées en mémoire une fois résolues ? Réponse : dans la GOT ! Pour le comprendre, relançons le programme et plaçons un breakpoint dans l’entrée de la PLT correspondant à strcmp.

$ gdb ./bin_str

(gdb) disas 0x08048314 0x08048374   //Les adresses de la PLT, qui restent fixes
Dump of assembler code from 0x8048314 to 0x8048374:
0x08048314 <_init+48>:  pushl  0x8049660
0x0804831a <_init+54>:  jmp    *0x8049664
0x08048320 <_init+60>:  add    %al,(%eax)
0x08048322 <_init+62>:  add    %al,(%eax)
0x08048324 <__gmon_start__@plt+0>:      jmp    *0x8049668
0x0804832a <__gmon_start__@plt+6>:      push   $0x0
0x0804832f <__gmon_start__@plt+11>:     jmp    0x8048314 <_init+48>
0x08048334 <__libc_start_main@plt+0>:   jmp    *0x804966c
0x0804833a <__libc_start_main@plt+6>:   push   $0x8
0x0804833f <__libc_start_main@plt+11>:  jmp    0x8048314 <_init+48>
0x08048344 <printf@plt+0>:      jmp    *0x8049670
0x0804834a <printf@plt+6>:      push   $0x10
0x0804834f <printf@plt+11>:     jmp    0x8048314 <_init+48>
0x08048354 <__stack_chk_fail@plt+0>:    jmp    *0x8049674
0x0804835a <__stack_chk_fail@plt+6>:    push   $0x18
0x0804835f <__stack_chk_fail@plt+11>:   jmp    0x8048314 <_init+48>
0x08048364 <strcmp@plt+0>:      jmp    *0x8049678
0x0804836a <strcmp@plt+6>:      push   $0x20
0x0804836f <strcmp@plt+11>:     jmp    0x8048314 <_init+48>
End of assembler dump.

(gdb) b *0x08048364
Breakpoint 1 at 0x8048364

(gdb) r
Starting program: /media/echange/Hacking/Reversing_Linux/plt_got/bin_str

Breakpoint 1, 0x08048364 in strcmp@plt ()
Current language:  auto; currently asm

(gdb) x 0x8049678
0x8049678 <_GLOBAL_OFFSET_TABLE_+28>:   0x0804836a

L’entrée correspondante de la GOT contient toujours l’adresse de l’instruction suivante dans la PLT. Quel intérêt ? A ce moment, il faut noter que le symbole strcmp n’est pas encore résolu, donc il est normal que cette entrée ne comporte aucune valeur intéressante. Plaçons un watchpoint sur cette entrée de la GOT afin de voir si elle change au fil du temps.

(gdb) watch *0x8049678
Hardware watchpoint 2: *134518392

(gdb) c
Continuing.
Hardware watchpoint 2: *134518392

Old value = 134513514
New value = -1209639648
0xb7f6545d in ?? () from /lib/ld-linux.so.2

Apparamment, la valeur de l’entrée a changé ! Observons sa nouvelle valeur :

(gdb) x 0x8049678
0x8049678 <_GLOBAL_OFFSET_TABLE_+28>:   0xb7e65d20

(gdb) p strcmp
$1 = {<text variable, no debug info>} 0xb7e65d20 <strcmp>

Ainsi on s’aperçoit qu’elle correspond désormais à l’adresse de strcmp(). Désormais, si le programme souhaîte faire d’autres appels à strcmp(), il n’aura plus à effectuer la résolution de symbole puisque le jmp situé dans l’entrée de la PLT référence directement l’adresse de strcmp() !

Quand cette valeur a-t-elle été écrite ? Pour cela, il suffit de regarder %eip et de voir dans quelle zone nous sommes.

(gdb) info registers
eax            0xb7e65d20       -1209639648
ecx            0x0      0
edx            0x8049678        134518392
ebx            0xb7f72ff4       -1208537100
esp            0xbfae4f58       0xbfae4f58
ebp            0xbfae4f90       0xbfae4f90
esi            0xb7f56858       -1208653736
edi            0xb7f73668       -1208535448
eip            0xb7f6545d       0xb7f6545d
eflags         0x246    [ PF ZF IF ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51

(gdb) disas $eip-3 $eip+20
Dump of assembler code from 0xb7f6545a to 0xb7f65471:
0xb7f6545a:     mov    %eax,(%edx,%ecx,1)
0xb7f6545d:     lea    -0xc(%ebp),%esp
0xb7f65460:     pop    %ebx
0xb7f65461:     pop    %esi
0xb7f65462:     pop    %edi
0xb7f65463:     pop    %ebp
0xb7f65464:     ret
0xb7f65465:     xor    %edx,%edx
0xb7f65467:     jmp    0xb7f653de
0xb7f6546c:     lea    -0x2477(%ebx),%eax
...

En cherchant un peu, on remarque qu’on se trouve juste à la fin de la fonction de résolution des symboles. L’instruction responsable de l’écriture de l’adresse dans la GOT est le mov %eax,(%edx,%ecx,1). En inspectant les registres, on voit que cela correspond bien à l’opération *0×8049678 = 0xb7e65d20 (l’adresse de strcmp).

On notera que cette méthode est comparable aux systèmes de caches des processeurs : l’objectif est d’accelérer les accès futurs aux fonctions en accédant une fois pour toute à une donnée et en la plaçant dans une zone d’accès plus rapide. Pour information, il est tout à fait possible de désactiver ce système de mise en cache en utilisant des variables d’environnement reconnues par ld.so. Par exemple, la variable d’environnement LD_BIND_NOT, si elle est définie, permet ainsi de désactiver complétement l’écriture des adresses dans la GOT, tandis que la variable LD_BIND_NOW indique à ld.so d’effectuer toutes les résolutions dès le début, donc de remplir la GOT dès le lancement de l’exécutable. Pour plus de renseignements, consultez le man de ld.so.

Récapitulatif

Le schéma suivant retrace le fil de l’exécution lors d’un appel à strcmp(), et récapitule les différents liens entre la PLT et la GOT.

1er appel de strcmp : symbole non encore résolu

main:
...
call   0x8048364 <strcmp@plt> ----+
mov    %eax,-0x1c(%ebp)           |
...                               |
                                  |
                                  |
0x8048364 (Entrée de la PLT) : <--+
jmp    *0x8049678  -----------------------> 0x8049678 (Entrée de la GOT) :
push   $0x20  <------------------------------ 0x0804836a
jmp    0x8048314 <_init+48> --------+
                                    |
                                    |
0x8048314 (Entrée 0 de la PLT) : <--+
pushl  0x8049660
jmp    *0x8049664  -----------------------> 0x8049664 (Header de la GOT) :
                                              0xb7f12c40 --+
                                                           |
                                                           |
0xb7f12c40 (.text de ld.so, résolution + appel) : <--------+
push   %eax              // Sauvegarde de registres
push   %ecx
push   %edx
mov    0x10(%esp),%edx   // Récupération du code de la fonction strcmp (0x20)
mov    0xc(%esp),%eax
call   0xb7f4c350  -------> Appel de la fonction de résolution des symboles
                            L'adresse du symbole (strcmp) est placé dans %eax.
                            L'entrée de la .got est patchée avec cette adresse.
... <---------------------- Retour de la fonction
mov    %eax,(%esp)       // L'adresse de strcmp (0xb7e65d20) est empilée
...
ret    $0xc ------------------------------+ // On saute sur strcmp
                                          |
                                          |
0xb7e65d20 (strcmp, .text de la libc): <--+
...
ret                      // Retour au main

2ème appel de strcmp : symbole déjà résolu

main:
...
call   0x8048364 <strcmp@plt>  ---+
mov    %eax,-0x1c(%ebp)           |
...                               |
                                  |
                                  |
0x8048364 (Entrée de la .plt) : <-+
jmp    *0x8049678  ----------------> 0x8049678 (Entrée de la GOT) :
                                       0xb7e65d20 --+ // Symbole résolu !
push   $0x20                                        | // Les instructions
jmp    0x8048314 <_init+48>                         | // suivantes ne sont pas
                                                    | // exécutées.
                                                    |
0xb7e65d20 (strcmp, .text de la libc): <------------+
...
ret                      // Retour au main

Références

Comme le précise l’introduction, je n’avais pas Internet quand j’ai réalisé cet article ; je ne peux donc pas citer de page Web. Je me suis beaucoup aidé de la documentation off-line des programmes que j’avais sous la main, à savoir :

• Le man de ld.so (man ld.so)
• L’aide de gdb (commande help de gdb)