Retrouvez cet article dans : Misc 21

Nous verrons dans cet article les limites courantes qui peuvent être rencontrées dans le filtrage au niveau applicatif (proxy, IPS) ou la détection d'intrusion (IDS).

Introduction

L'ouverture des systèmes d'informations impose une attention sans cesse accrue. L'objectif est simple : les flux doivent être filtrés et les attaques détectées. Mais comme le champ d'intervention est vaste, la tâche est complexe. Comme tout doit maintenant passer au peigne fin, le niveau applicatif devient le lieu d'inspection incontournable. Une fois le canal de transmission établi, c'est ce niveau qui assure le transit des données ou des fonctions réelles. Aujourd'hui, c'est aussi lui qui abrite la grande majorité des attaques. Et demander à un système de détection ou de prévention d'intrusion de comprendre chaque protocole applicatif qu'il rencontre n'est pas aisé. Même les proxies filtrants, spécialisés dans un nombre très limité de protocoles, souffrent de la définition des normes qui laissent souvent soit des possibilités d'extensions, soit différentes interprétations possibles. Pire encore, les personnes ou entreprises implémentant les normes prennent parfois le parti de ne pas les suivre complètement (consciemment ou non).
Dans ce contexte, il est inévitable que la détection d'intrusion et le filtrage au niveau applicatif ne peuvent être qu'approximatifs. Nous allons donc voir quelques-unes de leurs faiblesses et techniques d'évasions.

1/2 + 1/2 = 2

Dans la préhistoire des IDS, la méthode la plus répandue pour détecter les attaques dans les IDS était ce qui est appelé le packet grepping : il s'agit uniquement de rechercher une chaîne de caractères spécifique dans un paquet intercepté sur le réseau. Le problème rapidement soulevé est qu'une communication unitaire n'est pas forcément envoyée d'un bloc, mais peut être séparée en plusieurs parties. Pour qualifier une communication de dangereuse, il convient donc de ne pas s'arrêter à l'étude de chaque segment séparé mais bel et bien de les rassembler afin d'inspecter la communication dans son ensemble.

Fragmentation IP

En temps normal, une taille maximale de transfert (MTU) est donnée pour chaque interface réseau. Si un paquet à envoyer sur le réseau dépasse cette limite, celui-ci sera fragmenté en autant de paquets que nécessaires. Entre un expéditeur et un destinataire, un paquet peu très bien être fragmenté de multiples fois (au niveau de chaque routeur intermédiaire).
La publication " Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection " [IED] a dévoilé comment tirer parti de cette fonction afin de passer inaperçu auprès des systèmes de détection d'intrusion.
Au niveau IP, deux attaques principales y sont présentées :

• Jouer sur l'ordre des paquets : d'habitude, les paquets arrivent dans l'ordre correct. Un mauvais IDS qui ne traiterait que le cas général pourra alors être abusé. D'autre part, certains modules de réassemblage de fragments s'arrêtent dès que le dernier fragment est arrivé. Il est alors facile de les tromper en commençant par envoyer le dernier fragment puis tous les autres ;
• Envoyer plusieurs fois des fragments qui ont la même position mais pas forcément les mêmes données. En règle générale, les systèmes d'exploitation favorisent les derniers fragments envoyés, mais pas tous (par exemple, Solaris). Comme un IDS est rarement configuré pour prendre en compte les particularités de chaque système surveillé, c'est le genre d'astuce qui permet de passer inaperçu à tous les coups !

Fragroute [FRAG] est un outil bien utile qui permet de tester ces attaques. Nous en reparlerons un peu plus loin.

Segmentation TCP

Tout comme au niveau IP, l'IDS et l'IPS ont besoin de suivre l'envoi des segments TCP. Une difficulté supplémentaire est qu'à ce niveau, l'échange est bien plus compliqué : le numéro de séquence, la taille de fenêtre offerte (émetteur rapide, récepteur lent), la retransmission, etc. doivent entrer en paramètre.
La retransmission est un point relativement épineux : il n'est pas rare que les IDS doivent inspecter des flux de données importants. Dans ce contexte, il arrive qu'ils ratent quelques paquets. Alors qu'un système cible n'aurait qu'à demander une retransmission, l'IDS doit composer avec cette perte et faire des hypothèses sur la suite des échanges qu'il reçoit (en particulier pour le suivi des numéros de séquences).

