Es geht darum, dass ein Ausnahmebehandler aufgerufen wird, um die Division durch Null zu behandeln. Im Allgemeinen wissen Angreifer, dass Ausnahmebehandlungsroutinen nicht so gut getestet sind wie normale Codeflüsse. Ihr Hauptlogikfluss ist möglicherweise solide und gründlich getestet, aber ein Ausnahmebehandler kann durch Interrupts ausgelöst werden, die an einer beliebigen Stelle im Code innerhalb seines Bereichs auftreten.

  int myFunction (int a, int b, SomeState-Status) {state (UNINITIALIZED); try {state.something (a / b); Zustand (NORMAL); } catch () {state.something (b / a); Zustand (INVERTIERT); } return retval;}  

Diese schreckliche Pseudocode-Art zeigt, wie der Fehler ausgenutzt werden kann. Nehmen wir an, ein nicht initialisierter Staat ist irgendwie verwundbar. Wenn diese Routine aufgerufen wird, wird der Status zuerst nicht initialisiert. Wenn b Null ist, fängt es die Ausnahme ab und versucht, eine andere Logik auszuführen. Wenn jedoch sowohl a als auch b Null sind, wird erneut ausgelöst, sodass der Status nicht initialisiert wird.

Die Division durch Null selbst war nicht die Sicherheitsanfälligkeit, sondern der schlechte Code, der ausgenutzt werden kann.

Um ein weiteres erfundenes Beispiel hinzuzufügen, das jedoch auf einem realen Beispiel basiert:

Vor vielen (vielen) Monden führte meine High School Novell Netware aus und hatte es so konfiguriert, dass die Schüler keine Dos-Eingabeaufforderung direkt ausführen konnten ( was ärgerlich war, wenn man zB eine Diskette formatieren musste). Es wurde jedoch festgestellt, dass bei einer Eingabe eines Kennworts mit mehr als X Zeichen (d. H. Wenn Sie nur eine Weile eine Taste gedrückt halten) die Netware abstürzt und das System auf ... eine Dos-Eingabeaufforderung zurückgesetzt wird. Höchstwahrscheinlich war dies ein Pufferüberlauf, aber das Prinzip ist dasselbe: Wenn Sie es mit einem System (insbesondere einem eingebetteten) zu tun haben, das zumindest einige unerwartete Abstürze behandelt, indem Sie in einen Wartungsmodus versetzt werden, besteht ein Sicherheitsrisiko .

Wie die anderen Antworten vermuten lassen, hängt dies vollständig vom gesamten System ab. Das ist nicht nur der Code, sondern auch die Plattform, Sprache und der Compiler.

In c ++ ist beispielsweise die Division durch Null bei Ganzzahlen ein undefiniertes Verhalten. Eine der Regeln für diese bestimmte Sprache ist, dass der Compiler möglicherweise davon ausgeht, dass undefiniertes Verhalten niemals auftritt und dass er in diesem Fall alles tun darf.

Alles beinhaltet einen Absturz mit einer Fehlermeldung und Aufräumen, einen Absturz ohne Fehlermeldung und alles in einem seltsamen Zustand oder den schrecklichsten Versuch, weiterzumachen, als wäre nichts passiert.

In der Praxis versuchen die meisten guten modernen Compiler, sauber abzustürzen, wenn sie auf so etwas treffen. Dies sollte jedoch klar machen, warum davon ausgegangen wird, dass es sich um eine Sicherheitsanfälligkeit handelt. Wenn Sie Ihren Code nur mit einem anderen Compiler oder anderen Einstellungen erstellen und den Code nicht einmal ändern, kann das Programm von einem sauberen Absturz bis zum Löschen Ihrer Datenbank reichen.

Insgesamt könnte eine PHP-Umgebung bei einem falsch konfigurierten Webserver den physischen Pfad zum Skript anzeigen, wenn eine Division durch Null verursacht wird (interne Pfadleckage):

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

Beim Zugriff auf script.php? Number = 0 konnten wir Folgendes sehen:

Warnung stark>: Division durch Null in /var/www/html/script.php in Zeile 3.

Während ich in meinen Workshops und Vorträgen manchmal sage, dass alle Sicherheitsprobleme in Software im Wesentlichen Fehler sind, ist das Gegenteil nicht automatisch der Fall.

Ich würde jedoch nicht auf die Ausnutzbarkeit als Argument eingehen. Nur weil Sie und ich keinen Weg finden, etwas auszunutzen, heißt das nicht, dass jemand, der schlauer ist, es nicht eines Tages tun wird. Wir müssten einen formalen Beweis erbringen, dass es nicht ausnutzbar ist. Viel Glück mit formalen Beweisen in aktuellen Programmiersprachen.

