Korset: Code-based Intrusion Detection for Linux

Titkosítás, biztonság, privát szféra

Az anti-vírus cégek vesztes játékot játszanak. Sikerül elkapniuk a "hétköznapi" vírusokat és rosszindulatú programokat, de igazából mindig egy lépéssel le vannak maradva. Olykor napokra van szükségük ahhoz, hogy frissítéseikkel felkészítsék ügyfeleik számítógépét az éppen aktuális támadásokra, vírusokra. Nem beszélve arról, hogy bizonyítottan vannak olyan kártékony programok, amelyeket a vírusírtók nem detektálnak. Ezek akár évekig is megbújhatnak a számítógépeken úgy, hogy közben személyes adatokat, üzleti titkokat gyűjtenek.

Éppen ezért Avishai Wool professzor és végzős diákja, Ohad Ben-Cohen - a Tel Aviv Egyetem mérnöki fakultásáról - más megközelítéssel fordult a probléma felé. A szakemberek a nemrég zárult Las Vegas-i Black Hat biztonsági konferencián mutattak be egy új, "Korset" névre hallgató megoldást, amely azzal a céllal készült, hogy megállítsa a "malware"-eket Linux-alapú operációs rendszereken.

A Korset működése

A Korset statikusan elemzi az alkalmazás forrását/object kódját, majd felépít egy ún. folyamatábrát (control flow graph - CFG). Ezt a folyamatábrát használja fel a kernel annak ellenőrzésére, hogy az adott program által használt rendszerhívások és azok sorrendje legitimek-e vagy sem. Ha a kernel abnormális aktivitást észlel, leállítja a program futását még azelőtt, hogy valami rosszindulatú cselekményre sor kerülhetne.

A Korset két részből áll. Egy automatikus statikus elemzőből, amely a fordítási folyamat részeként felépíti a CFG-t, illetve egy kernel agent-ből, amely érvényt szerez a CFG-től származó irányelvnek és leállítja a problémás processzeket.

A fejlesztők azt állítják, hogy a Korset segítségével sikeresen készítettek CFG-ket az egész GNU C library-hoz, és sikeresen bemutatták, hogy a Korset képes blokkolni a támadásokat elhanyagolható overhead mellett.

A Korset a GPLv3 feltételei szerint terjesztődik.

A Korset honlapja itt. A 0.1-es verzió elérhető a honlapról.

Referenciák:
Putting A 'Korset' On The Spread Of Computer Viruses: Invention Stays One Step Ahead Of Anti-virus Software
Beyond Firewalls
Korset: Automated, Zero False-Alarm Intrusion Detection for Linux (PDF)

( Husky | 2008. 09. 10., sze – 09:22 )

Τehát a fordítás során a futtatható file mellé lesz egy strace-szerű leírásunk is. Ha ez hiányzik vagy nem elérhető, a program futása megakadályozható.

Ez imho nem sokkal jobb attól mint amikor kriptográfiailag aláírom az alkalmazást (ellenőrzés és fordítás után) és csak az érvényes aláírással rendelkezőket engedem futtatni ahogy az eddig is bevett gyakorlat volt az erre érzékeny piacon.

Plusz a vírusíró készíthet ugyanilyen korset file-t, vagy ha már belenyúl a futtathatóba, belenyúlhat a korset-be is. Ha nem tud, akkor meg kereshet lokális buffergubancot ahogy eddig. Viszont igaz, ezt a korset remekül ki is védi. Felemás érzéseim vannak. :)

Arra gondoltam, hogy aki nekiáll felépíteni egy szervert amin ez fut, az elvileg alapból ügyel a biztonságra és nem wuftpd-t rak a torrent kliens mellé. Auditált szerveralkalmazásokon meg elég nehéz fogást találni, tehát nehezen megfogható, mennyi pluszt ad a korset.

A felemás meg azért jön, mert a webes alkalmazások/sqj innyektorok ellen ez nem véd, márpedig a front többnyire ott van, és a dns/bgp bughoz hasonló gyári működésről még nem is beszéltünk.

