Informatika | Informatikai biztonság » Fórján Tamás - Férgek, vírusok UNIX alatt

Férgek a betonban 2000. május Manapság minden Windowsfelhasználó tudatában van annak, hogy kedvenc számítógépére léptennyomon számítógép-vírusok leselkednek. A UNIX-ok (Linux, FreeBSD, Solaris, vagy más változatok) felhasználói viszont lekicsinylően legyintenek, amikor vírusokról hallanak - "persze, ha ti is olyan operációs rendszert használnátok, mint mi, nektek sem kellene tartanotok tőlük" - halljuk gyakran a szájukból. De mi az oka ennek a "hátrányos megkülönböztetésnek"? Igaz-e egyáltalán, hogy a vírusok csak a DOS- és Windows-világ rákfenéi? Ezt a kérdést feszegetjük sorozatunk legújabb részében. A címben említett megkülönböztetést a UNIX-rendszerek pártolói gyorsan megmagyarázzák: "mert a UNIX rendszerek már tervezésüktől fogva biztonságosabbak, sokkal szigorúbb bennük a felhasználók jogosultságainak ellenőrzése, és ráadásul a felhasználók is fegyelmezettebbek, nem

használják feleslegesen a rendszeradminisztrátori jogosultságokat". Pontosan mit is jelent ez, és valóban így van-e? A válasz: részben igen, részben nem. Ahogyan látni fogjuk, mindkét táborban vannak "gyenge pontok". Amit a UNIX-guruk állítanak, egyértelműen igaz: ezekben a rendszerekben nagyon szigorúan korlátozzák, hogy mely felhasználók milyen tevékenységeket végezhetnek, és milyeneket nem. Erre az egyik legszembetűnőbb példa a fájlok kezelése: egy átlagos felhasználó a részére kiutalt könyvtáron kívül máshová nem írhat, illetve máshonnan nem olvashat - ez a könyvtár viszont csak az övé, más felhasználók bele sem láthatnak. Ez a szigorú védelem sok bosszúságtól képes megóvni azokat, akik használják: a Windows-világban jellemző vírusfertőzési módszerek itt nem működnének. Hiába indít el például egy felhasználó egy fertőzött alkalmazást, a saját könyvtárában lévő programokon kívül

semmi mást nem képes megfertőzni, mivel nem rendelkezik írási jogosultsággal máshoz. Ez körülbelül úgy képzelhető el a Windowshoz szokott felhasználóknak, mintha nem írhatnának sem a SYSTEM, sem a Program Files könyvtárba, de még a gyökér-könyvtárba sem. Sőt, van a UNIX rendszereknek egy olyan előnyük is, amelyet általában kényelmetlenségként élnek meg a felhasználók: ezek a rendszerek a legritkább esetekben kompatíbilisek egymással a programkódok számára, azaz ha egy program fut az egyik gépen, attól még korántsem biztos, hogy egy másikon is gond nélkül elindul. Ez a tulajdonság pedig nagyban korlátozza a káros programok terjedését, mert bináris formában ez szinte lehetetlen. Van azonban a UNIX rendszereknek is jónéhány gyenge pontja. Az első mindjárt a rendszergazda: minden ilyen rendszerben - a Windows NT-hez hasonlóan - van egy felhasználó, a rendszergazda, aki bármit megtehet: bárhová írhat, minden fájlt

elolvashat és módosíthat. Ha tehát ez a felhasználó futtat olyan programokat, amelyek fertőzöttek, akkor a fertőzés az egész rendszerben elterjedhet. Éppen ezért a lelkiismeretes UNIX rendszergazdák szinte sohasem használják "emberfeletti" hatalmukat, csupán akkor, ha valami komoly indok van rá. Amikor nem szükséges, akkor csupán "mezei" felhasználóként jelentkeznek be a rendszerbe, hogy ezzel is csökkentsék a veszélyt. Még így is előfordulhat azonban, hogy olyan programot indítanak el, amiről úgy gondolják, tudják, mit csinál pedig csak az eredetihez megszólalásig hasonló programról van szó, apróbb módosításokkal - amely például hátsó ajtót vág a rendszerbe. Ezek a trójaiaknak nevezett programok ma is komoly problémát jelentenek, és nagyon komoly körültekintést igényelnek. A második gyenge láncszemet a rendszerben futó programok jelentik. Hogy ezek miért veszélyesek? Azért, mert öröklik annak a

