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

»priviligierte Ports« definiert wurden, und alle Dämonen mit Supervisor-Rechten starten
mußten. Vielfach wurden diese Restriktionen aufgeweicht, und inzwischen ist es möglich,
daß Dämonen mit minimalen Rechten als User auf den privilegierten Ports laufen.
Wrapper können den Zugriff für bestimmte IP - Nummern sperren, und Dämonen mit
Userrechten starten. Betrachtet man z.B den »smapd«, einem Wrapper aus dem TIS
FWTK, der sich zwischen Kernel und Mailerdämon setzt, so basiert dieser auf einem
klaren Konzept: Der »smapd« läuft zwar mit Administratorrechten, ist aber so klein und
übersichtlich, daß es möglich war, diesen sicher zu programmieren. Er nimmt die Daten
entgegen und leitet diese an einen Mailer-Dämon weiter, der dann »nur« mit minimalen
Rechten läuft. Gelingt einem Angreifer ein »buffer overflow«, so ist es möglich, daß
Programme mit minimalen Userrechten gestartet werden. Man geht dabei davon aus, daß
ein User auf einem UNIX-Betriebssystem keinen Schaden anrichten kann. Auch ist das
Starten eines Netzwerksniffers mit Userrechten nicht so einfach möglich, da hierzu Zugriff
auf RAW SOCKETS erforderlich ist. Diese Möglichkeit ist aber nur dem »root« User
zugestanden. Nun lehrte die Erfahrung, daß es sehr wohl möglich ist, mit Tricks sich vom
User zum Superuser zu befördern. Das gelingt durch Ausnutzung einiger der vielen
internen Fehler von UNIX. Kein Hersteller hat es inzwischen geschafft, diese Probleme
zuverlässig in den Griff zu bekommen. Die chroot() Umgebung begrenzt
Dateizugriffsrechte auf ein Unterverzeichnis. Der Zugriff auf übergeordnete Verzeichnisse
bleibt verwehrt. So erhoffte man sich, daß wenn ein Dämon, der mit minimalen
Userrechten in einer »chroot()« Umgebung gestartet wird, daß ein Angreifer höchstens in
einem begrenzten Bereich und mit minimalen Rechten sein Unwesen treiben kann. Diese
Maßnahmen haben sich hervorragend bewährt, und halten die allermeisten erfahrenen
Angreifer schon fern. Einige findige Experten haben auch dagegen ein Mittel gefunden:
Sie kopieren den Befehl »mknod«, »mkfifo« und »mount« in die »chroot()« Umgebung
hinein, legen das Device, z.B. /dev/kmem an, welches der aktiven Festplatte entspricht
und »mounten« dieses. Dieses ist das RUNTIME- Abbild des Systemkernels in das
Filesystem eingeblendet. Mit einem Editor und Suchfunktionen kann man so nach
unverschlüsselten Paßworten im gesamten RAM-Bereich suchen lassen. Dieser Trick
funktioniert neben UNIX auch unter NT. In anderen Fällen war es möglich, bestimmte
Dämonen durch einen DoS Angriff »abzuschießen« und statt dessen ihren eigenen zu
starten, der Paßworte genau dann entführt, wenn jemand mit gültigem Paßwort sich
authentifiziert. Mit diesen können sich Angreifer von außerhalb normal einloggen. Es soll
aber nicht verschwiegen werden, daß diese Tricks nur unter LINUX gut dokumentiert sind.
Entscheidend für die Wirksamkeit dieser Maßnahmen sind die Sicherheitsmechanismen
des Kernels, und hier gibt es gravierende Unterschiede. FreeBSD, OpenBSD und NetBSD
besitzen (in den neuesten Versionen) einen äußerst restriktiven Sicherheitsmechanismus.
So können z.B. einfache User niemals Supervisorrechte erlangen. Es ist auch nicht
selbstverständlich, daß ein Administrator-Account beliebig Zugriff auf Logfiles hat. Erreicht
wurde dieses u.a. dadurch, daß erweiterte Rechte eingeführt wurden, z.B »append only« -
Files. D.h auch wenn jemand Administrator - Rechte besitzt, kann er niemals Logfiles
verändern, oder Paßworte verändern. Er könnte jedoch ohne Probleme weitere Accounts
hinzufügen, jedoch keine löschen. Ohne diese Sicherheits -Mechanismen ist ein Dämon,
der in einer chroot() Umgebung und mit nur minimalen Userrechten läuft, ein
Sicherheitsrisiko. Das betrifft insbesondere LINUX - Server. Bei anderen
Betriebssystemen sind diese Eigenschaften in den jeweiligen »trusted« Varianten der
Betriebssysteme bekannt (Trusted Solaris, Trusted Xenix....) Diese verfügen neben diesen
Eigenschaften auch über erweiterte Logging-Funktionen. Unter NT 3.50 (nicht 3.51 oder
4.0) existiert eine C2-Zertifizierung. Diese hat keinen Aussagewert bezüglich möglicher
»buffer overflows«
Wieviele buffer overflows können in einem Programm auftreten?
Genaugenommen liegt es an der Sorgfalt der Programmierer, überlange Strings bei der
Übergabe von Daten heraus zu filtern. Man darf aber nicht vergessen, daß schon ein
einfacher Dienst (pop3) eine größere Zahl von Befehlen unterstützt. Die veröffentlichten
exploits beziehen sich immer nur auf einen Befehl. Wie bei dem qpopper passiert, wurde
kurz nachdem QUALCOMM das Problem beseitigt hatte, ein neuer exploit veröffentlicht.
Es ist unbedingt damit zu rechnen, daß stets neue buffer overflows entdeckt werden. Da
einige Dämonen auch Informationen an andere weiterleiten (DNS oder POP3 an
MAILSERVER), so ist es auch möglich, daß eingeschleuste Informationen, z.B. im Mail-
Erstellt von Doc Gonzo - http://kickme.to/plugins