Jamais deux sans trois

Les 2 paragraphes précédents exposent des failles potentielles qui ne touchent pas le niveau applicatif mais uniquement le niveau réseau. Au niveau applicatif, le problème persiste. Nombreux sont les protocoles qui proposent de fragmenter l'envoi d'une requête ou de données.

Un cas très simple est Telnet où les caractères peuvent être transmis un à un (caractères d'effacement compris). De ce fait, il est nécessaire pour l'IDS de comprendre les commandes passées et pas uniquement les éléments du flot de données un à un.
Un protocole complexe est difficile à inspecter. C'est le cas de RPC. Autant les implémentations Unix que Windows ont montré leur aptitude à regorger de failles. Cet état de fait souligne à quel point il est important de décoder correctement ce type de protocoles. RPC [RPC] propose de fragmenter la demande d'exécution de procédure distante. Le protocole est difficile à analyser, car il inclut différents modes (connectés ou non) et la fragmentation ne suit pas les mêmes règles dans un cas ou dans un autre. Par exemple, dans le mode connecté, l'envoi des fragments est supposé ordonné, mais pas dans le mode non connecté. Même si une taille limite de segment est fixée, certaines phases de l'échange peuvent permettre l'envoi de segments plus importants, etc.

Quelques solutions

Bien évidemment, la plupart des concepteurs d'IDS et IPS ne sont pas restés les bras croisés devant ces menaces et ont implémenté des pré-processeurs qui permettent de déchiffrer les différents protocoles et de ré-assembler les fragments avant de les analyser. Pour prendre le cas de Snort, différents modules sont proposés :

• frag2 ré-ordonne les fragments IP, vérifie la taille des données présentes dans chaque fragment puis les ré-assemble ;
• stream4 suit l'état des connexions TCP et ré-assemble les différents segments d'une même communication;
• Plusieurs pré-processeurs d'inspection de protocoles, comme http_inspect_server, rpc_decode ou encore telnet_decode réalisent le même type de tâches au niveau applicatif.

Malgré tout, tout n'est pas parfait. Ici, les limitations sont multiples. Tout d'abord, ces pré-processeurs sont plutôt gourmands en ressources. Pour limiter cet effet, un timeout est souvent imposé pour chaque niveau d'analyse. Dans le cas de Snort cité précédemment, le défaut est de 60 secondes pour frag2, de 30 secondes pour stream4 et de 60 secondes pour le décodeur HTTP. Là où fragroute, dont nous parlions au premier paragraphe, prend tout son intérêt est dans l'exploitation de ce timeout. Si l'attaquant connaît le type d'IDS, il suffira souvent d'ajouter deux ou trois secondes au timeout par défaut. Dans le cas des IPS, il est même possible de rechercher la valeur du timeout en constatant, pour une attaque donnée et un délai qui varie entre chaque fragment envoyé, le seuil à partir duquel une réponse est obtenue.
Un second souci avec les pré-processeurs est la taille des données qui est conservée pour chaque communication. En effet, comme ces données résident en mémoire vive, il est prudent d'en limiter la taille pour garder des performances raisonnables. Tout ce qui dépasse cette limite de taille n'est alors pas pris en compte par l'IDS...
D'autre part, l'action des pré-processeurs est en général limitée aux ports connus ou spécifiés pour un protocole donné. Par exemple, un module d'inspection HTTP n'aura tendance à être appliqué que sur le port 80. Mais combien d'interfaces web de configuration ou d'administration tournant sur un autre port (appliances diverses, imprimantes, bornes WiFi, switches, baies de stockage, Compaq HTTP, Sun Local Patch Server, Ntop, etc.) se trouvent sur votre réseau ? Rares seront les administrateurs d'un IDS à penser à tous les inclure !
Un autre inconvénient qui mérite d'être mentionné est la complexité apportée par chaque pré-processeur. En effet, chaque nouveau module permettant d'analyser un nouveau protocole risque de contenir des vulnérabilités. Quelques exemples de telles vulnérabilités ont déjà été reportés, par exemple dans le décodeur RPC de Snort [SNORT-VULN]. Il suffit toutefois de voir le nombre de bugs et de failles trouvés dans les modules d'analyse de protocole d’Ethereal [ETHE] pour se dire que le potentiel de vulnérabilités au niveau des IDS et IPS est loin d'être épuisé.

Une question de présentation

Une fois les différents segments ré-assemblés, l'IDS doit les comprendre. Les modules d'analyse des protocoles sont également là pour normaliser la représentation des données.

Encodage

Une des astuces les plus utilisées, en particulier pour HTTP, est de jouer sur l'encodage de caractères. Par exemple, une URL contenant "MISC" en format ASCII s'écrira "%4D%49%53%43" une fois encodée en hexadécimal. Dans du HTML, les encodages peuvent être encore plus insidieux. Par exemple, "MISC" pourra s'écrire sous les formats "MISC" en hexadécimal, "&#77&#73&#83&#67" en codage décimal et "TUlTQw==" en Base64 (qui sera ensuite facilement décodé en 2 lignes de JavaScript). De même, une adresse IP 10.1.2.3 pourra être présentée sous la forme Dword 167838211, en hexadécimal 0x0a.0x01.0x02.0x03, ou même en octal 0012.0001.0002.0003 (ces formats peuvent ne pas être interprétés en fonction du navigateur web et de sa version – par exemple, certaines versions récentes d’Internet Explorer ne reconnaissent plus le format Dword pourtant standard).
Si on prend un cas assez simple d'un proxy web filtrant qui tente de prémunir les utilisateurs de cross-site scripting, de nombreuses formes d'évasion pourront être utilisées en se basant sur l'encodage. Le site ha.ckers.org [XSS] nous en donne de nombreux exemples. En voici quelques-uns dans le tableau 1, ci-contre.

Polymorphisme

Bon nombre de signatures d'IDS permettant la détection de shellcodes se basent sur la recherche d'instructions NOP (0x90). Le problème de cette approche est que, d'une part, elle génère beaucoup de faux positifs et, d'autre part, elle peut être contournée. En effet, des outils comme ADMutate [ADM] ou LibExploit [LIBEXPLOIT] permettent de remplacer les instructions 0x90 des shellcodes par d'autres instructions équivalentes. Le module Fnord a amené un niveau d'analyse plus approfondi dans Snort puisqu'il repose sur une recherche de variantes aux instructions NOP et SYS. Le nombre de variantes et l'évolution des outils permettant de détecter les shellcodes ne permet toutefois pas d'avoir une détection fiable. D'autre part, des outils comme LibExploit proposent de chiffrer le shellcode. Dans ce cas, une routine est ajoutée avant le shellcode pour le déchiffrer. Un IDS ou IPS peut très bien inclure dans ses règles de détection les routines les plus souvent rencontrées (en général, de simples XOR), mais il est très simple de les modifier et chaque routine incluse dans l'IDS ou l'IPS apporte un coup de calcul non négligeable. Pour passer inaperçu d'une détection statistique, un bourrage de données inutiles faussant le calcul est parfois ajouté au shellcode initial. Il semble donc illusoire d'espérer une détection fiable de shellcode. Dans le cas de proxy filtrant, ModSecurity [MODSEC] propose une détection et un blocage de buffer overflow, mais la détection suit les mêmes principes qu'exposé précédemment et les techniques d'évasion seront alors similaires.

D'autres problèmes de représentation

L'évasion de détection d'intrusion ou de filtrage en jouant sur la représentation de données est un vaste sujet. Nous avons déjà parlé des deux méthodes les plus courantes. Bien d'autres existent :

• La représentation en format big endian ou low endian des octets stockés en mémoire – les IDS ne font pas forcément la différence entre les deux représentations et ne prennent pas en compte l'architecture du processeur de la cible. Certains exploits visant des serveurs sous Solaris ne sont parfois pas détectés pour ces raisons ;
• Les fins de lignes représentées tantôt par \r\n tantôt par \n suivant que l'on se trouve sous Windows ou sous Unix ;
• La représentation des répertoires avec des \ ou des /. Cette technique d'évasion a été introduite par RFP avec Whisker [WHISKER] pour exploiter des failles IIS, mais elle peut également fonctionner pour passer outre certaines règles de détection de failles de serveurs FTP tournant sous Windows ;
• La représentation relative des répertoires avec des /../  ;
• Lorsque le protocole le permet, il est possible de jouer sur les espaces, les tabulations, les fins de lignes au milieu d'une requête, etc. Pour les protocoles qui ne disposent pas d'un module d'inspection spécifique, cette technique peut toujours fonctionner, même si cela tend à être de moins en moins vrai.

Camouflage

Lorsqu'une règle est créée pour qu'un IDS détecte une attaque ou qu'un IPS ou un proxy filtrant la stoppe, il est difficile d'imaginer toutes les variantes qui pourraient mener cette règle à être contournée. Imaginons une règle simplissime au niveau d'un IDS qui émet une alerte lorsque l'IDS constate que la commande su root a été passée. Est-ce que la personne écrivant l'IDS va penser aux contournements su `ls / | grep roo` ou su rq^Hoazert^H^H^H^H^Hot ou encore à une commande plus tordue comme :
echo -n s > /tmp/toto; echo -n "u " >> /tmp/toto; echo -n r >> /tmp/toto; echo -n o >> /tmp/toto;  echo -n o >> /tmp/toto;  echo -n t >> /tmp/toto; /tmp/toto

HTTP Request Smuggling

L'attaque HTTP Request Smuggling [SMUGGLING] a été dévoilée il y a peu par Watchfire et consiste à envoyer dans une même connexion différentes requêtes HTTP mal formées et jouer sur l'interprétation différente qu'en feront différents équipements et en particulier entre celle du serveur web visé et celle d'un proxy, d'un IDS ou d'un IPS. L'attaque repose beaucoup sur des multiples définitions de Content-Length. Nous allons détailler l'exemple donné par Watchfire qui explique comment contourner le filtrage applicatif web appliqué par Checkpoint FW1 et le module web Intelligence. Tout d'abord, voici l'ensemble de requêtes envoyées :

1     POST /page.asp HTTP/1.1
2     Host: chaim
3     Connection: Keep-Alive
4     Content-Length: 49223
5     [CRLF]
6     zzz...zzz      ["z" x 49152]
7     POST /page.asp HTTP/1.0
8     Connection: Keep-Alive
9     Content-Length: 30
10    [CRLF]
11    POST /page.asp HTTP/1.0
12    Bla:           [espace après "Bla:", mais pas de saut de ligne]
13    POST /page.asp?cmd.exe HTTP/1.0
14    Connection: Keep-Alive
15    [CRLF]

Note : Toutes les lignes finissent par un saut de ligne "\r\n" ([CRLF]) sauf la 12e qui se termine par une espace mais sans saut de ligne.

Ces requêtes sont envoyées à un serveur web IIS 5.0. Une étrangeté de IIS 5.0 est qu'il tronque le corps d'une requête après 49152 octets lorsque l'attribut Content-Type n'est pas spécifié ou pas en rapport avec l'extension de l'objet demandé (application/x-www-form-urlencoded pour une page ASP). Ce point pris en compte, voici les deux interprétations qui seront faites.
Commençons par FW1 :

• A partir de la valeur récupérée à la ligne 4, FW1 sait qu'il doit traiter les 49223 prochains octets. Il va donc traiter comme une première requête la ligne 6 qui fait 49152 octets ainsi que les 71 octets restants (c'est-à-dire les lignes 7 à 10) ;
• Pour FW1, une nouvelle requête commence à la ligne 11. Comme la ligne 12 ne termine pas par [CRLF], le POST de la ligne 13 n'est traité que comme un paramètre de l'en-tête Bla de la ligne 12. FW1 possède bien une règle lui disant de bloquer les requêtes vers un URL qui contient cmd.exe, mais comme la chaîne de caractères ne fait ni partie de la demande d'URL, ni du corps de la requête. Celle-ci n'est pas filtrée.

