Question:
La division par zéro est-elle une faille de sécurité?
Gwangmu Lee
2019-03-04 07:15:23 UTC
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?

J'ai un vague souvenir d'un CVE d'il y a de nombreuses années qui était à la base une division par zéro, mais qui était un bogue de code arbitraire racine distant.C'était * probablement * quelque chose comme ce que John Deters a décrit, mais je ne me souviens pas assez pour risquer de donner une réponse.
Je suppose que vous parlez de division * entier * par zéro?Parce que la division par zéro en virgule flottante IEEE 754 est bien définie et ne devrait donc pas poser de problème (mais certaines parties de ce qui s'applique dans le scénario de la réponse de John Deters s'appliqueraient également ici).
Une autre chose à retenir de cette question est que la révision du code devrait garantir que le dénominateur est vérifié avant chaque opération de division.Un dénominateur nul indique une sorte d'erreur qui doit être étudiée.
J'étais sur un projet où nous devions signaler une division par zéro contrôlable par l'utilisateur comme une faille de sécurité majeure pour le gouvernement américain.les utilisateurs pouvaient créer des paquets qui provoqueraient une opération mod 0, ce qui entraînerait une division par 0. la chose qui a été tuée était un système de prévention des intrusions.ainsi, vous pouvez le désactiver avec un paquet astucieux, juste avant de commencer une attaque.bien sûr, c'est un exemple très étrange et spécifique.
@Rob Ohhh c'est très intéressant.Je n'ai jamais pensé à un cas où DoS ouvre directement d'autres trous.
Il y a eu plusieurs cas de [crash des économiseurs d'écran] (https://www.jwz.org/blog/2015/04/i-told-you-so-again/) en raison de choses comme celle-ci, laissant le système déverrouillé et non protégé
@thatotherguy: Je ne me suis jamais soucié du fonctionnement des économiseurs d'écran, car c'est une chose tellement superflue depuis au moins 20 ans.Mais si cela fonctionne vraiment de telle manière que le crash de l'économiseur d'écran peut laisser l'ordinateur déverrouillé, alors la conception entière est sérieusement stupide, de bas en haut - une division par zéro est le plus petit problème dans ce cas.Mon attente de base serait que l '_environnement de bureau_ verrouille l'utilisateur (et désactive le matériel tel que 1394 / USB), puis appelle un _toy program_ qui peut (idéalement) faire un peu plus que dessiner des lignes idiotes sur l'écran.
Treize réponses:
#1
+105
John Deters
2019-03-04 10:09:31 UTC
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.

Les commentaires ne sont pas destinés à une discussion approfondie;cette conversation a été [déplacée vers le chat] (https://chat.stackexchange.com/rooms/90763/discussion-on-answer-by-john-deters-is-divide-by-zero-a-security-vulnerability).
#2
+50
Foon
2019-03-04 20:33:24 UTC
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é. .

Ramène de bons souvenirs ...
Un jour, je devrai raconter toute l'histoire de l'exploitation d'une faille similaire dans certains logiciels de tableau d'affichage d'Apple].Le logiciel a été initialement écrit pour un BASIC entier mais porté en BASIC en virgule flottante sans trop de considération.Vous pourriez provoquer le crash du BASIC en virgule flottante avec un débordement en entrant simplement "99e999" à n'importe quelle invite de saisie entière.Cela vous mènerait à une invite de commande et vous pourriez, par exemple, lire des e-mails privés ou des forums auxquels vous n'étiez pas autorisé à accéder.
#3
+19
Josiah
2019-03-04 14:24:40 UTC
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.

Le dernier paragraphe dépend de la définition de «bon».Certaines personnes considéreraient un compilateur qui optimise `if (x! = 0) launch_nuclear_missiles ();return 1 / x; `en rendant l'appel de fonction inconditionnel comme supérieur à celui qui ne le fait pas.Je dirais que les compilateurs de qualité * qui sont conçus pour être adaptés aux tâches impliquant des entrées non fiables * devraient soit planter soit ne rien faire en réponse à une division par zéro (si le code calcule `z = y / x;` mais n'utilise jamais `z`, un compilateur qui ignore complètement `x` ne doit généralement pas être considéré comme inférieur à celui qui piège s'il est nul), mais ...
... pour les tâches qui n'impliqueront jamais d'entrée non fiable, une sémantique plus lâche peut être raisonnable.
@supercat Je pense qu'il faudrait une garantie que `launch_nuclear_missles` revient toujours.
@SolomonUcko: Pourquoi?Si «x» vaut zéro, la division par zéro se produirait, que la fonction retourne ou non si elle est appelée.Si «x» n'est pas égal à zéro, la fonction peut retourner sans appeler UB.
@supercat Oups, tant pis.Le manque d'accolades et le fait que tout soit sur une seule ligne me trébuche.
@supercat: "Je dirais que les compilateurs de qualité qui sont conçus pour convenir à des tâches impliquant des entrées non fiables devraient soit planter soit ne rien faire en réponse à une division par zéro" - j'ai l'impression que vous confondez compilateurs et interprètes.L'entrée d'un compilateur est le texte du programme;la sortie est un programme exécutable.Une entrée non fiable dans l'exécutable résultant ne peut pas voyager dans le temps pour planter le compilateur.Quant à «ne rien faire», cela ne résout généralement pas le problème.Dans `double x = y / 0`, omettre l'initialisation laisserait` x` non initialisé, provoquant UB plus tard.
@MSalters: Sur la plupart des plates-formes, à moins qu'une implémentation ne fasse tout son possible pour provoquer un autre comportement, une tentative de chargement d'une valeur indéterminée de type `double` chargera une valeur arbitraire ou déclenchera un trap dont le comportement par défaut forcera la fin anormale du programme.De même pour la plupart des formes d'UB autres que celles qualifiées de «comportements critiques indéfinis» dans l'annexe L. (IIRC). Bien que l'annexe L soit rédigée de manière trop imprécise pour vraiment signifier quoi que ce soit (pour être significative, elle doit définir un modèle comportemental, puis spécifier que non-critical UB peut se comporter de n'importe quelle manière qui est ...
... conformément à ce modèle) la notion selon laquelle les implémentations devraient interpréter UB comme une excuse pour sauter les rails * même lorsque la plate-forme sous-jacente permettrait à une implémentation d'offrir des garanties comportementales utiles à un coût généralement nul en dehors des scénarios artificiels *.La réputation de C comme étant un langage rapide venait du fait que si sur une plate-forme particulière les exigences d'un programme pouvaient être satisfaites sans vérifier certaines conditions dans le code machine, ni le programmeur ni le compilateur n'auraient besoin d'inclure de telles vérifications.Si les programmeurs doivent inclure de telles vérifications ...
... même dans les cas où le comportement naturel de l'environnement pourrait répondre aux exigences sans eux, cela obligera les programmeurs à écrire du code qui ne peut pas être traité aussi efficacement qu'il aurait été possible en exploitant le comportement de la plateforme.
#4
+16
Jefrey Sobreira Santos
2019-03-05 04:53:16 UTC
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.

Il vaut peut-être la peine d'ajouter à cela que vous l'utilisez parfois pour obtenir des erreurs encore plus détaillées: ("Error near Select * from passwords where logins = 1/0") 'Verbose errors' est une mauvaise configuration mais c'est un moyen peu coûteux del'exploiter.
Ce serait une installation PHP très mal configurée.Non pas que de telles installations n'existent pas.display_errors n'a pas été expédié par défaut depuis LONGTEMPS.
#5
+13
Tom
2019-03-04 14:54:38 UTC
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é.

"tous les problèmes de sécurité dans les logiciels sont essentiellement des bogues" et certains d'entre eux sont PEBCAK = P
@aloMalbarez Je défie régulièrement les gens sur cette hypothèse.Heck, j'ai prononcé un discours liminaire à ce sujet.«users == losers» est l'excuse que les paresseux utilisent pour ne pas discuter de leurs lacunes dans la conception de l'interface utilisateur, de la visibilité des conséquences ou du transfert de blâme.
#6
+10
duskwuff -inactive-
2019-03-04 08:26:15 UTC
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.

Cela a déjà été mentionné dans la question.
@JAD: Il semble y avoir deux classes liées pour les attaques par déni.Premièrement, fournissez une entrée unique de sorte que l'état du serveur soit constamment corrompu.Deuxièmement, fournissez des entrées répétées qui plantent le serveur à plusieurs reprises.Cette réponse semble couvrir le premier scénario (_stay offline_) tandis que la question semble couvrir le second.Mais ils sont définitivement liés.
@jad, à cet égard, le titre et la question sont incohérents.Devrait probablement changer le titre.
Fondamentalement, tout bogue dans un programme qui peut le faire planter est potentiellement une vulnérabilité de sécurité, et un échec pour empêcher la division par zéro est un tel bogue commun, mais il n'y a pas de différence inhérente entre cela et d'autres causes de plantage.Par exemple, une erreur de tableau hors limites est tout aussi dangereuse.
#7
+5
securityOrange
2019-03-04 07:22:09 UTC
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.

Je ne suis certainement pas satisfait de la façon dont les processeurs Intel Pentium II les ont gérés.
Des bogues de division par zéro vont être dans l'application.Si cela arrive au niveau du processeur, vous avez déjà un problème.
Je sais.Intel a eu ce problème quand ils sont passés des processeurs P1 aux processeurs P2.
#8
+5
supercat
2019-03-04 23:20:57 UTC
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.

@PeterCordes: Si `x` n'est pas égal à zéro, la fonction peut retourner sans provoquer UB.Si «x» vaut zéro, alors UB se produirait indépendamment de ce que la fonction ferait si elle était appelée.
Oh oui, tu as raison.L'argument @SolomonUcko's ne tient pas, car `x = 0` entraînerait l'exécution de` y / x` * sans * un appel à une fonction éventuellement non retournée, et on peut donc supposer que cela ne se produit pas.Évidemment, ce code a un bogue, mais oui certains modes de défaillance sont pires que d'autres.C n'est pas une langue sûre.
@PeterCordes: Il est dommage qu'il soit à la mode pour les compilateurs de considérer les «extensions populaires» auxquelles fait allusion le raisonnement comme des «opportunités d'optimisation manquées», plutôt que de reconnaître qu'elles ont permis à de nombreux programmes de répondre aux exigences à un meilleur prix qu'il ne le serait autrement.
#9
+4
Sergiy Kolodyazhnyy
2019-03-06 09:35:44 UTC
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.

#10
+3
ANone
2019-03-04 20:26:08 UTC
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.

#11
+2
Erroneous
2019-03-06 04:57:49 UTC
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.

La question de savoir si un "crash" représente une vulnérabilité de sécurité est une fonction de l'environnement d'exécution.Si l'on utilise une implémentation C folle et agressive, cependant, toute action dont le comportement n'est pas mandaté par le standard C peut provoquer des vulnérabilités de sécurité même dans un environnement où le «crash» ne le ferait pas.
@supercat J'ai essayé d'améliorer ma réponse en fonction de vos commentaires
Vous devez dire que si * le code machine * fonctionnant sous Linux tente une division entière par zéro (ou une division entière 32 bits de -2147483648 par -1), il lèvera un `SIGFPE`.Un programme AC qui tente d'effectuer une telle division poserait des failles de sécurité dans les cas où un SIGFPE pourrait le faire, mais aussi dans les cas où l'hypothèse d'un optimiseur C selon laquelle les entrées d'un programme ne résulteront jamais en une division par zéro peut entraîner un compilateur optimisant la sécuritécode qui ne serait pertinent que si de telles entrées se produisent.
#12
+1
AMADANON Inc.
2019-03-05 03:54:57 UTC
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).

#13
+1
symcbean
2019-03-06 18:52:58 UTC
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.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 4.0 sous laquelle il est distribué.
Loading...