Computer gelten schon seit jeher als sensible Gesellen: Zuviel Hitze im Rechenzentrum kann sie ebenso lahmlegen wie irgendwo ein ferner Blitzschlag, ganz zu schweigen von den Risiken, die von bösen, fremden Bombenlegern - oder von ähnlich bösen, wohlbekannten Programmierern - ausgehen können.

Sind all diese Aspekte, die den streßgeplagten Managern großer Rechenzentren schon seit jeher viel Kopfzerbrechen bereiten, so kommt seit etwa zwei oder drei Jahren noch etwas völlig Neues dazu: das Risiko, daß Computer von "Viren" befallen werden und in ihren Dateien sozusagen die "Masern" bekommen. Denn seit etwa drei Jahren ist in Fachkreisen bekannt, daß es in der Tat Wege gibt, Rechensysteme tückisch zu "infizieren". Und damit deren vorzeitigen Exitus einzuleiten. . .

Der erste, der das bedrohliche, paradoxerweise aber durchaus auch nutzbringende Potential der sogenannten "Computerviren "erkannte und im kleinen Kreis beschrieb, war 1983 Fred Cohen von der Universität von Südkalifornien. Und seit seiner Pionierleistung ist es um die Gefahren - und Möglichkeiten - dieser seltsamen Rechner-Invasoren nie mehr ganz still geworden.

Einer der ersten, die sich mit dem Thema in Computerviren in Deutschland intensiv auseinandersetzen, ist Rüdiger Dierstein von der Zentralen Datenverarbeitung der Deutschen Forschungs- und Versuchsanstalt für Luft- und Raumfahrt (DFVLR) in Oberpfaffenhofen bei München (siehe CW Nr. 37/85 Seite 1; Experten vom Thema Computerviren infiziert). Dierstein definiert in einer ausführlichen, internen DFVLR-Schrift zu diesem Thema exakt, was man unter einem Computervirus denn eigentlich zu verstehen habe:

Als Computervirus wird ein Programm bezeichnet, das zwei charakteristische Eigenschaften hat: es kann erstens Kopien seiner selbst erzeugen und diese Kopien in andere Programme einpflanzen; und es kann zweitens eine wohldefinierte Funktion ausführen.

Dierstein bezeichnet die erste der beiden Eigenschaften als "Reproduktion" und die zweite als "Funktionalität".

Zum Punkt Reproduktion, also zur Fähigkeit eines Computervirus, andere Programme zu infizieren, bemerkt Dierstein präzisierend, es gehe dabei darum, daß ein Computervirus "immer dann eine Kopie von sich selbst in ein anderes Programm einzufügen" vermag, wenn "dieses Programm bisher noch keine Kopie des Virus" enthielt, also noch nicht infiziert war . Dabei sei aber vor allem eines zu beachten: jedes Programm, das auf die eben erwähnte Weise irgendwann einmal "infiziert" worden ist, kann fortan "sofort selbst wieder als Virus auftreten und andere, noch 'keimfreie' Programme infizieren". Mit der Folge, natürlich, daß die Rechner-Infektion sich nun, "genau wie den biologischen Viren", in einem Datenverarbeitungs-System oder -Netz "lawinenartig" ausbreiten kann.

Zur zweiten Haupteigenschaft eines Computervirus, der Funktion, ist gleichfalls noch ein wenig mehr anzumerken. Diese "Funktion" legt fest, welche "Wirkungen" des Virus "in einem Datenverarbeitungssystem oder in einem Rechnernetz" entfaltet; und zwar "nachdem es sich dort ausgebreitet hat". Doch diese Funktion muß in keiner Weise immer gleich "bösartig" sein; denn, so wird sich noch zeigen, man kann auch "helfende "Viren entwickeln und in einen Rechner einschleusen.

Neben ihren beiden, hier knapp behandelten Haupt-Eigenschaften können Computerviren noch verschiedene andere Merkmale aufweisen, bemerkt Dierstein; und zwar Merkmale, die durchaus gefährlich sein und die das bösartige Verhalten mancher Viren durchaus noch verstärken können. Doch sie gehören nicht mehr zur hier einleitend behandelten, grundlegenden - und die Viren als solche definierenden - Struktur.

