Zwei Trends haben in den letzten Jahren das Mainframe-Umfeld bestimmt: Zum einen ist es IBM gelungen, mit dem Aufbau einer Unix-Umgebung neben MVS und dem Einsatz von TCP/IP neben SNA den Host neu zu positionieren und für moderne Anwendungen zu öffnen. Viele Unternehmen verlagern mittlerweile Anwendungen, mit denen seinerzeit Unix in den Rechenzentren Einzug hielt, auf den guten alten Host, vor allem aus Skalierbarkeits- und Verfügbarkeitsgründen. Dies betrifft nicht nur Backend-Prozesse wie Datenbankserver, sondern auch die Applikations- und Webserver moderner verteilter Anwendungssysteme. Hierbei wird der Host – manchmal nahezu unbemerkt – zum extern über IP erreichbaren System, sei es im Extranet einer Firma oder sogar als Internet-Server.
Der zweite Trend ist neuer und noch revolutionärer: der Einsatz von Linux als Betriebssystem am Host. Und dies nicht nur für "Spielereien", sondern selbst große Umgebungen sind bereits dabei, zentrale Prozesse auf diese Plattform zu migrieren. Sicher am weitesten fortgeschritten ist dabei der Einsatz als Grundlage von SAP-Applikationsservern.
Für beide Umgebungen stellt sich die Frage, inwieweit die von alters her unterstellte Host-Security eigentlich noch trägt. Waren nicht Unix, Linux und gerade IP Begriffe aus einer Welt, gegen die man sich lange – auch mit dem Argument "Sicherheit" – abgegrenzt hatte? Auf der anderen Seite handelte es sich dabei womöglich schon immer um eine trügerische Sicherheit: Bereits Anfang 2000 wusste ein <kes>-Beitrag von gravierenden Schwachstellen bei Sicherheits-Checks von 350 Systemen unter OS/390 zu berichten (online unter www.kes.info/archiv/mainframe2000.html). In 100 % der Fälle konnten die Tester sich damals die höchste Autorisierungsstufe erschleichen: Die Ursachen lagen zu 80 % bei der Software-Industrie und den in Unternehmen erstellten Programmen.
War es IBM gelungen mit der Unix- und IP-Implementierung auf der S/390-Plattform deutlich besser zu sein? Macht die Plattform mit ihren Sicherheitsparametern auch Linux weniger anfällig? GAI NetConsult hat die Auswirkung typischer Programmierfehler, die im klassischen Unix-Umfeld zu Angriffsmöglichkeiten führt, auch im Host-Umfeld genauer unter die Lupe genommen. Dabei wurde neben einem System unter z/OS (V1R2) auch ein zLinux-System (Distribution SuSe SLES 7) untersucht. Zudem ließen sich Rückschlüsse auf die jeweiligen 31- bzw. 32-Bit-Vorgänger OS/390 und Linux for S/390 ziehen.
Bei der Frage nach der prinzipiellen Angreifbarkeit durch klassische Unix-Schwachstellen beschränkte man sich auf den Bereich Buffer-Overflow-und Format-String-Attacken, der bei weitem den größten Teil der Sicherheitsprobleme im Unix-Bereich ausmacht (vgl. <kes> 2002#5, S. 10 und <kes> 2001#5, S. 6).
Um die Angreifbarkeit eines Hosts zu ergründen, wurde zunächst auf dem System ein in C geschriebenes Programm gestartet und während der Ausführung im Debugger analysiert. Dabei wurde das gesamte Memory-Management des Systems untersucht, unter anderem die Anordnung und Adressierung der einzelnen Memory-Segmente eines Prozesses. Für mögliche Manipulationen von außen ist wichtig, welche Zugriffsschutzmechanismen auf den Memory-Bereichen des Prozesses implementiert sind. Beispielsweise sollte der Programmcode schreibgeschützt sein und eine Ausführung von Code im Stackbereich unterbunden werden. Diesbezügliche Tests sollten herausfinden, über welchen Memory-Bereich Einschleusen und Ausführen von Code prinzipiell möglich wäre.
In einem zweiten Schritt wurden in das C-Programm typische Programmierfehler eingebaut, die zu Buffer-Overflow- und Format-String-Schwachstellen führen, wie sie in der Vergangenheit in vielen Unix-Programmen auftraten. Von einem Testsystem aus wurden Angriffe gegen diese Schwachstellen versucht und die Reaktionen des Systems beobachtet.
Sofern ein prinzipieller Weg zur Ausnutzung von Buffer-Overflow- und Format-String-Schwachstellen vorhanden war, wurde im dritten Schritt versucht, gezielt "bösartigen" Code zu entwickeln, der dem Angreifer beispielsweise einen Kommandozeilenzugriff auf das System bietet (Shellcode). Da dieser Code in Assembler geschrieben werden muss, war dabei auch die Frage relevant, ob Angreifer Techniken aus dem weithin bekannten Unix- und Intel-Bereich verwenden können.
Aufgrund dieser Eigenschaften ist davon auszugehen, dass ein großer Teil der Buffer-Overflow- und Format-String-Attacken der Vergangenheit auch am Host erfolgreich ausnutzbar gewesen wäre (entsprechende Fehler im eingesetzten Code vorausgesetzt).
In der zweiten Phase wurde versucht, einen am Host ablaufenden Serverprozess mit einer präparierten Schwachstelle von einem externen Testrechner tatsächlich anzugreifen. Bei der Schwachstelle handelte es sich um einen typischen Programmierfehler, der einen string-basierten Buffer Overflow ermöglicht. Da das fehlerhafte Programm im 31-Bit-Modus ablief, bestand das Hauptproblem beim Einschleusen von Code im Stack-Wachstum hin zu höheren Adressen. Dies konnte mit Techniken, wie sie aus dem Bereich HP/UX bekannt sind, überwunden werden, sodass der Test letztlich erfolgreich ablief. Das System zeigte zum Zeitpunkt der Einschleusung des Codes von außen keinerlei Warn-Meldungen oder besonderer Reaktionen auf den "fremden" Code.
Bei dem testweise eingeschleusten Code handelte es sich zunächst lediglich um eine einfache Schleife, die die reguläre Abarbeitung des fehlerhaften Programms unterbrach. In der dritten Phase der Untersuchung wurde versucht, "bösartigen" Shellcode zu entwickeln, der beispielsweise dem Angreifer interaktiven Zugriff auf das System ermöglicht. Dies gelang innerhalb der zur Verfügung stehenden Zeit nicht. Das unter OS/390 und z/OS verfügbare System ABI (Application Binary Interface) unterscheidet sich grundsätzlich von anderen Unixen und Systemen auf Intel-Basis, wodurch verbreitete Techniken zur Programmierung von Shellcode nicht genügen. Vielmehr sind vertiefte Kenntnisse in der Assemblerprogrammierung des Hosts erforderlich.
Zusammenfassend lässt sich sagen, dass ein S/390-System unter OS/390 oder z/OS gegenüber Buffer-Overflow- und Format-String-Attacken ungefähr im gleichen Maße anfällig ist wie Unix-Systeme. Ähnlich wie zwischen den unterschiedlichen Unix-Derivaten gibt es auch hier einzelne Faktoren, die das Ausnutzen bestimmter Fehlertypen erleichtern oder erschweren – in Summe geht der Autor aber davon aus, dass ungefähr das gleiche Risikopotenzial vorliegt.
Denial-of-Service-Angriffe, bei denen der angegriffene Dienst blockiert oder zum Absturz gebracht wird, sind ohne weiteres möglich. Die Nutzung von Schwachstellen für weiter gehende Aktionen des Angreifers ist prinzipiell möglich, aber durch die Schwierigkeiten bei der Shellcode-Programmierung nach Einschätzung des Autors derzeit unwahrscheinlicher als im Unix-Umfeld.
Neben der theoretischen Nutzbarkeit typischer Programmierfehler ist zur Risikobeurteilung auch die Frage wichtig , ob derartige Fehler tatsächlich im verwendeten Sourcecode vorkommen. Die Erfahrung der letzten Jahrzehnte zeigt, dass C-Programme immer wieder derartige Probleme aufweisen. Es liegen zudem seitens IBM keinerlei Informationen vor, dass der Sourcecode der relevanten Bereiche im Betriebssystem und in den Netzwerkdiensten einem speziellen Security Review unterzogen wurde. Vielmehr geht GAI NetConsult davon aus, dass der Code – zumindest teilweise – aus anderen Unix-Derivaten stammt und lediglich an die Eigenheiten der S/390-Plattform angepasst wurde. Somit sind vermutlich auch vorhandene Fehler übernommen worden.
Diese Vermutungen sah man durch die Ergebnisse weiterer Tests
bestätigt: Bei der Untersuchung des z/OS-Systems mit Tools
(SPIKE Suite, siehe ![[externer Link]](../../images/link.gif)
www.immunitysec.com/spike.html), die
den zu testenden Dienst wahllos mit überlangen und
irregulären Eingaben überschütten, kam es
reproduzierbar zu Abstürzen im GPMSERVE Management Webserver
sowie im Network File System (NFS) und dem mountd-Daemon; ob
weitere RPC-basierte Dienste betroffen sind, konnte nicht
abschließend geklärt werden. IBM hat zwischenzeitlich
Patches bereitgestellt und bestätigt, dass es sich beim
GPMSERVE um einen Format-String-Fehler gehandelt hat.
Bei einer IP-Verbindung zu den Services (in verwundbarer Form) sind somit auf jeden Fall Denial-of-Service-Attacken möglich. Angreifer könnten so das gesamte File-Sharing zum Absturz bringen und beispielsweise verteilte SAP-Installationen massiv stören. Laut IBM sind die Schwachstellen nicht "exploitable", um Shell-Zugriff zu erlangen. Allerdings mussten sich in der Vergangenheit schon häufig Software-Hersteller nach solchen Versicherungen eines Besseren belehren lassen...
Bezüglich der grundsätzlichen Angreifbarkeit durch Buffer Overflow und Format Strings betont IBM, dass davon nur "Anwendungsprogramme" betroffen seien, der eigentliche Betriebssystemkern aber aus prinzipiellen Gründen dagegen immun sei. Detaillierte Aussagen zu den bestehenden Schutzmaßnahmen wolle man aber nicht machen. Auch ließ sich nicht klären, was genau für IBM zum "Kern" und was zur "Anwendungssoftware" gehört.
Eine weitere Quelle für Programmierfehler liegt in der zunehmenden Verwendung von Open-Source-Programmen am Host, beispielsweise dem Apache Webserver oder OpenSSH. Beide Programmpakete waren in der Vergangenheit von Fehlern betroffen und konnten erfolgreich angegriffen werden. Zumindest für die Schwachstellen in OpenSSH geht GAI NetConsult davon aus, dass sie auch unter OS/390 und z/OS auszunutzen gewesen wären. Problematisch ist dabei, dass der Quellcode frei vorliegt und sich somit Schwachstellen viel genauer untersuchen und Angriffs-Tools gezielter entwickeln lassen. Umso wichtiger ist es, vorhandene Fehler umgehend zu beheben, indem man (in der Regel sehr schnell verfügbare) Patches einspielt. IBM sieht sich hierbei allerdings nicht in der Verantwortung, selbst wenn das Unternehmen die Open Source Software bereitgestellt hat.
Die Untersuchungen des Linux-Systems (Linux for zSeries, SuSe Linux Enterprise Server7) ergaben in der ersten Phase folgende Resultate:
Bei der Beurteilung dieser Eigenschaften muss man zwischen den 32- und 64-Bit-Versionen unterscheiden: Im 32-Bit-Modus bestehen nur sehr geringe Unterschiede zwischen Linux auf S/390 und auf der Intel-Plattform (Big-Endian- statt Little-Endian-Format). Dies führt dazu, dass praktisch alle Schwachstellen, die auf der Intel-Architektur auszunutzen sind, auch auf der Hostplattform erfolgreich angegriffen werden können.
Für den 64-Bit-Modus der zSeries-Linux-Versionen ergibt sich aus der Null-Byte-Problematik, dass ein großer Teil der für die Intel-Plattform verfügbaren Angriffe nicht auf den Host übertragbar sind. Die Ausnutzbarkeit gegebenenfalls vorhandener Schwachstellen zum Einschleusen von Code ist deutlich erschwert, da Adressen über Stringeingaben nicht direkt geschrieben werden können.
In der zweiten Phase wurde versucht, einen am Host unter Linux ablaufenden Serverprozess mit einer präparierten Schwachstelle von einem externen Testrechner aus anzugreifen. Für die 32-Bit-Version ergaben sich keinerlei Probleme – Angriffe konnten von der Intel-Plattform quasi direkt übernommen werden.
Für eine Format-String-Schwachstelle konnte aber letztlich auch die genannte Problematik im 64-Bit-Modus überwunden werden: Anstatt im einzuschleusenden Code Adressen direkt zu übertragen, verwendet man auf dem Stack bereits an anderer Stelle vorhandene Adressen. Diese Technik kann erfolgreich für nahezu alle Format-String-Schwachstellen der Vergangenheit verwendet werden.
Wiederum zeigte das System keinerlei besondere Meldungen oder ungewöhnliche Reaktionen auf den eingeschleusten Code. Die Entwicklung von Shellcode für Linux auf der Hostplattform ist zudem sehr einfach, da alle Techniken aus dem Intel-Umfeld nahezu 1:1 übernommen werden können. Im konkreten Fall wurde ein Shellcode für den genannten Angriff entwickelt, der über einen execve-Maschinencode die Bourne Shell (/bin/sh) ausführt und somit dem Angreifer einen interaktiven Zugriff ermöglicht. Er besitzt dabei exakt die Rechte des angegriffenen Programms.
Nebenbemerkung: Der Mitte 2002 im Phrack-Magazin Nr. 59
( www.phrack.org/show.php?p=59&a=13)
veröffentlichte Shellcode für Linux for zSeries stellte
sich bei den Tests als ungeeignet für die 64-Bit-Version
heraus. Der Urheber hat zwischenzeitlich im Kontakt mit GAI
NetConsult betont, dass er über eine Reihe bislang
unveröffentlichter Exploits für 32-Bit-Linux
verfüge, die diesen Shellcode erfolgreich verwenden.
Die Untersuchungen haben letztlich gezeigt, dass auch für Linux auf der Hostplattform keine höhere Sicherheit gegenüber Buffer-Overflow- und Format-String-Angriffen besteht. Das Risikopotenzial ist ähnlich einzustufen wie bei anderen Linux-Plattformen oder auch Unix-Systemen.
Die Verfügbarkeit des Quellcodes und die unproblematische Entwicklungsmöglichkeit von Shellcode begünstigen zwar das Auffinden und Ausnutzen von Schwachstellen im Programmcode. Der derzeit stattfindende Übergang auf die 64-Bit-Architektur kompensiert diesen Nachteil aber, da hierdurch (wenn auch ungewollt) für den größten Teil der gängigen Angriffsmuster erhebliche Komplikationen entstehen.
Entscheidend ist letztlich, dass die S/390-Plattform (unabhängig vom Betriebssystem) den auf ihr ablaufenden Prozessen keine effektiven Schutzmechanismen für ihre Speichersegmente zur Verfügung stellt. Zudem werden Bereichsüberschreitungen bei Schreiboperationen im Memory und Manipulationen im ablaufenden Code ähnlich wie bei anderen Unix-Plattformen nicht erkannt.
Auch diese Ergebnisse wurden an IBM und SuSe übermittelt. Im Gegensatz zum z/OS-Bereich erhielten die Tester aber sowohl vom SuSe Security Team als auch von IBM Böblingen, die für die Linux-Entwicklungen auf der S/390-Plattform zuständig sind, innerhalb weniger Tage Antworten zu den aufgeworfenen Problemen und Fragen.
Zum dem Punkt Nichtbeachtung der angezeigten Speicherzugriffsrechte antwortete IBM, dass die S/390-Plattform lediglich die Unterscheidung zwischen Lese- und Schreibberechtigung zulasse, das (wichtige) Recht zur Ausführung von Speicherseiten sich aber nicht einschränken ließe. Im Juni 2002 sei in den plattformspezifischen Kernelteilen eine Modifikation erfolgt, die zumindest die Lese- und Schreibberechtigungen korrekt umsetze. SuSe bestätigte dies, hat aber noch keine Aussagen zur Übernahme dieser Modifikation gemacht.
Der beispielhafte Exploit einer Format-String-Schwachstelle wurde von beiden Seiten bestätigt. Sowohl IBM als auch SuSe sehen aber keine Möglichkeiten für grundlegende Maßnahmen zur Unterbindung solcher Angriffe. Die S/390-Plattform biete weder die Möglichkeit, den Stack nicht-ausführbar zu setzen, noch könne der riskante Parameter "%n" generell aus der Library entfernt werden, auch wenn man ihn im normalen Anwendungsumfeld praktisch nicht benötigt. Somit muss auch hier jeder einzelne aufgefundene Programmierfehler, der einen Format-String-Angriff ermöglicht, umgehend vom Code-Lieferanten korrigiert und der entsprechende Patch vom Betreiber eingespielt werden.
Auch wenn es geringe Unterschiede zwischen den untersuchten Systemen gibt, muss man insgesamt feststellen, dass am zSeries-Host – gleich unter welchem Betriebssystem – kein höherer Schutz gegen Angriffe von außen besteht als in anderen Unixen oder bei einem Linux-PC. Typische Programmierfehler können zu Buffer-Overflow- und Format-String-Schwachstellen führen, die in einem ähnlichen Maße auszunutzen sind wie in anderen Systemwelten. Neben Angriffen gegen die Verfügbarkeit ist prinzpiell auch das Einschleusen von Code möglich, der dann mit den Rechten des angegriffenen Dienstes am Host ausgeführt wird.
Bei der Sicherung des Hosts sollte man daher analog zur Sicherung einer Unix-Umgebung vorgehen. Die entsprechenden Konzepte dürften in vielen Unternehmen bereits vorliegen und müssen gegebenenfalls nur noch konsequent auf den Host übertragen werden. Dazu gehören vor allem eine Reduzierung der verfügbaren Dienste auf das unabdingbare Maß, die restriktive Konfiguration aller Dienste, der Ablauf mit minimalen Privilegien sowie ein Perimeterschutz gegenüber nicht voll vertrauenswürdigen Netzen. Nicht zu vernachlässigen sind jedoch auch die ständige Aktualisierung der Systeme und regelmäßige Security Audits.
Frank Breitschaft ist Bereichsleiter Security bei der GAI NetConsult, Berlin.
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2003#2, Seite 58
| 