La division par zéro est-elle une faille de sécurité?

Question

view on stackexchange narkive permalink

Même si parfois les bogues logiciels et les vulnérabilités sont considérés comme le même concept, il doit y avoir au moins un aspect distinct entre eux, et je pense que le plus important est l ' exploitabilité (ce dernier ayant le propriété).

Ce qui m'intéresse, c'est que, même après avoir vu de nombreux cas où des bogues de division par zéro sont signalés comme des problèmes logiciels, je ne peux guère trouver d'attaque (autre que DoS) en utilisant des bogues de division par zéro. Je sais que tous les types de bogues n'ont pas le même impact sur un système en termes de sécurité, mais y a-t-il une méthode d'attaque qui utilise des bogues de division par zéro pour obtenir quelque chose de différent de DoS, comme l'élévation de privilèges par exemple?

Answer 1

view on stackexchange narkive permalink

Le problème est qu'un gestionnaire d'exceptions sera appelé pour gérer la division par zéro. En général, les attaquants savent que les gestionnaires d'exceptions ne sont pas aussi bien testés que les flux de code normaux. Votre flux logique principal peut être solide et minutieusement testé, mais un gestionnaire d'exceptions peut être déclenché par des interruptions survenant n'importe où dans le code dans sa portée.

  int myFunction (int a, int b, SomeState state) {state (UNINITIALIZED); essayez {état.quelque chose (a / b); état (NORMAL); } catch () {state.quelque chose (b / a); état (INVERSÉ); } return retval;}  

Cet horrible pseudocode illustre en quelque sorte une manière dont la faille pourrait être exploitée. Disons qu'un état non initialisé est en quelque sorte vulnérable. Si cette routine est appelée, l'état est d'abord non initialisé. Si b est zéro, il intercepte l'exception et essaie de faire une autre logique. Mais si a et b sont tous les deux à zéro, il lance à nouveau, laissant l'état non initialisé.

La division par zéro elle-même n'était pas la vulnérabilité, c'est le mauvais code qui l'entoure qu'il est possible d'exploiter.

Answer 2

view on stackexchange narkive permalink

Pour ajouter un autre artificiel mais basé sur un exemple réel:

Il y a de nombreuses (nombreuses) lunes, mon lycée exécutait Novell Netware et l'avait configuré pour que les étudiants ne puissent pas exécuter directement une invite dos ( ce qui était ennuyeux si vous aviez par exemple besoin de formater une disquette). Cependant, il a été découvert que si vous entrez dans un mot de passe plus de X caractères (c'est-à-dire que vous maintenez simplement une touche enfoncée pendant un moment), cela planterait netware et ramènerait le système à ... une invite dos. Très probablement, il s'agissait d'un dépassement de tampon, mais le principe est le même: si vous avez affaire à un système (en particulier un système embarqué) qui gère au moins quelques plantages inattendus en vous faisant passer en mode maintenance, alors il y a un problème de sécurité. .

Answer 3

view on stackexchange narkive permalink

Comme le suggèrent les autres réponses, cela dépend entièrement de l'ensemble du système. Ce n'est pas seulement le code, mais aussi la plate-forme, le langage et le compilateur.

Par exemple en C ++, la division par zéro sur les entiers est un comportement indéfini. L'une des règles concernant ce langage particulier est que le compilateur peut supposer qu'un comportement indéfini ne se produira jamais et est autorisé à faire quoi que ce soit s'il le fait.

Tout comprend un crash avec un message d'erreur et un nettoyage, un crash sans message d'erreur et tout laisser dans un état étrange, ou le plus terrifiant essaie de continuer comme si de rien n'était.

Maintenant, dans la pratique, la plupart des bons compilateurs modernes essaient de planter proprement s'ils rencontrent quelque chose comme ça, mais cela devrait expliquer pourquoi on suppose qu'il s'agit d'une vulnérabilité. Si vous construisez simplement votre code avec un compilateur différent ou des paramètres différents, et que vous ne changez même pas le code, ce que fait le programme pourrait passer d'un crash propre à l'effacement de votre base de données.

Answer 4

view on stackexchange narkive permalink

Avec un serveur Web mal configuré, un environnement PHP pourrait révéler le chemin physique du script lorsqu'une division par zéro est provoquée (fuite de chemin interne):

  <? php $ denominator = $ _GET ['number']; echo 1 / $ denominator;  

En accédant à script.php? Number = 0, nous pourrions voir:

