ClickCease Bugs hinter den Schwachstellen - Teil

Inhaltsübersicht

Abonnieren Sie unseren beliebten Newsletter

Schließen Sie sich 4.500+ Linux- und Open-Source-Experten an!

2x im Monat. Kein Spam.

Die Bugs hinter den Schwachstellen - Teil 1

Joao Correia

31. Oktober 2022 - Technischer Evangelist

Es ist üblich, von neuen Schwachstellen und Exploits zu hören, von denen einige sogar eigene Namen bekommen, aber manchmal sind die Details, wie sie auftreten, unter Proof-of-Concept-Code und Impact Scores begraben. 

Diese Artikelserie wird diese versteckten Fehler entmystifizieren, indem sie einen Einblick in die tatsächlichen Code-Probleme gibt, die den meisten Sicherheitsschwachstellen zugrunde liegen, die Systeme überall betreffen. 

Wir könnten die einzelnen Codefehler in beliebiger Reihenfolge durchgehen. Aber Mitre hat eine Liste eine Liste der 25 gefährlichsten Bugs im Jahr 2022 veröffentlicht, und diese Liste ist so gut wie jede andere, also werden wir sie durchgehen - und erklären, wie Codeprobleme zu jedem dieser Bugs führen, und auf einige Schwachstellen hinweisen, die aus dem Vorhandensein solchen Codes in einer Anwendung entstehen.

In diesem ersten Teil der Serie betrachten wir die Einträge 25 bis 21 der Top 25 der gefährlichsten Bugs des Jahres 2022, die von Mitre ermittelt wurden.

25 - Unzulässige Kontrolle der Code-Erzeugung ('Code Injection')

Dies ist ein häufiges Problem, bei dem der Programmierer keinen ausreichenden Schutzcode für die vom Benutzer eingegebenen Daten bereitstellt, d. h. die Software verwendet alle Eingaben, die sie erhält, ohne sie zu bereinigen, und verwendet diese Eingaben dann unverändert für die internen Funktionen.

Auf einer sehr niedrigen Ebene können speziell angefertigte Eingaben die Funktionsweise des Programms auf unvorhergesehene Weise verändern und dem Benutzer mehr Kontrolle über das Programm und in manchen Fällen über das gesamte System geben.

Dies führt zu Situationen, in denen Eingaben sorgfältig konstruiert werden, um unerwünschte Nebeneffekte wie Datenverfälschungen oder unbeabsichtigte Änderungen des Programmablaufs hervorzurufen.

Ein sehr häufiger Spezialfall dieser Art von Fehlern ist die "SQL-Injektion", die eine eigene Kategorie weiter vorne in dieser Artikelserie verdient, aber nichts anderes als ein Spezialfall der Code-Injektion ist.

So ist beispielsweise die Verwendung von "eval()" in PHP häufig ein Code-"Geruch", der auf eine mögliche Code-Injection-Situation hinweist, wenn der übergebene Wert zuvor nicht ordnungsgemäß validiert wird.

24 - Unzulässige Einschränkung des Verweises auf externe XML-Entitäten

XML-Dateien können als Teil ihrer Struktur Verweise auf externe Dokumente enthalten, was jedoch dazu führen kann, dass eine Anwendung Dokumente außerhalb des vorgesehenen Bereichs lädt. Dies kann zu Problemen bei der Pfadüberquerung, unsachgemäßen Dateizugriffen oder falschen Daten führen, die von der Anwendung als gut angesehen werden.

Dies gilt für URIs (Unique Resource Identifiers), die auf andere lokale Dateien oder sogar auf Dateien im Internet verweisen, indem file:// oder http:// URIs verwendet werden.

Sie ermöglicht nicht nur den Zugriff auf sonst unerreichbare Dateien, sondern kann auch dazu verwendet werden, die Anwendung zu zwingen, übermäßige Datenmengen zu verarbeiten, indem sie mit unerwartet großen Dokumenten gefüttert wird, wodurch sie verlangsamt wird oder solche Anwendungen sogar nicht mehr reagieren.

Wenn die Anwendung keinen Schutz dagegen bietet, ist es möglich, ein System auszunutzen, indem eine XML-Datei wie diese erstellt wird:


<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>

<stockCheck>

<productId>&xxe;</productId>

</stockCheck>

Und dann das Ergebnis zu beobachten.