Voyons maintenant comment IIS interprète la requête :

• Comme le Content-Type n'est pas spécifié, IIS présuppose que le Content-Length réel est tronqué à 49152 octets. Pour lui, la première requête s'arrête donc à la fin de la ligne 6 ;
• La seconde requête commence à la ligne 7 et possède un corps de 30 octets, soit jusqu'à la fin de la ligne 12 ;
• A la ligne 13 commence alors la troisième requête, qui comporte la faille en question – l'attaque est réussie.

Cette attaque s'appuie sur une interprétation erronée d’IIS, mais d'autres variantes permettent de passer outre le filtrage de différents proxies (ce n'est pas le but de cet article, mais le cache d'un proxy peut aussi être manipulé ainsi [APACHE-SMUG]) en se contentant de spécifier 2 fois l'en-tête Content-Length. Certains serveurs ou proxies prendront le premier en considération, d'autres le second.

L'implémentation qui ne suit pas la norme

Dans le cas d'exploitation de failles d'un serveur ayant un support SSL, il est possible d'inclure dans la négociation de la connexion SSL un champ dont la valeur associée est inexistante. La définition du protocole SSL spécifie que ce cas ne doit pas avoir lieu et la connexion ne sera plus suivie par plusieurs IDS. Comme en pratique, certaines implémentations SSL (par exemple, OpenSSL) ne font qu'ignorer les champs pour lesquels les valeurs sont vides, la négociation de la connexion SSL ne sera pas coupée.
Cet exemple montre bien qu'il puisse y avoir des distorsions d'interprétation entre un serveur et un IDS, même si l'IDS suit drastiquement les conseils d'implémentation d'un protocole.