felhasználónak a jogosultságait, aki elindította őket. Ha például a levelezést végző programot a rendszergazda indítja el, akkor ez a program minden olyan jogosultságot megkap, amellyel a rendszergazda rendelkezik - tehát írhat-olvashat a rendszerben akadály nélkül. Ez viszont két nagyon komoly következménnyel jár: egyrészt minden rendszergazdának folyton résen kell lennie, figyelnie kell, hogy mit indít el, másrészt minden program, amelyet elindít, bombabiztos kell, hogy legyen. Ha például egy felhasználó olyan programot indít, amely fontos állományokat próbál meg törölni, akkor a rendszer biztosan nem engedi ezt meg. Ha viszont a rendszergazda indítja el ugyanezt a programot, akkor a rendszer boldogan teljesíti "ura és parancsolója" akaratát - törli az állományokat. De akkor is lehet baj, ha a rendszergazda csak olyan programokat futtat, amelyekre szükség van a rendszer működéséhez. Ha bármilyen külső körülmény

"ki tudja zökkenteni" ezeket a programokat a normális működésükből, és rájuk tudja kényszeríteni akaratát, akkor - lévén rendszergazdai jogosultságokkal bírnak - végre is lehet hajtani ezeket a parancsokat. A Morris-worm Hogy ez nem pusztán elmélet, álljon itt egy klasszikus példa. 1988 novemberében az Internet - amely akkor még mindössze 60,000 számítógépből állt - az addigi legnagyobb támadás áldozata lett. Egy elszabadult program egymás után fertőzte meg az összekapcsolt gépeket, és használta őket ugródeszkaként a további terjedéshez - amely végül az egész rendszer katasztrofális lelassulásához vezetett. A "féreg" - merthogy a szakirodalom azóta szerzője után csak Morris-worm néven emlegeti volt az első olyan program, amely kifejezetten a rendszerek hiányosságait aknázta ki Ezek a problémák, vagy biztonsági lyukak már jó ideje ismertek voltak a rendszerek üzemeltetői előtt - de senki sem

gondolta, hogy komoly veszélyt jelentenének. Többfajta rést is kiaknázott a Féreg: a sendmail (levelező szerver) programba épített "hibakereső" funkción mint hátsó ajtón keresztül parancsokat lehetett végrehajtani a megtámadott gépen, annak a felhasználónak a jogosultságaival, aki a levelező szervert indította. Mivel ez a rendszergazda volt, ezért minden olyan gépen, amelyen a megfelelő lyukat tartalmazó sendmail futott, a program könnyen jutott rendszergazdai jogosultsághoz. Emellett kihasználta azt is, hogy a gépek "megbíznak egymásban", azaz egyes gépek azonosítás nélkül beengedtek más, "megbízhatónak" gondolt gépekről felhasználókat (például a rendszergazdát). A Féreg itt megszemélyesítette a "bizalmat élvező" felhasználókat, így minden gond nélkül bejutott ezekre a gépekre is. De hurcolt magával egy 432 szóból álló szótárat is, amelyet arra használt, hogy ha a felsorolt

"tuti" módszerek nem váltak be, akkor próbálkozással, felhasználónév/jelszó párok kitalálásával kísérletezett. Amikor bejutott egy gépre, ott azonnal nekilátott, hogy megvesse lábát: saját forráskódját minden rendszeren lefordította (így elkerülte a bináris inkompatibilitás problémáját), és nekilátott újabb célpontokat keresni, majd indult a folyamat az elejéről. A Morris-worm működési ábrája UNIX CSODABOGARAK A fenti eset tanulságai világosak: nehezen kitalálható jelszót kell választani, és minden programból a lehető legfrissebbet kell használni. Az Internet korában a programokkal kapcsolatos hibák percek, órák alatt jutnak el a világ minden részére - nem lehet tehát arra számítani, hogy "tudom, hogy hibás, mások viszont úgyse jönnek rá". Azonban bármilyen világos is, hogy mit kell csinálni, számos rendszergazda nem törődik a szabályokkal, így azután nem csoda, hogy biztonságosnak hitt

rendszereikben problémák jelentkeznek. 1998-ban jelezték először, hogy a BIND program (az Internet egyik alapkövének számító DNS (Domain Name System) UNIX-os implementációja) 4.97-es, illetve 812-es változata olyan hibát tartalmaz, amely rendszergazdai jogosultságok szerzésére ad lehetőséget anélkül, hogy a támadó tudná a rendszergazda jelszavát. Azonnal meg is jelent egy Admw0rm-nak nevezett program, amely ennek a hibának a kiaknázásával gépről gépre próbált meg terjedni. Ez az eset a másik nagyon gyakori hibaforrás, az úgynevezett "buffer overrun" problémát aknázza ki. Arról van szó, hogy a programot felépítő függvények egymás hívásakor a memória stack-nek nevezett területén adják át egymásnak a paramétereket. A stack-en azonban más is van: azok a memóriacímek, amelyekre a hívott függvények befejezte után a programnak ugrania kell. Ha a hívó program nem végez ellenőrzéseket a paraméterek hosszára, akkor