Ein Beispiel für eine besonders tückische dieser Zusatz-Eigenschaften ist die bekannte "Auslösefunktion", denn mit ihrer Hilfe kann der Zeitpunkt, von dem an das Virus seine Aktivität entfaltet, auf eine ferne Zukunft hinausgeschoben werden. Doch wie gesagt: Auch ohne diese Zusatzfunktion ist ein Programm mit den Eigenschaften "Reproduktion" und "Funktionalität" - nach Diersteins Definition - bereits ein Virus.

Viren können in Assembler, in höheren Sprachen wie etwa Fortran oder C und auch, wie etwa seinerzeit von Cohen selber, in einer Kombination aus Assembler und Fortran geschrieben werden. Und nach einer verbalen Beschreibung Diersteins die sich aber leicht in den jeweils angebrachten Code umsetzen läßt sieht ein Virus konkret beispielsweise so aus:

Das Virus "V" sucht nach irgendeiner ausführbaren Programmdatei EXEC, die noch nicht infiziert wurde. Dazu prüft es zunächst, ob in der ersten Zeile der Datei "1234567" steht. Ist dies nicht der Fall, so kopiert das Virus V sich vor der Datei EXEC und macht damit aus ihr die "infizierte" Datei INFEX. Dann fährt das Virus V fort und führt das Unterprogramm FUNKTION aus. Danach wird der Rest des Hauptprogramms ausgeführt, dem das Virus V vorgeschaltet worden war.

Und das geschieht, in der Folge, im infizierten Rechnersystem? - Ganz einfach: Immer, wenn ein Anwender nun das Programm EXEC aufruft, führt die Maschine an dessen Stelle das - infizierte - Programm INFEX aus. Und da dieses Programm INFEX ja das Virus V enthält, infiziert es zunächst wieder eine andere, ausführbare Datei, ehe es weitergeht dann ganz so fortfährt, als wäre es einfach nur EXEC. Dierstein: "Von einer geringen Verzögerung für das Infizieren abgesehen, verhält sich INFEX, bis auf die zusätzlichen Virusfunktionen, genauso wie EXEC."

Was die "Funktion" eines Virus betrifft, so wird die natürlich so gut wie immer eine andere sein als die des befallenen "Wirts-Programms", hebt Dierstein hervor; und das bedeutet, das Virus ändere die Funktion des Wirts-Programms - zum Guten wie zum Bösen.

Während man die bösen Wirkungen eines Virus nun hier wohl kaum weiter ausmalen muß, ist es sicherlich interessant, ein paar Worte zu potentiell nutzbringenden Eindringlingen zu sagen. Wobei übrigens auch die Idee der "helfenden" Viren schon auf den Viren-Erfinder Cohen zurückgeht; denn er hat seinerzeit schon einen einfachen Kompressions-Algorithmus erfunden, der wie ein Virus arbeiten soll und der damit helfen könnte, Speicherplatz einzusparen.

Dazu kommentiert Dierstein: auch wenn dies vielleicht nicht unbedingt der beste und wirtschaftlichste Weg sein mag, Speicherplatz zu sparen - es sei doch wohl ein bestehender Gedanke, "bestimmte Systemfunktionen virusartigen Programmen zu übertragen und somit sicher zu gehen, daß diese Funktionen auch wirklich bis in die hintersten Winkel eines Systems eingebaut werden". Denn warum sollte es denn eigentlich nicht möglich sein, "die Leistungsfähigkeit bestimmter Systemfunktionen mit Hilfe von Virusprogrammen zu verbessern"?

Systemfunktionen durch Viren verbessert

Ehe diese Idee später noch weiter verfolgt wird, scheint an spätestens dieser Stelle nun dringend ein historischer Rückblick angebracht; und zwar eine Darstellung der Pionier-Leistung Cohens, die sich ja nicht bloß erschöpfte, die vage Idee eines Virus in konkreten Code umsetzen und außerdem noch nach nutzbringenden Anwendungen für diese Viren gesucht zu haben.