Persze jó ha van, csak nem az a fény az alagút végén amit az ember egy novel approach-tól szeretne látni.

Feltételezem - mint a malware / vírusírtóknak is - ennek is inkább desktop-on lenne jobban értelme, ahol az user letölt valamit, vagy levélmellékletként megkap, azt elindítja vagy elindul és az garázdálkodna a gépen a user jogosultsági szintjén (adatot gyűjtene, hátsó ajtót nyitna, spammelne, stb.). Én ennek nem szerveren látnám létjogosultságát elsősorban. Nem is buffer overflow exploitok ellen készült ez alighanem.

--
trey @ gépház

Desktopon elég kevés IDS-t láttam ami nem idegesíti alkalmanként az usert, az elég ingoványos terep.

Tegyük fel, csinálsz korset-et a firefoxra hogy nyugodtan klikkolj ha esetleg lenne benne bug. Majd feltennél egy firefox addont (/plugint). Hopp, ettől módosul a működés, ráadásul egy második kódtérhez adtál hozzá javascriptet (/külső libet), amit a korset vagy figyel (és akkor nem is tudsz belenyúlni), vagy nem (mert a weboldalak random vackainak is futnia kell). Innentől meg megint ott vagyunk, hogy akkor most mi ellen véd? :)

Jó ez, csak még bizonytalan vagyok, mennyire, és mire. :D

"Korset is still a very young prototype. It blocks real shellcodes, and it was found to incur negligible overhead on simple I/O-centric applications (see our companion
paper [BW08] for a detailed evaluation and analysis), but it is still very far from a mature HIDS."

Jelen állapotában nem sokat ér amúgy sem. Kezdet stádiumban van. Hogy ha "mature" lesz, akkor majd mennyit ér? Azt majd kitalálják a szakértők :)

--
trey @ gépház

innen lehet csemegezni tovabbi reszletek irant. a rovid sztori az, hogy az elmult evtizedben mar sokszor felfedeztek ezt a dolgot, es senkinek sem sikerult a valo eletre is atultetnie (a tobb problema kozul emitt lehet pl. a mimikri tamadasokrol olvasni). az a 'zero false positive' meg a szokasos akademiai kamu, nem valodi programokra vonatkozik (mert azok dinamikusan linkeltek, tobbszaluak, van bennuk asm kod, stb). amugy az a kernel patch is eleg mokas dolgokat tartalmaz, pl. az i386 syscall path-on ez van:

--- a/arch/i386/kernel/entry.S
+++ b/arch/i386/kernel/entry.S
@@ -367,6 +367,17 @@ ENTRY(system_call)
CFI_ADJUST_CFA_OFFSET 4
SAVE_ALL
GET_THREAD_INFO(%ebp)
+/* system calls security hook */
+#ifdef CONFIG_SECURITY_SYSCALL
+ pushl %eax
+ pushl %ebp
+ call security_system_call
+ cmpl $0, %eax
+ jnz syscall_noperm
+ popl %eax
+ popl %eax
+#endif

ez eddig meg akar jo is lehetne, csak hogy mi tortenik, ha az a jnz megis ugrik:

+#ifdef CONFIG_SECURITY_SYSCALL
+syscall_noperm:
+ movl $-EACCES,PT_EAX(%esp)
+ jmp resume_userspace
+END(syscall_noperm)
+#endif /* CONFIG_SECURITY_SYSCALL */

hat igen, az a ket pop erosen hianyzik, ez igy ranezesre egy ring-0 kodvegrehajtas kategoriaju hiba (minden 8 byte-tal eltolodik, a resume_userspace vegen levo iret szepen a userlandbol jovo eax:fs cimre fog visszaterni, az pedig siman kontrollalhato).

ma neztem ra a kodra fel pillanatot, kb. ennyibol meg is van a velemenyem rola: why beat a dead horse ;). a jnz meg akkor ugrik, amikor a sajat detektalo fv-uk 'nem'-et mond (mellesleg siman meghal a processz tole nem exploit eseten, tehat evidens, hogy ezt a kodot soha senki nem tesztelte i386-on).