megfelelően nagy paraméterek esetén előfordulhat, hogy a stack-re több adatot próbál meg írni a program, mint amennyi helyet a paraméterek számára lefoglalt. Ekkor - értelemszerűen - felülíródnak a korábban ott található adatok Amikor pedig a hívott függvény befejezi működését, akkor a stack-ről nem azokat az adatokat tölti vissza a rendszer, amelyeket a függvény hívása előtt odaírt, hanem azokat, amelyek fölülírták az eredeti adatokat. Így lehetséges olyan behatolási kísérlet, amely megpróbál egy bufferbe túlságosan sok adatot tölteni. Ha a túlcsorduló adatok a gép számára értelmezhetőek, akkor az eredeti programkód helyett ez a kód hajtódik végre. Noha kissé nyakatekertnek hangzik, a buffer overrun módszerek ma az egyik legelterjedtebb betörési eszköznek számítanak. Pedig a védekezés nem túlságosan bonyolult: minden alkalommal, ha a program külső forrásból kér be adatokat (pl. felhasználónév és jelszó

prompt), ellenőrizni kell a megadott paraméterek hosszát. Ha ez túl nagy, akkor le kell vágni a fölösleget Érdekes adat, hogy az elmúlt hónapokban az Internetes betörésekkel foglalkozó levelező listán a sláger ez a két évvel ezelőtti, könnyen kijavítható módszer volt. JAVA A Java olyan programozási nyelv, amely egy jól definiált, biztonságos környezetben, az úgynevezett "sandbox"-ban futtatja az elkészült programokat. Ennek az az előnye, hogy minden olyan hardverkörnyezetben, ahol fut a sandbox, minden Java alkalmazás képes futni. Így teljesen platformfüggetlen programok készíthetők vele. Ez persze a "sötét oldal" számára is nagy lehetőség: ha sikerül működőképes Java vírust írni, az minden hardveren képes lesz futni. Hát, sikerült - először 1998-ban Az első Java-vírus megjelenésével megdőlt az a nézet, hogy a Java nyelv annyira biztonságos, hogy nem lehet Java vírust készíteni. Azonban a helyzet

nem vált azonnal kritikussá, mert a terjedési mechanizmus nem volt túlságosan hatékony. Amint az köztudott, a modernebb Web-böngészők képesek Java-kisalkalmazások futtatására saját futtatókörnyezetükben - ami nagyon korlátozott képességekkel bír csak. Azonban Java programot nem csak böngészőből lehet futtatni, hanem valódi, teljes értékű programként is, böngésző nélkül. Az 1998ban megjelent StrangeBrew vírus ilyen módon képes csak futni, böngészőből tehát egyáltalán nem Működni viszont működik: megkeres és megfertőz más, a gépen tárolt Java alkalmazásokat, így képes saját maga továbbterjesztésére - a gépek közötti terjedésre azonban csak akkor, ha tulajdonosaik Javaprogramokat cserélnek egymással. A fertőzési mechanizmuson finomított az 1999 nyarán megjelent BeanHive vírus, amely a StrangeBrew-hoz hasonló módon terjed, ám saját programkódját az Internet egy megadott pontjáról tölti le. Mivel a

Java-programok felhasználók közötti cseréje ma még nem különösebben gyakori, a Java vírusok egyelőre nem jelentenek komoly veszélyt - de ez egyik napról a másikra megváltozhat. VÉGSZÓ A ritka UNIX-vírusok és férgek után érdekességként megemlítjük, hogy a Sun Microsystems kifejlesztette Solaris operációs rendszeréhez a WABI Windows-emulátort. Ebben az emulátorban remekül fut a Microsoft Word, amiben viszont remekül futnak a makróvírusok - így, szigorúan véve, a makróvírusok még Solaris alatt is képesek működni. Az üzenet pedig egyértelmű: nem kizárólag az operációs rendszer gondos megválasztása az, ami megvédhet egy rendszert a különféle behatolóktól (vírusoktól, férgektől és betörőktől), hanem az az odafigyelés, amellyel a jó rendszergazdák követik a rendszerüket érintő biztonsági híreket, és korrigálják, kijavítják a felderített biztonsági lyukakat, illetve ráveszik felhasználóikat, hogy ők is

körültekintően, adataik értékének tudatában kezeljék az új és ismeretlen programokat. Fórján Tamás