Die große Leistung, die Cohen vor zwei bis drei Jahren mit seiner Publikation - und Demonstration! - der Viren erbracht hat, würdigt Dierstein mit dem einleitenden Hinweis, heutzutage müsse man alle Aussagen über Sicherheitsmängel eines komplizierten Computer-Systems konkret im Einzelfalle nachweisen oder noch besser vorführen, wolle man überhaupt ernst genommen werden. Denn solange man anders als Cohen, Risiken, Schwachstellen und andere Gefahrenpunkte bloß behaupte oder auch bloß logischschlüssig aufzeige, finde man bei den Verantwortlichen praktisch kein Gehör.

Versuche mit Bedacht gewählt und abgegrenzt

Die Lage sei hier also ähnlich wie auch im Bereich der Leistungsanalyse großer, komplexer Betriebssysteme. Denn auch hier wurden Aussagen über deren Leistungsfähigkeit beziehungsweise über deren Fehlverhalten solange nur als "bloße Vermutung" behandelt, solange man sich allein aus theoretischen Überlegungen heraus ableite. Solange es also an konkreten, um Routinebetrieb vorgenommenen und damit überzeugenden Messungen noch fehle.

Cohen, so lobt Dierstein nun, habe genau diese, jedem Theoretiker entgegenschlagende Skepsis nun bewußt damit abzufangen gesucht, daß er von Anfang an eben nicht bloß Gedankenexperimente vorlegte, sondern stets auch auf praktische Vorführ-Möglichkeiten drängte. Dabei habe er das Ziel seiner Versuche "mit Bedacht gewählt und genau abgegrenzt"; denn Cohen wollte ja gerade nicht in der Art eines Hackers vorgehen und sich etwa als unberechtigter Benutzer über Schleichwege und Schlupflöcher Zugriff auf geschützte Daten oder Funktionen verschaffen; und er wollte das System ja auch gar nicht auf Hacker-Weise mißbrauchen oder gar lahmlegen. Sondern, so Dierstein, Cohen wollte "im Experiment die eigentliche kennzeichnende und "todbringende" Eigenschaft des Computervirus" bestätigen"; nämlich die, daß so ein Virus sich eben "unbemerkt und ungehindert von allen Grenzen und Abschottungen auf legalen Wegen in der gesamten Software eines DV-Systems ausbreiten" könne.

Für Cohen ging es seinerzeit klar und offen darum, mit Wissen und Zustimmung des Systemverantwortlichen ein einziges Ur-Virus an geeigneter Stelle in ein System einzubringen und dann dessen Ausbreitung zu beobachten. Dabei mußten Schwachstellen der Implementierung während des Experiments sorgfältig vermieden werden, denn es sollten bei Cohens Versuch ja bewußt nicht etwa eigene Schwachstellen, sondern vielmehr "grundsätzliche Fehler in den Sicherheitskonzepten" aufgedeckt werden.

Grundsätzliche Fehler in den Konzepten gesucht

In diesem Kontext ist nun wichtig, daß sogar die Frage, wie bringt man eigentlich ein Ur-Virus in ein System hinein, nicht Gegenstand der Versuche dar. Denn es gibt ja in jedem Datenverarbeitungs-System eine große Zahl von Menschen, die das Recht zum Schreiben und Lesen von Programmen haben und die daher auch leicht ein Ur-Virus auf den Weg bringen können.

Die Versuche haben später sogar gezeigt, daß man Ur-Viren selbst im Anwender-Modus in ein System bringen kann. Und Dierstein mahnt in diesem Zusammenhang daher nun ausdrücklich, man solle sich bewußt machen, daß "die Einschränkung (der Cohenschen Versuche) auf, berechtige Benutzer die Bedrohung, die von den Viren ausgeht, fast nicht vermindert und erste recht nicht grundsätzlich beseitigt." Denn man sehe an Hand der Experimente doch wohl klar, wie gefährdet Systeme allgemein seien, besonders aber gerade in jenen Teilen, in denen "mit besonderen Privilegien und Autorisierungen an ihnen gearbeitet werden" könne. Cohen und seine Mitarbeiter gingen bei ihren Tests mit größter Vorsicht vor. Sie gaben alle Viren manuell ein und sie beschränkten sich auf Exemplare, die in ihrem Funktions-Teil keine "Krankheitskeime" aufwiesen; denn alles, was sie taten, war, daß sie einfach nur ihre Präsenz meldeten.

