Pour reprendre l'introduction, le déni de service se produit finalement dés qu'il y a une tentative de faire une opération sur une application avec les privilèges inadaptés. Cela provoque alors des effets de bords et rends le système inutilisable soit un déni de service. Pour résumer, lors d'un déni de service nous constaterons les effets suivants :

• Plantage du système
• Arrêt prématurés des processus (Thread qui sont lancés sur les processeurs)
• Crée un contexte de deadlock. C'est à dire des processus qui s'attendent mutuellement.
• Le point ci-dessus de deadlock provoque un autre effet de bords lorsqu'ils verouillent des ressources :  D'autres processus ne peuvent plus alors avoir accès aux ressources nécessaire pour effectuer leur traitement...

De tels problèmes se produisent souvent à cause de pilotes qui contiennent des bugs qui peuvent être exploité par de quelconque applications. L'exploitation de ce type d'anomalie est alors simple et il est difficile de se prémunir contre. Les causes communes de ce type de failles sont généralement :

• la validation du buffer utilisateur qui est incorrect.
• Une mauvaise utilisateur du buffer en dépassant sa capacité ou alors en utilisant un mauvais accès à la zone mémoire associé.

En gros on arrive dans la situation suivante :

Pour des systémes de fichiers ce genre de problème est fréquent. Il suffit de prendre l'exemple du nombre de caractéres possible pour un chemin de fichier. Il est limité pour des raisons historique à 260 caractéres sur les systèmes 32bits windows. Ainsi la plus part des pilotes ont une constante associée. Malheureusement, sur les systèmes Unix ou NTFS la limite est à 32'767 caractères unicode (ou 65'534 bytes). De ce fait, une maniére de provoquer un DO simplement et de tenter de faire créer par l'application un chemin de fichier qui dépasse cette taille...

Un autre problème commun avec les systèmes de fichiers sont les pointeurs sur les requêtes privées FSCTL que l'on retrouve en trois catégories :

• Consommation de tout l'espace libre disponible
• Utilisé toute la bande passante disponible
• Bloquer les accès aux fichiers dont les utilisateurs ont besoin

En soit, il y a peu de choses à faire pour un développeur pour se prémunir de ce type d'attaque et donc éviter les conséquences associées. Toutefois, cela signifie qu'il faut avoir mis en place les ce qu'il faut dés les fondations du développement, ce qui est trop souvent minorés par manque de temps ou de connaissances des développeurs.

Toutefois, il y a des aspects ou il est difficile d'évaluer l'impact notamment sur la gestion de la bande passante car les systémes d'exploitation ont souvent aucun ou peut de mécanisme pour surveiller la consommation par application. C'est ce qui rend les malwares difficile à détecter. Pour pallier ce type de risque il faut mettre en place des techniques de traces et d'audit permettant de surveiller ce qui se passe sur le systéme et minimiser le risque de déni de service.