D'autres limites

Le chiffrement

" Si c'est chiffré, c'est sécurisé " ! Voici une fausse idée que certains se font. Un flux chiffré n'arrête pas les attaques. Il empêche par contre l'IDS ou l'IPS de mener à bien son inspection. Il me semble donc utile de bien garder à l'esprit que le chiffrement permet certes d'éviter une interception malencontreuse des communications qui transitent, mais qu'il ne servira pas à grand-chose de demander à un IDS d'y détecter des attaques. Le chiffrement peut intervenir à plusieurs niveaux : certains sont évidents, comme pour IPsec ou les connexions SSL et d'autres le sont moins, comme le chiffrement à l'intérieur de requêtes RPC...

La nouveauté

La confiance placée dans l'inspection faite par un IDS ou un IPS a aussi une limite dans les nouveaux protocoles qui ne sont pas tout de suite supportés. Il suffit par exemple de se pencher sur l'ensemble des nouveaux protocoles de voix sur IP pour se dire qu'aucun IDS ne sera capable de les supporter rapidement. Non seulement, ils sont nombreux, mais en plus beaucoup sont complexes. La même remarque est pertinente pour les protocoles de peer to peer.
Dans le même ordre d'idée, il y a également un laps de temps non négligeable entre la publication d'une nouvelle faille et sa prise en compte dans un IDS. Tout d'abord, l'éditeur de l'IDS mettra systématiquement quelques jours pour écrire une ou plusieurs règles offrant la possibilité de détecter l'exploitation de la faille. Ensuite, la mise à jour des règles d'un IDS est rarement journalière et un délai sera alors ajouté avant l'installation sur les IDS en production.
Pour réduire ce défaut, certains éditeurs d'IDS ou d'IPS offrent des outils de mise à jour automatique des règles de filtrage, à l'instar de Oinkmaster [OINK] pour l'IDS Snort ou LiveUpdate pour l'IPS Symantec SNS. Initiative originale, la filiale de 3COM, éditrice d'IPS TippingPoint [TP], a lancé il y a peu un programme nommé " Zero Day Initiative [ZDI] " qui vise à rémunérer les chercheurs indépendants en sécurité informatique en échange de failles encore inconnues. Bien que TippingPoint soit en lien avec l'éditeur de logiciel touché par la faille pour corriger celle-ci et la rendre publique à terme, il sera tout de même le premier vendeur d'IPS à inclure une règle permettant de filtrer les nouvelles attaques.