Keine Krankheitskeime im Funktionsteil

Als weitere Sicherheit wurden besondere "Spuren" angelegt, die dafür sorgten, daß kein Virus sich ausbreiten könnte, ohne daß man ihn entdecken konnte. Den eigentlichen Prozeß der Infektion schützten besondere Zugriffskontrollen und der für die Versuche benutzte Code wurde außerdem in Segmente eingeteilt, die wiederum, jedes für sich, verschlüsselt und geschützt wurden; so sollte jede denkbare Nutzung durch fremde, nicht direkt am Experiment beteiligte Personen verhütet werden.

Nach Abschluß jedes Versuchs wurden die Daten schließlich wieder von allen Virus-Spuren befreit und somit sichergestellt, daß kein Benutzer Schaden leiden konnte.

Ein erster Versuch Cohens lief auf einer voll ausgelasteten VAX-750 unter dem Betriebssystem Unix; dabei wurde das Virus, nach acht Stunden Vorbereitungszeit, in ein neues Programm eingepflanzt, dessen Leistung und Laufeigenschaften noch unbekannt waren. Cohen setzte das Virus an den Anfang des Programms und erreichte so, daß es stets schon dann aktiv wurde, wenn das Programm - das der grafischen Anzeige der Unix-Dateistrukturen diente - seine Arbeit noch gar nicht begonnen hatte.

Nach fünf Minuten alle Stufen durchlaufen

Dieser erste Versuch gliedert sich in fünf Wiederholungen bei denen dem Experimentator zwischen fünf und knapp 60 Minuten Systemautorisierung zugestanden wurden. Das Virus war mit seinen 200 Zeilen Code so gebaut, daß es in nicht ganz 500 Millisekunden ablief; also schnell genug, um keine auffallenden Verzögerungen zu bewirken.

Wie die Tests zeigten, dauerte es maximal 60, teilweise aber auch bloß fünf Minuten, bis das Virus sich in alle Autorisierungsstufen des Systems vorgearbeitet hatte. Diese Resultate überraschten praktisch jedermann, zumal das Virus im minimaler Zeit auch "erstaunlich weit" verbreitet wurde. Die Konsequenz: die für das System Verantwortlichen weigerten sich prompt, weiteren Experimenten zuzustimmen. . . - Was Cohen nicht zuletzt insofern bedauerlich findet, als damit auch gleich alle geplanten, weitergehenden Tests unterbunden wurden; Versuche nämlich, bei denen er mit Hilfe zusätzlicher Tracing-Programm beispielsweise noch hatte untersuchen wollen, zu welchen Folgen Infektionen von Password-Dateien wohl führen können. Dazu hätte er noch die "Spuren" analysieren müssen, die die Viren auf ihrem Weg durch das System hinterlassen.

Ein weiterer Versuch Cohens lief auf einem Univac-Rechner des Typs 1108, wobei hier mit dem - eigens als "sicheres System" ausgewiesenem - Betriebssystem Bell-LaPadula der Mitre Corporation gearbeitet wurde. Auch in diesem Fall wurde sichergestellt, daß das Virus nicht etwa Systemfehler oder Schwachstellen der Anlage für seine Ausbreitung nutzte, sondern sich nur auf "legitimen" Wegen ausbreitete.

Die Infektion dauerte nur 20 Sekunden