"In this paper we discuss how static analysis can be used to automatically construct a model of application behavior. We show that the derived model can prevent future or unknown code injection attacks (such as buffer overflows) with guaranteed zero false alarms. We present Korset, a Linux prototype that implements this approach, and focus on its Kernel implementation and performance."

Tévedtem, állítólag buffer overflow ellen is jó. El kéne olvasni a PDF-et.

--
trey @ gépház

( uid_228 | 2008. 09. 10., sze – 09:38 )

Hol is olvastam azt, hogy az SELinux keszitoi is folyamatabrak, tamadasi vektorok menten kepzeltek el a dolgaikat, de egy blackhat inkabb egy buffer overflow-ra gyur, minthogy a matematikai bizonyitasban keres hibat? :))

--
Ruby takes the elegance and simplicity of Perl, and mixes it with the library support of Lisp.

( willy v | 2008. 09. 10., sze – 11:22 )

Ez vagy baromsag, vagy nem mukodik valos kornyezetben...
Egybkent ilyen ".. angol tudosok .. " feelingje van. Spanyolviaszkutatasban is eselyes. Nincs ido melyebben belemenni, majd az ido megmondja.

Az első gondolatom nekem is az volt, hogy "És tessékmondani ez a turinggépmegállási problémát is megoldja?"

Kiváncsi vagyok, hogy egy interpretert is tartalmazó programmal mit tud (tud-e egyáltalán bármit) ez a CFG syscall trace-es megközelítés kezdeni. Mert ha nem, akkor nuku javascript, perl, python, bash, stb. de akár még problémás lehet a jit fordított java kód is.

Én sokkal inkább úgy érzem, hogy ez egy olyan eszköz, ami néhány speciális támadásfajta kiszűrésére alkalmas lehet, amik ennek következtében kikopnak a használatból és átadják a helyüket olyanoknak, amik kiszűrésére ez a módszer teljesen alkalmatlan. A világegyenletet szerintem nem oldották meg ma sem.
---
Linux is bad juju.

( synapse | 2008. 09. 10., sze – 11:39 )

Ez arra valo, hogy ne lehessen _elteriteni_ a programot, tehat a korset tudja hogy fork() utan socket() hivas kovetkezik, nem pedig mondjuk system(). Ha system()-et lat, akkor terminalja a programot, sikitozik, satobbi...

Na most arra lennek kivancsi, hogy multithreades alkalmazas (egy pid latszik) hogy valosul meg? Ugyanis azok aszinkron hivogathatnak syscall-t. Ez az egyik.

A masik, hogy ez sem megoldas, hiszen ha enged read()-et, akkor kiolvashato vele file. Jelen esetben mondjuk a passwd/shadow/barmi mas. Tehat csak a parametereit kell manipulalni. Ez olyan, mint az ASLR meg a PAX. Nem oldja meg a problemat, de meglehetosen leszukiti az attack-vectort. ret2libc-vel most nem az osszes library hivasra lehet ugrani, hanem csak arra ami a korset-nek tetszik. Ha code-exec lehetseges, akkor viszont le is lehet emulalni mondjuk a read, write, stb... szekvenciat amig el nem erjuk a grafban a kivant megengedett syscallt.

synapse

--------------------------
The OOM killer is like a surgeon that amputates the limb of a man to save his life: losing a limb is not a nice thing, but sometimes there is nothing better to do.

"Understanding the Linux Kernel" on page frame reclaiming

Es a kernel latja a userspace-ben futo threadeket? Szerintem csak pidet lat (task_struct). Rosszul tudom?

synapse

--------------------------
The OOM killer is like a surgeon that amputates the limb of a man to save his life: losing a limb is not a nice thing, but sometimes there is nothing better to do.

"Understanding the Linux Kernel" on page frame reclaiming

( kisg v | 2008. 09. 10., sze – 11:50 )

Ezzel kapcsolatban szeretném megkérdezni a hozzáértőket, hogy a biztonsági szakemberek (illetve gonosz haxorok :) ) használnak-e automatizált statikus kódelemzőket, illetve futásidejű eszközöket, hogy a szoftverekben kihasználható hibákat keressenek?