Analyse de signatures

Lorsqu'une signature d'un IDS est connue, un attaquant peut très bien analyser celle-ci afin de déterminer une méthode d'évasion qui fonctionnera. Par exemple, une analyse rapide de signature peu amener à trouver, dans la chaîne de caractères recherchée par l'IDS, quels caractères pourraient être insérés ou déplacés afin de passer inaperçus. Ceci pourrait nous faire croire que les IDS Open Source tels que Snort sont moins sûrs, puisque leurs signatures sont connues de tous. Toutefois, les autres IDS ne sont pas à l'abri, car il est toujours possible de déterminer à partir de reverse engineering les critères de filtrages appliqués. La publication [REVERSE] en donne un exemple pour RealSecure, l'IDS d’Internet Sercurity Systems. Les auteurs y montrent comment, à partir des appels système qu'ils récupèrent via ptrace et d'outils qu'ils ont développés pour l'analyse des appels passés, ils arrivent à déterminer les critères de filtrages ainsi que le mode de fonctionnement du module d'analyse HTTP. Ces éléments leur permettent de proposer une méthode d'évasion pour une attaque donnée. Même si l'ingénierie inverse rend la tâche plus difficile, elle permet avec quelques efforts de passer outre les signatures propriétaire.

5. L'IDS ou l'IPS idéal