[Dieses Beispiel stammt von https://portswigger.net/web-security/xxe..]

Wenn der Zielserver in der Lage ist, auf andere interne Systeme zuzugreifen, auf die ein Angreifer normalerweise nicht zugreifen könnte, dann könnte dieser Fehler als Sprungbrett genutzt werden, um Informationen von diesen Systemen zu erhalten.

Fehler 23 - Unkontrollierter Ressourcenverbrauch

Alle Ressourcen, die einer Anwendung zur Verfügung stehen, sind begrenzt: Verarbeitungsleistung, Speicherplatz, Netzwerkbandbreite, Speicherkapazität, Datenbankverbindungen usw. 

Wenn die Anwendung dazu verleitet werden kann, eine oder mehrere dieser Ressourcen zu missbrauchen, kann sie diese erschöpfen und die Anwendung oder in manchen Fällen das gesamte System als nicht ansprechbar oder sogar unbrauchbar erscheinen lassen.

Er kann im Code als rechenintensive Funktionen auftreten, die nicht vor wiederholten Aufrufen geschützt sind (während frühere Aufrufe noch nicht abgeschlossen sind), oder sogar als Funktionen, die eine unverhältnismäßig große Menge an Daten aus sehr kleinen Eingaben erzeugen (z.B. komplexe Fehlermeldungen aus einzelnen Zeichenfehlern), was beides potentielle Quellen für diese Art von Fehler sind.

Eine weitere häufige Manifestation dieses Fehlers ist, wenn eine Anwendung die ihr zugewiesenen Ressourcen nicht entsorgt, was zu Out-of-Memory-Fehlern oder Ähnlichem führt.

Dies ist eine besonders ungeheuerliche Art von Fehler, der oft schwer zu diagnostizieren ist, bevor eine Anwendung das Produktionsstadium erreicht - oder aufgrund unsachgemäßer Tests - und der eine Anwendung in einen abgestürzten oder noch schlimmeren, unerwarteten Zustand versetzen kann.

Die meisten statischen Code-Analyse-Tools verfügen über Prüfungen, um diese Art von Situation zu erkennen, aber da Code auf viele verschiedene Arten geschrieben werden kann, ist es immer möglich, einen so verschlungenen Code zu haben, dass diese Analyse-Tools ihn nicht erkennen können.

Fehler 22 - Gleichzeitige Ausführung unter Verwendung gemeinsam genutzter Ressourcen mit unsachgemäßer Synchronisierung ("Race Condition")

Wenn mehrere Anwendungen versuchen, dieselbe Ressource zu nutzen, oder sogar mehrere Threads innerhalb derselben Anwendung, muss eine Form der Koordinierung stattfinden, um sicherzustellen, dass jeder den Zugriff hat, den er braucht, solange er ihn braucht. 

Andernfalls kann es zu Situationen kommen, in denen eine Anwendung gleichzeitig mit einer anderen Anwendung beginnt, in eine Datei zu schreiben, und am Ende haben Sie entweder eine Mischung aus den Inhalten, die in der Datei enthalten sein sollten, nur die Inhalte einer der Anwendungen oder sogar nur eine leere Datei.

Da diese Art von Situation sehr belastungsabhängig ist, ist es auch schwierig, sie zu reproduzieren und adäquat zu identifizieren.

Es kann jede Art von Ressource betreffen, nicht nur Dateien. Es kann sich beispielsweise auf In-Memory-Daten, Netzwerke und Datenbanken auswirken - und zwar so sehr, dass im Laufe der Zeit viele sprachspezifische Konstrukte hinzugefügt wurden, um dieser Situation zu begegnen, mit dem Ziel, eine Zugriffsart zu schaffen, die als "atomar" bezeichnet wird und bei der garantiert ist, dass sie vollständig oder überhaupt nicht erfolgt, so dass keine teilweisen Lese-/Schreibvorgänge auftreten.

Etwas so Einfaches wie das Erhöhen eines Variablenwerts (x++) ist tatsächlich anfällig für diese Art von Problemen, da der eigentliche Vorgang in mehrere Operationen auf Maschinenebene aufgeteilt ist (Lesen des ursprünglichen Werts von x, Erhöhen desselben, Zuweisen des neuen Werts zurück zu x). Wenn x eine Variable wäre, die von mehreren Threads innerhalb einer Anwendung gemeinsam genutzt wird, könnte dies zu Fehlern führen, wenn mehrere Threads versuchen, den Wert gleichzeitig zu erhöhen.

Sprachkonstrukte wie Mutexe, Semaphoren und andere Thread-Synchronisationsmechanismen wurden speziell zur Lösung dieser Art von Problemen eingeführt. Angesichts der Häufigkeit von Sicherheitslücken, die auf diese Art von Fehlern zurückzuführen sind, ist die erfolgreiche Implementierung solcher Konstrukte möglicherweise nicht ideal.

Fehler 21 - Server-Side Request Forgery (SSRF)

Server können dazu gebracht werden, Antworten auf Anfragen an andere Ziele als die ursprüngliche Adresse des Anfragenden zu senden.

Wie bereits in Fehler #24 beschrieben, ist es möglich, eine Anwendung auf andere Inhalte zugreifen zu lassen, indem URIs in speziell gestaltete XML-Dateien eingefügt werden. Wenn sich diese Dateien an einem fremden Ort befinden, scheint die Anfrage von dem Server zu kommen, der die XML-Datei verarbeitet, und nicht vom System des Angreifers. Dies ist zwar nicht der einzige Fehler, der in diese Kategorie fällt, aber ein eindeutiges Beispiel dafür, wie ein Server bzw. eine Anwendung dazu gebracht wird, eine Verbindung mit einem fremden System herzustellen.

Jede Eingabe, die eine Liste von URIs enthalten kann, die nicht ordnungsgemäß validiert sind, kann als SSRF-Mechanismus verwendet werden. 

Zum Beispiel kann das M3U-Dateiformat kann Verweise auf externe Dateien enthalten. Bei einem Webdienst für die Videokodierung, der eine M3U-Datei als Inhaltsliste akzeptiert, wäre es möglich, einen Verweis auf Systemdateien einzuschließen, auf die ansonsten nicht zugegriffen werden kann, und diese als Teil der Ausgabe des Webdienstes einzuschließen.

Zusammenfassung
Die Bugs hinter den Schwachstellen - Teil 1
Artikel Name
Die Bugs hinter den Schwachstellen - Teil 1
Beschreibung
Von neuen Sicherheitslücken hört man häufig, aber manchmal sind die Details, wie sie entstehen, verborgen. Lassen Sie uns diese versteckten Bugs entmystifizieren. 
Autor
Name des Herausgebers
Tuxcare
Logo des Herausgebers

Möchten Sie das Patchen von Sicherheitslücken ohne Kernel-Neustart, Systemausfallzeiten oder geplante Wartungsfenster automatisieren?

Erfahren Sie mehr über Live-Patching mit TuxCare

Werden Sie ein TuxCare-Gastautor

Los geht's

E-Mail

Beitreten

4,500

Linux & Open Source
Fachleute!

Abonnieren Sie
unseren Newsletter