Ha igen, akkor ugyanezek az eszközök miért nem jobban elterjedtek pl. a kernel/alkalmazásfejlesztők körében? Ha nem, akkor miért nem?

Itt most nem az ismert eszközökre, pl. valgrind gondolok, hanem ezeknél átfogóbb eszközökre. A Coverity ugye csinált / csinál marketinget abból, hogy megtalált elég sok nyílt forrású szoftverben hibákat, de az utóbbi időben elég csönd volt arrafelé, és a biztonsági hibák száma nem úgy tűnik, mintha csökkenne.

Elég szomorú a következőt olvasni Andrew Mortontól, aki elvileg pont a szívén viseli a kernel minőségét és a fejlesztési folyamat javítását:
"Our (complexity(config system) * complexity(header files)) is so large that compilation testing doesn't prove anything useful. You just have to check your homework very carefully and don earplugs for the inevitable explosions."

Ez az én értelmezésem szerint azt jelenti, hogy elfogadott a kernel fejlesztőknél az, hogy egy változásnál fogalmuk sincs, hogy annak milyen hatásai lesznek azon kívül, hogy bíznak a reviewerekben és a tesztelőkben. Meg persze a füldugókban...

Ez azért elég szomorú tekintve, hogy a szükséges számítási kapacitás szerintem simán rendelkezésre állna pl. Amazon EC2 vagy hasonló Cloudok használatával.

A 8GB RAM-mal rendelkező workstationök korában elvárható lenne, hogy a kernel (illetve általában a C / C++) fejlesztők legalább olyan eszközökkel dolgozzanak, mint ami a Java vagy .NET világban mindennapos (pl. az IDE pontosan látja a CFG-t, és már szerkesztés közben adja a warningokat / hibákat).

Ja, hogy C-re kicsit nehezebb megcsinálni a preprocesszor miatt? Tekintve, hogy ez a probléma az egész szoftveripart érinti, mivel a rendszerszoftverek nagy részét C / C++ -ban írják, csodálkozom, hogy nincs néhány milliárd USD ennek a fejlesztésére.

Arról nem is beszélve, hogy ekkora ipari összefogás lehetővé tenné, hogy a C / C++ következő ISO változatában a preprocesszort újragondolva a nyelv részévé tegyék, és ne egy független, szövegalapon dolgozó makrónyelv legyen.

Kicsit hosszúra sikerült, de annyiban nem offtopic, hogy olyan eszközöket használunk pont a rendszerszoftverek fejlesztésére, amelyek szinte maguk generálják a hibákat és amelyekhez nehéz fordítót (főleg C++) illetve analízis/transzformációs eszközöket írni.

Üdv,
Gergely

A programkódot statikusan kielemezni, hogy fog-e hülyeséget csinálni körülbelül lehetetlen. Kb a 4 közlekedési lámpa gyújtogatása az a komplexitás amit még bizonyítani lehet, hogy helyesen működik. A bizonyítás költsége legalább exponenciálisan nő a program komplexitásával.

Elméletileg igen. Gyakorlatilag azért elég sok mindent lehet tenni különféle trükkökkel, hogy valódi programokon ne exponenciálisan nőjön a komplexitás.

Érdemes például megnézni, hogy az Apple mit alkot az LLVM környékén: http://clang.llvm.org/
Gyakorlatilag megunták a GCC-t, és írnak egy olyan új C/ObjC/C++ fordítót, amibe már eleve be van tervezve a statikus kódellenőrzés, refaktoring felhasználás. 1-2 éven belül valószínűleg opcióként az XCode-ban elérhető lesz.
Van már készülő statikus kódellenőrzőjük is.

Hasonlóan, ha elméletileg nézzük, akkor a preprocesszorkonfigurációk száma is exponenciálisan nő a használt preprocesszor változók számával. Ha azonban megnézzük a valóban értelmes konfigurációkat, jóval kezelhetőbb helyzetet kapunk.

Üdv,
Gergely