Après avoir exposé quelques lacunes des IDS ou des IPS, voici quelques caractéristiques de l'IDS ou l'IPS idéal : une inspection minutieuse de tous les protocoles possibles et imaginables, une interprétation de toutes les représentations de données qui puissent exister, des règles nombreuses et souples qui permettent de détecter toutes les variantes d'une attaque, etc. Mais pourquoi un tel IDS n'existe-t-il pas encore ? En grande partie parce qu'il faut faire des compromis sur l'utilisation de ressources système. Plus l'inspection est précise et plus les ressources nécessaires doivent être importantes. En dehors des dénis de services dus à l'implémentation d'algorithmes inadaptés [MISC19], les IDS doivent composer avec une contrainte de taille : normaliser, analyser et suivre simultanément quelques milliers de connexions. On ne peut demander à un seul IDS de traiter de long en large des requêtes que plusieurs serveurs ont souvent eux-mêmes du mal à satisfaire. Il paraît alors inévitable d'accepter cette imperfection pour permettre une inspection même incomplète mais non sujette à un déni de service.

Conclusion

Le filtrage applicatif ne résout pas tous les maux de la sécurité : il ne se substitue pas aux mises à jours de sécurité, il ne règle pas les erreurs logiques de programmation, il n'a pas de boule de cristal qui permet d'éviter les attaques encore inconnues et même dans ce qu'il sait très bien faire, il demeure faillible. Ces défauts doivent être corrigés par d'autres dispositifs afin de garantir une défense en profondeur. Il n'est qu'un maillon de la chaîne et doit être pris comme tel... avec ses forces et ses limites.

Références :

• [IED] Thomas H. Ptacek, Timothy N. Newsham, " Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection" :
• http://www.insecure.org/stf/secnet_ids/secnet_ids.html
• [FRAG] Site de Fragroute : http://www.monkey.org/~dugsong/fragroute/
• [RPC] Mine d'informations sur le protocole RPC : http://www.opengroup.org/onlinepubs/9629399/docix.htm
• [SNORT-VULN] Snort RPC Preprocessing Vulnerability : http://www.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=21951
• [ETHE] Ethereal Security Advisories : http://www.ethereal.com/appnotes/
• [XSS] XSS cheatsheet Esp: for filter evasion : http://ha.ckers.org/xss.html
• [ADM] ADMutate Homepage : http://www.ktwo.ca/security.html
• [LIBEXPLOIT] A generic exploit creation library : http://www.packetfactory.net/projects/libexploit/
• [MODSEC] ModSecurity : http://www.modsecurity.org/
• [WHISKER] Whisker : http://sourceforge.net/projects/whisker/
• [SMUGGLING] HTTP Request Smuggling, Watchfire : www.watchfire.com/resources/HTTP-Request-Smuggling.pdf
• [APACHE-SMUG] Apache HTTP Request Smuggling Vulnerability : http://www.securityfocus.com/bid/14106
• [SQUID-SMUG] Squid Proxy Cache Security Update Advisory SQUID-2005:4 : http://www.squid-cache.org/Advisories/SQUID-2005_4.txt
• [OINK] Oinkmaster : http://oinkmaster.sourceforge.net/
• [TP] TippingPoint : http://www.tippingpoint.com/
• [ZDI] Zero Day Initiative : http://www.zerodayinitiative.com/details.html
• [REVERSE] Mutz, Kruegel, Robertson, Vigna et Kemmerer, " Reverse Engineering of Network Signatures " :
• http://www.cs.ucsb.edu/~vigna/pub/2005_kruegel_mutz_robertson_vigna_kemmerer_auscert05.pdf
• [MISC19] Philippe Prados, " DoS par complexité ", MISC 19, Mai-Juin 2005, p. 31.

   Retrouvez cet article dans : Misc 21