Um Ihre Frage zu beantworten: Eine Division durch Null könnte eine Sicherheitslücke oder ein Teil davon sein. In der Regel führt dies zu einer Ausnahme und damit zur Beendigung der Software. Dies allein könnte eine wichtige Information für einen Angreifer sein (er weiß jetzt, dass eine Variable Null war).

Es ist unwahrscheinlich, dass die Division durch Null allein eine Sicherheitslücke darstellt, aber In einem größeren Kontext kann dies ein Teil des Problems sein.

Um die Schleife zu schließen, sollten Sie alle Fehler immer ernsthaft behandeln. Wenn Sie nicht sicher sein können (z. B. dass Ihre Abteilung eine Variable verwendet, die Sie nicht steuern), müssen Sie sie abfangen und verarbeiten, ob sicher oder nicht. "Ja, es ist ein Fehler, aber ich sehe nicht, wie er ausgenutzt werden kann" ist keine sicherheitsbewusste Denkweise.

Division durch Null ist von Natur aus keine Sicherheitslücke.

Wenn Sie jedoch einen Anwendungsserver zum Absturz bringen und offline bleiben können, indem Sie ihn durch Null teilen, kann dies eine Rolle spielen eine Denial-of-Service-Sicherheitsanfälligkeit.

Ich denke, letztendlich wird Ihre Antwort auf das einzelne System im Spiel ankommen. Wie geht das System damit um, durch 0 zu teilen? Wenn es elegant ist, sind Ihre Angriffsoptionen begrenzt oder nicht vorhanden. Wenn es etwas Funky macht, können Sie wahrscheinlich mit etwas da reinkommen.

Grundsätzlich können daraus keine Standardangriffe entstehen - das weiß ich sowieso -, aber Computer können immer schlecht und schlecht mit Fehlern umgehen Der Umgang mit Fehlern ist die Quelle vieler Sicherheitslücken.

Wenn ein Programm nur vertrauenswürdige Daten empfängt und keine Verhaltensanforderungen erfüllen müsste, wenn böswillig gestaltete Daten angegeben werden, kann möglicherweise etwas effizienterer Code generiert werden, als dies bei einem bestimmten Verhalten erforderlich wäre Anforderungen, die es für alle Daten erfüllen musste.

Da einige Aufgaben nur die Verarbeitung vertrauenswürdiger Daten beinhalten, während andere die Verarbeitung von Daten aus nicht vertrauenswürdigen Quellen beinhalten, ermöglicht der C-Standard Implementierungen, die nur für die früheren Aufgaben vorgesehen sind Optimierungen, die für diejenigen, die für letztere vorgesehen sind, und für diejenigen, die für letztere Aufgaben geeignet sind, unangemessen wären, um Garantien zu bieten, die Optimierungen unnötig behindern würden, die bei der Verarbeitung der ersteren nützlich sein könnten.

Leider ist die Der Standard bietet keine Möglichkeit, mit der Implementierungen angeben können, welche Arten von Verhaltensgarantien sie über die vom Standard vorgeschriebenen hinaus bieten. Als C89 geschrieben wurde, erwarteten die Autoren, dass "der Marktplatz" einen besseren Job als die Autoren des Standards machen könnte, um zu bestimmen, welche Arten von Implementierungen welche "populären Erweiterungen" unterstützen sollten, indem sie sich zumindest etwas vorhersehbar verhalten, wenn der Standard Nein auferlegt Anforderungen, und diese Einstellung hat sich nicht geändert, obwohl sie nicht mehr zum heutigen Compiler-Markt passt.

Gegeben etwa:

  if (x! = 0) launch_nuclear_missiles (); ... und dann, möglicherweise in einer anderen Funktionz = y / x;  

, würden einige Leute einen Compiler anzeigen, der das "if" durch einen bedingungslosen Aufruf von launch_nuclear_missiles () ist einem überlegen, der launch_nuclear_missiles nur aufruft, wenn x ungleich Null ist. Ein solches Verhalten wäre jedoch nur dann angemessen, wenn Aufgaben verarbeitet werden, die niemals nicht vertrauenswürdige Eingaben beinhalten.

Wenn man weiß, dass die Compiler, die man verwendet, die Arten von Garantien für schwaches Verhalten einhalten, die Allzweck-Compiler selbstverständlich angeboten haben und die das Schreiben von Programmen erleichtern, die schwache Verhaltensbeschränkungen erfüllen können, selbst wenn sie böswillig angegeben werden. gestaltete Eingaben, dann Division durch Null stellen möglicherweise keine Sicherheitslücken dar. Bei aggressiv optimierenden Compilern, die nicht für Aufgaben mit nicht vertrauenswürdiger Eingabe geeignet sind, muss jedoch eine ausreichende Logik zur Sicherheitsüberprüfung hinzugefügt werden, um alle Vorteile zu negieren, die solche "Optimierungen" hätten bieten können.