Attention : Division par zéro dans /var/www/html/script.php à la ligne 3.

Answer 5

view on stackexchange narkive permalink

Bien que je dise parfois dans mes ateliers et conférences que tous les problèmes de sécurité dans les logiciels sont essentiellement des bogues, l'inverse n'est pas automatiquement vrai.

Je n'irais cependant pas à l'exploitabilité comme argument. Ce n'est pas parce que vous et moi ne pouvez pas trouver un moyen d'exploiter que quelqu'un de plus rusé ne le fera pas un jour. Nous aurions à fournir une preuve formelle qu'il n'est pas exploitable. Bonne chance avec les preuves formelles dans les langages de programmation actuels.

Donc, pour répondre à votre question: une division par zéro pourrait être une vulnérabilité ou une partie de celle-ci. En général , cela entraînera une exception et donc la résiliation du logiciel. Cela en soi pourrait être une information importante pour un attaquant (il sait maintenant qu'une variable était nulle).

Il est peu probable que la division par zéro seule soit une faille de sécurité, mais dans un contexte plus large, cela peut faire partie du problème.

Donc, pour fermer la boucle, vous devez toujours traiter tous les bogues sérieusement. Si vous ne pouvez pas être sûr (par exemple, votre division utilise une variable que vous ne contrôlez pas), vous devez l'attraper et la gérer, sécurité ou non. "ouais, c'est un bogue mais je ne vois pas comment il pourrait être exploité" n'est pas un état d'esprit soucieux de la sécurité.

Answer 6

view on stackexchange narkive permalink

La division par zéro n'est pas intrinsèquement une faille de sécurité.

Cependant, si vous pouvez faire planter un serveur d'applications et rester hors ligne en le divisant par zéro, cela peut constituer une vulnérabilité de déni de service.

Answer 7

view on stackexchange narkive permalink

Je pense qu’au bout du compte, votre réponse dépendra du système individuel en jeu. Comment le système gère-t-il la tentative de division par 0? Si c'est élégant, alors vos options d'attaque sont limitées ou inexistantes. Si cela fait quelque chose de funky, vous pouvez probablement y entrer avec quelque chose.

En gros, aucune attaque standard ne peut en sortir - que je sache de toute façon - mais les ordinateurs peuvent toujours gérer les bogues mal, et mauvais la gestion des bogues est à l'origine de nombreuses vulnérabilités.

Answer 8

view on stackexchange narkive permalink

Si un programme ne reçoit que des données fiables, et s'il ne doit répondre à aucune exigence comportementale lorsque des données conçues de manière malveillante sont fournies, il peut alors être possible de générer un code légèrement plus efficace que ce qui serait requis s'il y avait des exigences auxquelles il devait répondre pour toutes les données.

Étant donné que certaines tâches impliquent uniquement le traitement de données fiables, tandis que d'autres impliquent le traitement de données provenant de sources non fiables, la norme C autorise les implémentations destinées uniquement aux tâches précédentes. optimisations qui seraient inappropriées dans celles destinées à ces dernières, et à celles destinées à convenir à ces dernières tâches pour offrir des garanties qui empêcheraient inutilement les optimisations qui pourraient être utiles lors du traitement des premières.

Malheureusement, le La norme ne fournit aucun moyen par lequel les implémentations peuvent indiquer les types de garanties comportementales qu'elles offriront au-delà de celles prescrites par la norme. Lors de la rédaction de la C89, les auteurs s'attendaient à ce que "le marché" fasse un meilleur travail que les auteurs de la norme pour déterminer quels types d'implémentations devraient prendre en charge quelles "extensions populaires" en se comportant au moins de manière assez prévisible dans les cas où la norme n'imposait aucune exigences, et une telle attitude n'a pas changé même si elle ne correspond plus au marché actuel des compilateurs.

Étant donné quelque chose comme:

  if (x! = 0) launch_nuclear_missiles (); ... et puis, éventuellement dans une autre fonctionz = y / x;  

certaines personnes verraient un compilateur qui remplace le "si" par un appel inconditionnel à launch_nuclear_missiles () comme supérieur à celui qui n'appelle launch_nuclear_missiles que si x est différent de zéro, mais un tel comportement ne serait approprié que lors du traitement de tâches qui n'impliqueront jamais d'entrée non fiable.

Si l'on sait que les compilateurs que l'on utilise maintiendront les types de faibles garanties comportementales que les compilateurs à usage général offraient naturellement, et qui facilitent l'écriture de programmes qui pourraient rencontrer de faibles contraintes comportementales même lorsqu'ils sont donnés de manière malveillante. les intrants fabriqués, puis la division par zéro pourrait ne pas poser de problèmes de sécurité. Cependant, avec des compilateurs à optimisation agressive qui ne sont pas conçus pour être adaptés aux tâches impliquant des entrées non fiables, il sera nécessaire d'ajouter suffisamment de logique de contrôle de sécurité pour annuler tous les avantages que de telles "optimisations" auraient pu offrir.

Answer 9

view on stackexchange narkive permalink

mais y a-t-il une méthode d'attaque qui utilise des bogues de division par zéro pour obtenir quelque chose de différent de DoS, comme l'élévation de privilèges par exemple?

Recherche rapide sur la base de données CVE de MITRE révélera que la plupart du temps la division par zéro provoque un déni de service, mais un cas particulier CVE-2005-0998 permet autre chose:

Description Le module Web_Links pour PHP-Nuke 7.6 permet aux attaquants distants d'obtenir des informations sensibles via un paramètre show invalide, ce qui déclenche une division par zéro erreur PHP qui fuit le chemin complet du serveur.

Cela en soi ne permet pas une élévation de privilèges ou des attaques spécifiques, mais de manière générale, les informations sensibles peuvent être utiles pour créer d'autres attaques. En d'autres termes, la division par zéro en elle-même pourrait n'être qu'un tremplin.

Answer 10

view on stackexchange narkive permalink

Je vois d'où vous venez à ce sujet. En soi, il est difficile de voir comment une simple erreur arithmétique pourrait être utilisée pour causer tout ce qui nécessitait une entrée de données (comme l'exécution de code).

