Firewall Handbuch für LINUX 2.0 und 2.2 - zurück

22.7 Warum Filter anfällig gegen buffer overflows sind
Das folgende Beispiel stammt von Eric Dumazet und findet sich auf
ftp://ftp.ris.fr/pub/linux/proxy/. Es ist ein Beispiel für einen Proxy, wie man ihn auf vielen
Firewalls implementiert finden kann. Viele Firewall - Hersteller benutzen oft Code aus dem
Internet, um Ihrer Firewall noch ein paar spezielle Protokolle, hier einem VDO Proxy,
hinzuzufügen. Dies ist nicht der in dem LINUX Kernel implementierte Proxy, sondern
einer, der auf jedem UNIX einfach zu installieren ist. Der Autor hat auch einen
transparenten HTTPD-PROXY geschrieben, der auch auf o.a. URL zu finden ist. Das
Problem mit diesem Proxy ist folgendes. Es fehlen überall Begrenzungen für die maximal
zulässige Länge der Übergabeparameter. Um feststellen zu können, welche Daten von wo
aus an den Filter übergeben werden, muß man eine vollständige Flußanalyse des (hier
noch überschaubaren Programmes) durchführen. Es müssen also folgende Fragen geklärt
werden. Ein einziger Fehler im Quellcode ist bereits für einen Angreifer ausreichend, um in
das Netzwerk hinter dem Proxy vorzudringen. Wo ist der Fehler ?:
• Werden ARGC() ARGV() abgefangen ?
• Wie fordern die Unterroutinen in stdio, netdb, netinet u.s.w Speicher an
(malloc, realloc, vmalloc). Welche Routinen sind buffer overflow gefährdet ?
• Welche Arrays sind statisch angelegt, welche Informationen können dort
hineingeschrieben werden ? Ist ein buffer overflow möglich ?
• Werden unzulässig Lange Strings vor dem Speichern in statische Arrays auf
Überlänge abgefragt ? Wo ist ein Beispiel im Code ?
• Welche Pointer auf Arrays oder Funktionen können mit unzulässigen Werten
gefüllt werden. Wo werden diese Werte auf Zulässigkeit untersucht ?
• Welche Fehlermeldungen werden an den SYSLOGD oder KLOGD bei
welchen Fehlern übergeben ? Welche Fehler können vom
Systemadministrator entdeckt werden ?
• Nach welchem Mechanismus arbeitet der VDO Proxy ? Welche Ports
(TCP/UDP) sind zu welchem Zeitpunkt geöffnet, welche bleiben unnötig lange
geöffnet ? Welche TCP Ports bleiben offen ? Welche Angriffe sind möglich ?
• Welche Ports werden nach Absprache mit dem VDO Video-Server im Internet
in der Firewall bzw. in dem Proxy geöffnet ? Ist der Proxy manipulierbar
dahingehend, daß eventuell die Firewall auch für andere Protokolle
transparent wird ?
• Wieviel Speicher verbraucht der Proxy in Abhängigkeit der Zahl der Video
Datenströme ? Ist ein DoS möglich ?
• Wie fängt der Proxy Spoofing Angriffe ab ? Wird ein double reverse lookup
durchgeführt ?
• Wird der IDENTD mit aktiviert ? Welche Informationen könnte dieser liefern ?
• Kann man den Proxy mit einem TCP Wrapper betreiben ?
• Kann der PROXY in einer CHROOT() Umgebung gestartet werden ?
• Was passiert, wenn der das Format der Videodaten plötzlich verändert wird.
Kann sich der Eingangspuffer dynamisch anpassen, oder ist ein buffer
overflow möglich ?
• Können Funktionen, wie strcpy() mit unzulässigen Werten aufgerufen werden
(altes strcpy() Pointer Problem) ?
• Ist die Library gefixt ?
• Gibt es Parameter, die bei Übergabe an den PROXY diesen Killen (DoS) ?
• Wieviele gleichzeitige Video Datenströme verträgt der PROXY ?
Wer sich intensiver mit dieser Materie auseinandersetzt, wird beim Lesen dieses Artikels
über sicheres Programmieren unter UNIX, siehe http://www.whitefang.com/sup/securefaq.html,
daß viele Programme unter LINUX weit davon entfernt sind, sicher zu sein....
Für C-Spezialisten hier nun der vollständige Quellcode, der, bevor er auf einer Firewall
eingesetzt werden kann, nach obigen Punkten abgesucht werden sollte. Wie schwer
Erstellt von Doc Gonzo - http://kickme.to/plugins