, aber gibt es eine Angriffsmethode, bei der Fehler, die durch Null geteilt werden, verwendet werden, um etwas anderes als DoS zu erreichen, z. B. die Eskalation von Berechtigungen?

Schnellsuche in der CVE-Datenbank von MITRE zeigt, dass die Division durch Null meistens Denial-of-Service verursacht, aber in einem bestimmten Fall CVE-2005-0998 ist noch etwas anderes möglich:

Beschreibung Das Web_Links-Modul für PHP-Nuke 7.6 ermöglicht es Angreifern von Remotestandorten aus, vertrauliche Informationen über einen ungültigen show-Parameter abzurufen, der eine Division durch einen PHP-Fehler von Null auslöst, der den vollständigen Pfadnamen des Servers verliert.

Dies selbst ermöglicht keine Eskalation von Berechtigungen oder bestimmte Angriffe, aber im Allgemeinen können vertrauliche Informationen bei der Erstellung anderer Angriffe hilfreich sein. Mit anderen Worten, die Division durch Null allein könnte nur ein Sprungbrett sein.

Ich sehe, woher du kommst. An sich ist es schwierig zu erkennen, wie nur ein Rechenfehler verwendet werden kann, um alles zu verursachen, was eine Dateneingabe erfordert (wie die Codeausführung).

Abhängig von der Sprache kann es jedoch zu Problemen bei der Flusssteuerung oder selektiv kommen Absturz-Threads usw. Auf diese Weise können Sie andere Probleme verschärfen oder, wenn Sie wirklich (unglücklich) sind, direkt dazu führen, dass ein Pfad ausgelöst wird, der doppelt so viel ausnutzbar macht. Denken Sie daran, dass die Dateneingabe und der Fehler nicht unbedingt identisch sein müssen.

Dies ist ein wenig erfunden, aber sagen Sie beispielsweise, Sie haben ein Objekt, das sich bereits in einer verknüpften Liste befindet, durch Hinzufügen einer Kopie zu verschoben Wenn Sie dies in einem Thread tun und aus irgendeinem Grund (sagen wir, jemand fügt eine Statistik-Druckanweisung in die falsche Iterationsschleife ein), wird die Liste möglicherweise verlassen in einem schlechten Zustand mit 2 Kopien desselben Elements. Wenn dies bereinigt wird: doppelt frei ...

Wenn Sie den Inhalt dieses neuen Elements steuern und die Statistik zu einer Teilung führen können Wenn Sie den Inhalt auf Null setzen und dennoch genügend Kontrolle über den Inhalt haben, kann dies durchaus ausgenutzt werden.

Nicht wahrscheinlich, aber möglich.

Die Frage könnte besser formuliert werden als "Warum wird Denial of Service als Sicherheitslücke angesehen?". Wenn Linux auf einem x86-Prozessor ausgeführt wird und der Prozessor eine Ganzzahl durch 0 teilt (oder den minimalen vorzeichenbehafteten Ganzzahlwert geteilt durch -1, dank supercat), empfängt das Programm ein SIGFPE-Signal. In Windows ist dies eine illegale Operation. Der C / C ++ - Standard betrachtet es als undefiniertes Verhalten, was bedeutet, dass Sie nicht zuverlässig wissen können, was passieren wird, wenn Sie sich nur den Code ansehen.

Normalerweise führt dies, wie bei vielen, aber nicht allen Denial-of-Service-Schwachstellen, dazu in einem "Absturz". Hier sind einige Möglichkeiten, was Sie ausnutzen können, wenn ein Programm abnormal beendet wird:

• Es könnte einem anderen Programm ermöglichen, dieselben Ressourcen wie das erste (wie ein Port) zu verwenden und so zu tun, als wäre es dasselbe Programm
• Absturz kann alle vom Programm verwendeten Bereinigungsvorgänge umgehen, die ausgenutzt werden könnten.
• Wenn der Exit-Code des Programms in einem anderen Programm verwendet wird, das das Signal nicht überprüft Der Status der PID des untergeordneten Prozesses könnte bedeuten, dass das Programm einen Fehlercode zurückgegeben hat. Auf meinem Linux-Computer setzen die folgenden beiden Programme beispielsweise $? (die Variable, die in Shell-Skripten zur Darstellung des Rückkehrcodes des vorherigen Befehls verwendet wird) auf 136 : int main (int argc, char ** argv) {return 1 / (argc - 1); } und int main () {return 136; }
• Abstürze können zu Coredumps führen, die geschützten Speicher wie Sicherheitsschlüssel, Kennwörter und das Rezept für Coca-Cola enthalten können.