Cependant, selon le langage, cela pourrait causer des problèmes de contrôle de flux ou sélectivement crash des threads etc. C'est le genre de chose qui vous permet d'aggraver d'autres problèmes ou si vous êtes vraiment (pas) chanceux, de conduire directement à déclencher une voie qui cause le double de quelque chose d'exploitable. N'oubliez pas que l'entrée de données et le bogue ne doivent pas nécessairement être identiques.

C'est un peu artificiel, mais disons par exemple que vous avez déplacé un objet déjà dans une liste liée en ajoutant une copie à la tête, puis itérer jusqu'à ce que vous la trouviez et supprimiez la copie.Si vous faites cela dans un thread et pour une raison quelconque (disons que quelqu'un met une instruction stats print dans la boucle d'itération qui est fausse), il est possible que cela quitte la liste dans un mauvais état avec 2 copies du même élément.Lorsque cela est nettoyé: double free ...

Si vous pouvez contrôler le contenu de ce nouvel élément, et que la statistique entraîne une division par zéro et toujours contrôler suffisamment le contenu, cela pourrait bien être exploitable.

Peu probable, mais possible.

Answer 11

view on stackexchange narkive permalink

La question pourrait être mieux formulée comme suit: "Pourquoi le déni de service est-il considéré comme une faille de sécurité?". Lors de l'exécution de Linux sur un processeur x86, si le processeur divise un entier par 0 (ou la valeur entière minimale signée divisée par -1, merci supercat), le programme reçoit un signal SIGFPE. Sous Windows, c'est une opération illégale. La norme C / C ++ considère qu'il s'agit d'un comportement non défini, ce qui signifie que vous ne pouvez pas savoir de manière fiable ce qui se passera simplement en regardant le code.

Normalement, comme avec de nombreuses vulnérabilités de déni de service, mais pas toutes, il en résultera dans un "crash". Voici quelques possibilités de ce que vous pouvez exploiter lorsqu'un programme a une terminaison anormale:

• Cela pourrait permettre à un autre programme d'utiliser les mêmes ressources que le premier (comme un port) et de faire semblant d'être le même programme .
• Un crash peut contourner toute opération de nettoyage utilisée par le programme qui pourrait être exploitée.
• Si le code de sortie du programme est utilisé dans un autre programme qui ne vérifie pas le signal état du PID du processus enfant, il pourrait penser que le programme a renvoyé un code d'erreur. Par exemple, sur ma machine Linux, les 2 programmes suivants définissent tous les deux $? (la variable utilisée dans les scripts shell pour représenter le code retour de la commande précédente) sur 136 : int main (int argc, char ** argv) {return 1 / (argc - 1); } et int main () {return 136; }
• Un plantage peut entraîner des choses comme des coredumps qui peuvent contenir de la mémoire protégée comme des clés de sécurité, des mots de passe et la recette de Coca-Cola.