Bei diesem Experiment wurde ein Virus eingesetzt, das aus fünf Zeilen Assemblercode, aus etwa 200 Zeilen Fortran IV und aus 50 Zeilen Job-Control-Language bestand und das in Eile und unter sehr ungünstigen Randbedingungen entwickelt worden ist. Dennoch dauert die Infektion des Systems nur 20 Sekunden; ein Wert übrigens, den man durch entsprechende Optimierungen noch leicht auf eine Sekunde drücken könnte. Und sicher, so meinen Fachleute, wäre es auch noch leicht möglich, ein unauffälligeres" Exemplar dieses Virus zu entwickeln.

Andere Versuche des Viren-"Erfinders" Cohen galten den Zusammenhängen zwischen Resource-Sharing einerseits und dem Ausbreitungsverhalten der Viren andererseits. Dabei stellte sich - auf einer VAX unter Unix - einmal mehr heraus, daß der größte Teil des Sharings in den meisten Rechnern nur von einigen wenigen Benutzern herzurühren scheint - und dies wiederum deutet gleich schon einen ersten Weg an, wie man die Pflege der Viren vielleicht einmal wieder bekämpft können. Denn das Sharing und die Ausbreitung der Viren, so betont Dierstein, "hängen miteinander ursächlich zusammen"; und daher könnte es vielleicht sinnvoll sein, jene Benutzer die, auf dem Weg des Ressource-Sharing, mit anderen Benutzern oder Systemteilen besonders viel Kontakt haben, speziellen und besondern strengen Schutzmechanismen zu unterwerfen. . .

Dieser Sharing-Versuch zeigte am Rande außerdem noch, daß erstens viel mehr Benutzer, als die Systemverantwortlichen gedacht haben, zur Ausführung privilegierter Befehle berechtigt waren. Und daß zweitens ganz andere Leute, als man vermutet hatte, "durch besonders hohe Sharing-Faktoren herausragten".

Die Beobachtungen ergaben, daß dann, wenn einer der privilegierten Benutzer "Opfer" einer Virus-Infektion geworden war, keine Stunde mehr verstrich, ehe das gesamte System "vollständig infiziert" war. Doch sie zeigten außerdem, daß man die Ausbreitungsgeschwindigkeit der Viren "um Größenordnungen senken" konnte, griff man zu einfachen organisatorischen Änderungen. Wobei diese weder die Funktionalität noch die Leistungsfähigkeit des Systems in Mitleidenschaft zogen.

Besonders rasch kommen Viren nach Cohens Studien immer dann voran, wenn Systemverwalter ihr Accountfile benutzen, um "aus irgendwelchen Gründen" die Programme anderer Benutzer laufen zu lassen. Denn auf diesem Umweg gelangen Viren unversehens von Ebenen niedriger Berechtigung zu Ebenen höherer Berechtigung - und von jenen aus konnten sie das System dann binnen weniger Minuten verseuchen. . .

Dazu der Rat des DFVLR-Experten: Systemverwaltern wollte man wohl besser ein getrenntes Accounting zuweisen.

In einem Resümee der hier nur knapp referierten Versuche und Analysen Cohens faßt Dierstein zusammen, daß Viren sich erstens in sehr kurzer Zeit entwickeln lassen, daß sie, zweitens, bei geschickter Programmierung in den meisten der heutigen Systeme "so gut wie keine Spuren hinterlassen", daß sie sich drittens, auch in Systemen durchsetzen, die nach modernen Prinzipien des Schichten-Aufbaus erstellt wurden und daß sie viertens selbst von Leuten mit wenig Systemerfahrung eingepflanzt werden können.

Sind sie in einem Computer erst mal drin, so breiten sie sich laut Dierstein "in Windeseile durch ein gesamtes DV-System aus" . Und außerdem muß man fürchten, daß sie in einem Netz von Rechnern gleich rasch vorankommen wie in einem singulären Einzel-System. . .

Eben aus diesen Gründen ist die Gefahr, die von Viren ausgeht, wohl "immens". Zumal man sich ja immer wieder bewußt machen sollte, daß unsere Gesellschaft heute sehr stark vom permanenten und korrekten Funktionieren zahlreicher Computersysteme abhängig ist. Von Systemen also, für die "bösartige" Virus-Programme eine "unübersehbare Gefahr" darstellen, wie Dierstein hervorhebt.