Aufgrund von Optimierungen kann der Compiler außerdem davon ausgehen, dass der Divisor niemals 0 sein kann, und möglicherweise Code optimieren, den Sie möglicherweise nicht berücksichtigt haben. Dies gilt nur für kompilierte Sprachen wie C und C ++, die ein undefiniertes Verhalten (oder ein gleichwertiges Verhalten) für die Division durch Null aufweisen. Ich konnte keinen optimierten Code erstellen, der dies anhand der Beispiele in einigen anderen Antworten in clang oder gcc tut, aber nichts hindert sie oder andere Compiler daran, dies in der Vergangenheit oder Zukunft zu tun.

Hier ist ein Beispiel, wo es einen Unterschied machen könnte.

Es ist zu 100% erfunden - aber viele Klassen von Exploits werden durch theoretische "erfundene" Beispiele identifiziert, bis bestimmte Beispiele gefunden werden.

Es handelt sich um Pseudocode.

  Versuch: Ermitteln Sie die durchschnittliche CPU-Auslastung pro angemeldetem Benutzer, wenn dieser Durchschnitt zu hoch ist, und teilen Sie der angemeldeten Person mit, dass wir beschäftigt sind. Anmeldeinformationen abrufen Überprüfen Sie die Anmeldeinformationen, wenn die Anmeldeinformationen ungültig sind, und weisen Sie sie an, den Zugriff für diese Sitzung auf den korrekten Zugriff für diesen Benutzer zu beschränken, wenn eine Ausnahme vorliegt: Führen Sie nichts in  

In aus In diesem Fall wird die durchschnittliche CPU pro angemeldetem Benutzer möglicherweise als "Gesamt-CPU / Anzahl der angemeldeten Benutzer" berechnet. Wenn keine angemeldeten Benutzer vorhanden sind, wird "durch 0 teilen" angezeigt und es wird direkt zum "Wenn vorhanden" übersprungen ist eine Ausnahme "-Klausel. Dies umfasst das Einschränken des Zugriffs - die neue Sitzung hat möglicherweise Zugriff, der dem zuletzt angemeldeten Benutzer entspricht, oder unbegrenzten Zugriff.

Während in diesem Beispiel der gesamte Code zusammen angezeigt wird, ruft Ihr Hauptcode häufig etwas auf, das etwas aufruft Andernfalls können die beiden interagierenden Aspekte (in diesem Fall die Division durch 0 und die Tatsache, dass die Ausnahme ignoriert wird) in Teilen des Codes ausgeführt werden, die weit voneinander entfernt sind.

Wie viele Leute bereits erwähnt haben, ist die Division durch Null (allein) kein oder gar kein Sicherheitsfehler. Soweit mir bekannt ist, haben die meisten (vielleicht alle!) Programmiersprachen klar dokumentierte Informationen darüber, was passiert, wenn durch Null geteilt wird. Ich denke, so ziemlich jede Sprache, die Ausnahmen hat, hat eine Ausnahme für die Division durch Null (ich habe gesehen, dass ein mechanischer Taschenrechner in einer Endlosschleife steckt).

Hier gibt es einige sehr spezifische Antworten. Ich würde zustimmen, dass eine (nicht behandelte) Division durch Null in erster Linie ein funktionales Problem ist - aber das bedeutet nicht, dass es nicht als Sicherheitsproblem ausgenutzt werden kann. In der Tat gibt es so viele Fehler, die ausgenutzt werden können. Die Klassifizierung von "funktional" gegenüber "Sicherheit" bei Anwendung auf Fehler erscheint etwas sinnlos.

Sie schließen eine Kategorie von Sicherheitsproblemen (DOS) ab, ohne darüber zu diskutieren was Sie hier als außerhalb des Geltungsbereichs liegend betrachten. Das offensichtlichste Szenario ist, dass das Auslösen des Fehlers dazu führt, dass die Instanz des Programms gestoppt wird. Es gibt jedoch subtilere Effekte: Wenn dadurch große Datenmengen in das Dateisystem geschrieben werden (z. B. ein Core-Dump), bietet sich eine Möglichkeit für einen zweiten DOS-Typ, indem das Dateisystem gefüllt wird.

Jefrey erwähnt die Offenlegung für eine PHP-Anwendung - aber Fehlermeldungen, Protokolle und Core-Dumps bieten Menschen, die versuchen, Informationen zu extrahieren, auf die sie keinen Zugriff haben sollten, aus Programmen, die in einer beliebigen Sprache geschrieben sind Das Beenden des Programms führt zu einer Reaktion. Ein Angreifer hat dann die Möglichkeit, ein bestimmtes Programm zu einem Zeitpunkt seiner Wahl auszulösen. Er hat eine gewisse Kontrolle darüber, was Ihr System tut, was eine Eskalation von Angriffen / Berechtigungen erleichtern kann.

Auch wenn das Steuerungssystem manuell ist, gibt es immer noch einen Übergangszustand für das System, in dem das Sicherheitsverhalten weniger genau definiert ist und in dem Assets wie Passphrasen, Passwörter und private Schlüssel im Flug sind.