De plus, à cause des optimisations, le compilateur peut choisir de supposer que le diviseur ne pourrait jamais être 0 et optimiser potentiellement le code que vous n'auriez peut-être pas envisagé. Cela ne s'applique qu'aux langages compilés comme C et C ++ qui ont un comportement non défini (ou son équivalent) pour la division par zéro. Je ne pouvais pas produire de code optimisé qui fasse cela en utilisant les exemples dans d'autres réponses dans clang ou gcc, mais rien ne les empêche ou d'autres compilateurs de faire cela dans le passé ou dans le futur.

Answer 12

view on stackexchange narkive permalink

Voici un exemple où cela pourrait faire une différence.

C'est 100% artificiel - mais de nombreuses classes d'exploits sont identifiées par des exemples théoriques "artificiels", jusqu'à ce que des exemples spécifiques soient trouvés.

C'est un pseudo-code.

  essayez: obtenez l'utilisation moyenne du processeur par utilisateur connecté si cette moyenne est trop élevée, dites à la personne qui se connecte que nous sommes occupés. obtenir les identifiants de connexion vérifier les identifiants de connexion si les identifiants ne sont pas valides, leur dire de partir restreindre l'accès pour cette session à l'accès correct pour cet utilisateur s'il y a une exception: ne rien laisser à l'utilisateur dans  

Dans dans ce cas, le processeur moyen par utilisateur connecté peut être calculé comme suit: "CPU total / nombre d'utilisateurs connectés" - s'il n'y a pas d'utilisateurs connectés, vous obtenez "diviser par 0", et il passe directement à "s'il y a est une clause d'exception. Cela inclut la restriction d'accès - la nouvelle session peut avoir un accès correspondant au dernier utilisateur à se connecter, ou un accès illimité.

Bien que cet exemple montre tout le code ensemble, votre code principal appellera souvent quelque chose, qui appelle quelque chose sinon, et les deux aspects qui interagissent (dans ce cas, la division par 0 et le fait que l'exception est ignorée) peuvent s'exécuter dans des parties du code très éloignées.

Comme beaucoup de gens l'ont mentionné, la division par zéro (à elle seule) n'est pas un bogue de sécurité, ni même un bogue du tout. Autant que je sache, la plupart des langages de programmation (peut-être tous!) Ont des informations clairement documentées sur ce qui se passe lorsque la division par zéro se produit. Je pense que presque toutes les langues qui ont des exceptions ont une exception pour la division par zéro (j'ai vu une calculatrice mécanique se coincer dans une boucle sans fin).

Answer 13

view on stackexchange narkive permalink

Il y a ici des réponses très spécifiques. Je conviens qu'une division (non gérée) par zéro est avant tout un problème fonctionnel - mais cela ne signifie pas qu'elle ne peut pas être exploitée comme un problème de sécurité. En effet, il y a tellement de bogues qui peuvent être exploités que la classification «fonctionnel» vs «sécurité» appliquée aux bogues semble quelque peu inutile.

Vous rejetez une catégorie de problèmes de sécurité (DOS) sans aucune discussion sur ce que vous considérez comme hors de portée ici. Le scénario le plus évident est que le déclenchement de l'erreur provoquera l'arrêt de l'instance du programme. Mais il y a des effets plus subtils - si cela provoque l'écriture de grandes quantités de données dans le système de fichiers (comme un vidage de mémoire), cela présente une avenue pour un deuxième type de DOS, en remplissant le système de fichiers.

Jefrey mentionne la divulgation pour une application PHP - mais les messages d'erreur, les journaux et les vidages de mémoire fournissent des bases de choix riches pour les personnes essayant d'extraire des informations auxquelles elles ne devraient pas avoir accès à partir de programmes écrits dans n'importe quelle langue.

Si cela est prématuré la fin du programme conduit à une sorte de réponse, puis un attaquant a les moyens de déclencher un programme spécifique à un moment de son choix - il a un certain contrôle sur ce que fait votre système, ce qui peut faciliter une attaque / élévation de privilèges.

Même si le système de contrôle est manuel, il existe toujours un état de transition pour le système où les comportements de sécurité sont moins bien définis et où les actifs tels que les phrases de passe, les mots de passe et les clés privées sont en vol.