No description
Find a file
2021-05-10 14:22:36 +02:00
AnalyseStat Added python script for statistical analysis 2021-02-21 11:36:39 +01:00
attaque_brop Attaque blind ROP 2021-04-27 18:40:37 +02:00
Interpreteur interpreteur 2021-05-10 14:22:36 +02:00
lib Ajout de tests de performance pour les deux versions du patch rondoudou 2021-04-07 20:05:46 +02:00
patch2 Ajout de tests de performance pour les deux versions du patch rondoudou 2021-04-07 20:05:46 +02:00
.gitignore Suppression de l'exécutable et ajout d'un makefile 2021-03-13 11:23:02 +01:00
attaque.c Première attaque en connaissant l'adresse d'une fonction + détection des segfault serveur par le client 2021-03-13 11:13:47 +01:00
client.c Première attaque en connaissant l'adresse d'une fonction + détection des segfault serveur par le client 2021-03-13 11:13:47 +01:00
endCodeAddr Added script for offsets 2021-02-12 15:33:51 +01:00
endStackAddr Added script for offsets 2021-02-12 15:33:51 +01:00
Makefile Première attaque en connaissant l'adresse d'une fonction + détection des segfault serveur par le client 2021-03-13 11:13:47 +01:00
notesRuntimeASLR.md Added notes RuntimeASLR 2021-02-24 16:34:05 +01:00
output.csv Added script for offsets 2021-02-12 15:33:51 +01:00
outputASLR.csv Added python script for statistical analysis 2021-02-21 11:36:39 +01:00
outputWithoutASLR.csv Added python script for statistical analysis 2021-02-21 11:36:39 +01:00
pid Added script for offsets 2021-02-12 15:33:51 +01:00
ReadMe.md Mettre à jour 'ReadMe.md' 2021-02-28 19:07:02 +01:00
serveur.c Première attaque en connaissant l'adresse d'une fonction + détection des segfault serveur par le client 2021-03-13 11:13:47 +01:00
serveur_data.txt Added script for offsets 2021-02-12 15:33:51 +01:00
startCodeAddr Added script for offsets 2021-02-12 15:33:51 +01:00
startLibcAddr Added script for offsets 2021-02-12 15:33:51 +01:00
startStackAddr Added script for offsets 2021-02-12 15:33:51 +01:00
stats.sh Added script for offsets 2021-02-12 15:33:51 +01:00

Projet d'Initiation à la Recherche (PIR) | 4A-IR-SI | INSA Toulouse

Membres :

  • Léonie Gallois
  • Elies Tali
  • Yohan Simard
  • Paul Faure
  • Nahom Belay
  • Jean-Rémy Hok

Tuteurs :

  • Didier Le Botlan
  • Eric Alata

Compilation

WARNING : TO USE THE MAKEFILE YOU MAY NEED "gcc-multilib" (sudo apt-get install gcc-multilib)

Commandes make

Ces commandes compileront les trois exécutables client, serveur et attaque.

Note : le programme attaque est toujours compilé en 64 bits avec canary, car il n'y a pas d'utilité à le compiler autrement.

64bit, avec canary

make 64b

64bit, sans canary

make 64b_nocanary

32bit, avec canary

make 32b

32bit, sans canary

make 32b_nocanary

Principe général

- Le serveur : Gere un entier (init 0) En écoute sur un port passé en paramètre, des qu'une connexion arrive, il fork, traite la connexion dans le fils, le père se remet en attente
- Gestion de la connexion : Attends une chaine de caractère du client, et, en fonction de son contenu effectue les actions adéquates
- Chaine attendues : 
		* ADD/SUB/MUL/DIV      : Le serveur additionne, soustrait, multiplie, divise la valeur actuelle par l'argument passé
		* RESET								 : Le serveur remet l'entier a 0
		* GET 								 : Le serveur envoi la valeur de l'entier
		* PRINT                : Le serveur affiche la valeur de l'entier

- Le client : Demande a l'utilisateur de saisir une chaine, puis, affiche la réponse du serveur (si elle a lieu d'être)

- Failles : 
		* Le serveur copie la chaine reçue avec le read mal fait -> risque de buffer Overflow
		* Le serveur fork, l'attaquant peut accumuler de la connaissance

Étapes de dévelopement

- Step 1 : FAIT
		* Le serveur  : Gere le nombre de connexions, à chaque connexions, il l'affiche juste.
		* Le client   : Se connecte et ferme la connexion aussitôt.
		* Utilité     : Test de l'établissement des connexions. 
		* Retour test : OK.
- Step 2 : FAIT
		* Le serveur  : Gere le nombre de connexions, à chaque connexions, dans le fils, il appelle une fonction d'affichage.
		* La fonction : Reçoit la nombre de connexion, l'affiche, ainsi que son adresse mémoire.
		* Le client   : Se connecte et ferme la connexion aussitôt.
		* Utilité     : Verification que les adresses ne changent pas dans la pile d'un fork à l'autre. 
		* Retour test : Adresses identiques a chaque connexions.
- Step 3 : FAIT
		* Le serveur  : Gere l'entier, à chaque connexions, dans le fils, on appelle une fonction de lecture de la requette (read avec BOF possible) puis traite la requete.
		* La fonction : Lit la chaine et renvoi une structure correspondant a l'action a faire.
		* Le client   : Se connecte, demande a l'utilisateur de saisir la chaine, affiche la réponse, et ferme la connexion.
		* Utilité     : Test du serveur dans son fonctionnement normal. Test BOF possible
		* Retour test : Serveur OK, BOF OK (detecté par le canary).
- Step 4 : TESTER LES PREMIERES EXPLOITATIONS

Statistical Analysis

We wanted to verify how random ASLR was so we executed our server multiple times and retried the positions of the stack, lib and code using “/proc/$pid/map”. We examined two scenarios the first one using ASLR and the second without ASLR (for reference sake).

We focused on three different values: the address of the stack (first row), the offset between the stack and the code portion (second row) and the offset between stack and lib (last row). The first column corresponds to ASLR and the second without ASLR. (Had trouble adding labels to the plot and didnt get around to doing it, sorry).

To have a better picture of the unique addresses and a clearer representation, we only factored in how often each value was present. Then we looked at how many times those occurrences occurred.

The X-axis we have the occurence and in the Y-axis how many times that occurrence occurred.