Samstag, 1. Mai 2010


Topthema

Donnerstag, 26. März 2009 | Topthema

About Security #197: Schwachstellen-Suche: Pufferüberläufe verhindern

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/048020)

In About Security #196 wurden die Testeingaben für die Suche nach Pufferüberlauf-Schwachstellen beschrieben, in dieser Folge erfahren Sie, worauf Sie bei der Auswertung der Ausgaben achten müssen und wie Angriffe über Pufferüberlauf-Schwachstellen verhindert werden können.

Pufferüberlauf-Schwachstellen finden

Nach jeder präparierten Eingabe wird die Ausgabe der Webanwendung auf auffällige Zeichen hin überprüft. Da der Pufferüberlauf meist erst gegen Ende der Verarbeitungskette erfolgt, wird eine Fehlermeldung der betroffenen Komponente sehr wahrscheinlich von der Webanwendung ausgewertet und nicht unbedingt direkt ausgegeben.

Verdächtig sind der HTTP-Statuscode 500 sowie alle Fehlermeldungen, die bei Eingabe normallanger falscher Eingaben nicht auftreten. Mit etwas Glück reicht die Webanwendung die Fehlermeldung auch unverändert weiter, so das zusammen mit der Meldung der Webanwendung eine informative Fehlermeldung erscheint. Auch unvollständige oder fehlerhafte Antworten des Servers können auf einen Pufferüberlauf hinweisen, ebenso wie ein plötzlicher Abbruch der TCP-Verbindung oder das komplette Einfrieren der Webanwendung.

Falls eine Off-by-one-Schwachstelle vorhanden ist, kommt es evtl. statt zu einem Absturz zu einem unerwarteten Verhalten der Webanwendung, wie z.B. der Ausgabe unerwarteter oder zusätzlicher Daten.

Kommt es in Folge eines Pufferüberlaufs zu einem Absturz oder allgemein einen Fehler, muss das nicht zwingend sofort nach der Eingabe des betroffenen Parameters passieren. Evtl. sind daher mehrere Versuche nötig, um den betroffenen Parameter zu ermitteln.

Knapp daneben...

In manchen Fällen werden die Testeingaben von Eingabeprüfungen der Webanwendung oder anderer Komponenten wie z.B. des Webservers vor dem Erreichen des eigentlichen Ziels gestoppt. Zum Beispiel kann die Eingabe für einen GET-Parameter an der Längenbeschränkung für URLs scheitern, die oft um 2048 Zeichen liegt. Dann ist zu prüfen, wie lang die URL genau werden darf und ob sich evtl. darin ein ausreichend langer Wert übertragen lässt. Evtl. kann auch ein Wechsel der Kodierung beim Angriff helfen: Beim Umkodieren von z.B. ASCII nach HTML-Entities zur Verhinderung von Cross-Site-Scripting oder SQL-Injection wird z.B. aus einem < ein &lt; und aus einem " ein &quot; und die Eingabe dadurch entsprechend länger. Eine weitere Möglichkeit eine Längenbegrenzung für die URL zu umgehen, ist das Ausweichen auf POST-Parameter. Manche Webanwendungen unterscheiden nicht zwischen über GET und über POST übertragenen Parametern.

Auch andere Eingabeprüfungen müssen ggf. berücksichtigt werden. Zum Beispiel könnte die Webanwendung prüfen, ob ein Wert für einen Namen nur Alphanumerischen Zeichen enthält oder ob in einer E-Mail-Adresse das @-Zeichen und mindestens ein Punkt vorkommen usw.. Dann muss auch die überlange Eingabe diesen Anforderungen entsprechen, damit sie überhaupt an den kompilierten Teil der Anwendung weitergeleitet wird. Am einfachsten lässt sich das erreichen, indem eine normale, von der Anwendung akzeptierte Eingabe entsprechend erweitert wird.

Schwachstelle gefunden - was nun?

Das eine Pufferüberlauf-Schwachstelle gefunden wurde ist nicht gleichbedeutend damit, das sie auch ausgenutzt werden kann. Das quasi "blinde" Ausnutzen einer Pufferüberlauf-Schwachstelle ist ganz im Gegenteil sehr schwierig. Da sie aber auf jedem Fall für einen DoS-Angriff ausgenutzt werden kann, muss sie sowieso behoben werden, Ausnutzbarkeit hin oder her. Dafür stehen in diesem Fall drei Möglichkeiten zur Verfügung, die sich je nach Umgebung auch kombinieren lassen.

About Security: Alle Folgen

Am sichersten ist die Korrektur der Schwachstelle in der betroffenen Komponente. Liegt deren Quelltext vor, kann die Schwachstelle darin behoben und das Programm danach, ggf. mit entsprechenden Compilereinstellungen zum Schutz vor Pufferüberläufen, neu kompiliert werden, siehe About Security #7 und #8.

Ist das Beheben der Pufferüberlauf-Schwachstelle in der betroffenen Komponente nicht möglich, z.B. weil es eine zugekaufte Komponente ist oder der Quelltext eines alten Programms nicht mehr vorhanden ist, muss die Webanwendung den Schutz der Komponente übernehmen. So, wie z.B. Cross-Site-Scripting- oder SQL-Injection-Angriffe durch das Prüfen und ggf. Filtern der Eingaben verhindert werden, wird dann das Ausnutzen der weiterhin vorhandenen Pufferüberlauf-Schwachstelle durch das Prüfen und ggf. Filtern der Eingaben verhindert. Da dabei gezielt bestimmte Parameter auf deren jeweils maximal zulässige Länge geprüft werden, kann die Prüfung auch nicht wie oben beschrieben umgangen werden. Ob überlange Parameter verworfen oder passend gekürzt werden ist dabei Geschmacksache. Ich empfehle, den Parameter zu verwerfen, da sowieso ein falsches Ergebnis geliefert würde, egal ob es sich um einen Angriff oder eine versehentliche Falscheingabe handelt.

Die dritte Möglichkeit kommt besonders dann zum Zuge, wenn auch die Webanwendung nicht geändert werden kann: Die Parameter werden von einer Webapplication-Firewall auf die korrekte Länge geprüft und zu lange Eingaben von der Webanwendung ferngehalten. Webapplication-Firewalls werden in zukünftigen Folgen von About Security beschrieben, in der nächsten Folge geht es um die Suche nach Integer-Schwachstellen.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

Kommentare

Folgende Links könnten Sie auch interessieren