"ami arra utal, hogy a böngésző az Apple WebKit-jére épül, azaz a "from scratch" nem teljesen stimmel."

öö, volt olyanról szó, hogy from scratch? a kis képregényes bemutatójukban is írják, hogy WebKit-et használnak..

www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=google+chrome+scratch

Jaja, koztudott hogy webkit alapu. A koncepcio volt from scratch.

Mellesleg pedig hogy egyszer az eletben konstruktiv hozzaszolasom is legyen:

Elvileg (infok amiket olvastam) a webkit minden bongeszo instance-nek (tab, windows etc) nyit egy uj processt. Namost ez szerintem baromi jo otlet, mivel valamelyik hasal akkor nem rantja az egeszet (40 tab zarodik flashplugin szarsaga miatt), masreszt pedig a processeket lehet kulon utemezni. Ez utobbi akkor lenne a legfrankobb hogyha belsoleg megoldana ezt a dolgot es nem kezzel kene rahivni a processekre a renice-ot :) Sercurity szempontbol is utos lehet a tema hogyha a privsep jol meg van oldva, mert peldaul a google nem lopja el a citibankos cookie-t (mert nincs is az address space-eben). All in all szerintem fasza kis kezdemenyezes amibol tanulhatna a FF3, mert ez a threades dolog szopas, ha valami borul akkor borul minden. Szerintem egy ilyen kornyezetben a fork() lassusaga irrelevans (nem nyitogatsz meg masodpercenkent 100-200 tabot).

Es akkor feldobom a nagy kerdest:
Szerintetek melyik a jobb hozzaallas az ilyen multithread problemakhoz? Ez most akar bongeszo eseteben, akar webserver eseteben (apache prefork vs worker). Legyen process-szinten szeparalva, vagy eleg thread-szinten. Esetleg hibrid megoldas? Kivancsi vagyok a velemenyetekre mind fejlesztoi mind security szempontbol.

synapse

Ok, akkor lehet hogy én értettem félre a dolgot.
@synapse
Böngészőnél az általad leírtak miatt sztem egyértelműen _kell(ene)_ a process szintű szeparáció. Egyébként meg nyilván attól függ a döntés, hogy mit akarunk kezdeni az adott software-el

hup.hu/cikkek/20080902/google_chrome_bongeszot_fejleszt_a_google_from_scratch
szerintem te is ezt olvastad és ez azt írja amit te, én is úgy tudtam eddig.

A túlcsordulásos támadások ellen NEM véd az, hogy egy helyett több processz fut. Ha már legalább 1 processz fut, akkor támadható ezzel a módszerrel ha meg több akkor mindegyik támadható, azaz a támadási felület még nagyobb.

A több processzre szeparálás a programhibák ellen vég, ha a kód összeomlik, akkor az egész processz is összeomlik. De ha minden TAB önálló procesz, akkor az összeomlás csak azt a TAB-ot érinti.

Ennek semmi köze a túlcsordulásos támadásokhoz. Ez ellen úgy lehet védekezni, hogy vagy 100% hibátlan kódot írsz, vagy nem futtatsz egyetlen processzt sem. :)

FIKA ON

>A túlcsordulásos támadások ellen NEM véd az, >hogy egy helyett több processz fut. Ha már

no shit, tenyleg nem ved? :D

>legalább 1 processz fut, akkor támadható ezzel >a módszerrel ha meg több akkor mindegyik >támadható, azaz a támadási felület még >nagyobb.

A kod ugyanaz mindegyik instance-ben. Mitol lesz nagyobb a tamadasi felulet? Egy bugbol nem lesz ket bug mert 2x elinditom a software-t.

>A több processzre szeparálás a programhibák >ellen vég, ha a kód összeomlik, akkor az egész >processz is összeomlik. De ha minden TAB >önálló procesz, akkor az összeomlás csak azt a >TAB-ot érinti.

Programhibak ellen nem ved. Kod nem omlik ossze. Ha osszeroskad a process vagy atveszik felette az iranyitast akkor minimalis lehet a baj, mert NEM LATJA a tobbi process memoriajat (tobbi tabot), igy nem is tudja onnan kiszedni az informaciot. Ja es ofkorsz hiaba veszed at egy process folott az iranyitast ha sandboxban vagy vagy ahol le vagy korlatozva (chroot peldaul).

>Ennek semmi köze a túlcsordulásos >támadásokhoz. Ez ellen úgy lehet védekezni, >hogy vagy 100% hibátlan kódot írsz, vagy nem >futtatsz egyetlen processzt sem. :)

Ki mondta, hogy van koze? 100%-os kod nincs, de egeszen jol meg lehet kozeliteni. Igen, peldaul azzal hogy _szeparaltan_ es/vagy _sandboxban_ futtatod a program azon reszeit amik nem biztonsag-kritikusak. Ajanlom a least privilege elvet.

FIKA OFF

Amugy nem tudom miert irtad amit irtal de nagyon nem vagod mivan. Bocs, nem azert vagyok paraszt mert direkt flamebait volt az elozo postom hanem azert mert okosnak akarsz latszani, de nagyon tavol all toled a tema.

synapse

@webjúzer: szeritntem kevered a sandboxingot, és az egy process per tab fícsört...

nem műxik a java :|

@webjúzer
Nem beszélsz hülyeséget, de olvasd át még egyszer a posztot:

"szeparált memóriaterületen, egyfajta v*irtuális gépen fut*"

tehát sandboxingról van szó, az alkalmazások nem láthatják a fizikai memóriát, csak a saját virtuális területüket. Persze egy sandboxot is lehet szarul implementálni...

Segítsetek, ez mit jelent a Chrome névjegyében? "A jelen szoftver bizonyos részeit harmadik féltől licenceltük, az alábbi címen leírtak szerint: www.google.com/support/chrome/bin/answer.py?answer=100336
Hivatalos verzió 1583
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13"

És miért van az, hogy ilyenmappáim vannak a gépemen: C:\Program Files\Mozilla Thunderbird\chrome\ holott én nem telepítettem a Mozillát?

A Google Chrome tulajdonképpen Mozilla?

Ez is aranyos:

milw0rm.com/exploits/6355

Azért gógüléknek is van mit javítani még.

@formax
chrome-nak hívják a FF és a TB megjelenítő rétegét (javítsatok ki ha tévedek!), egyszerű névegyezésről van szó. Tehát a chrome az alkalmazások része, nem a Google Chrome nyúlt bele a Mozillás könyvtáraidba.

@synapse: Hol van a Windowsban chroot?

@buherator: Hogyan csinálsz Windowson kernel támogatás nélkül "sandboxot"?

Én úgy vettem észre a chrome nem épül be a kernelbe, tehát valódi sanbox sincs, legfeljebb logikai szinten, ami a kártékony kódot nem gátolja meg semmiben.

Szóval, hogy is csinálja azt a homokozót a chrome Windowson? :)

Nekem az is jó, ha valaki megmutatja a chrome forráskódjában. És akkor elhiszem. :)

@buherator: "szeparált memóriaterületen, egyfajta v*irtuális gépen fut*"


Akkor most csak olyan mintha de mégsem, vagy tényleg olyan? Én virtuális gépet sem találtam a forráskódban. Egyfajtát sem, meg tényleg azt sem.

Egyelőre ez egy logikai szeparáció lehet, ami majd idővel (mondjuk Windows 7) amikor majd lesz hozzá OS támogatás majd valóság is lehet. Egyszer majd. Addig csak marketing.

@webjúzer
A z egy fajtát azért írtam, mert nyilván nincs egy komplett virtuális környezet létrehozva, csak néhány szükséges feature (ha jól sejtem a fájlrendszer pl. nincs elszeparálva). Na persze ha létre van hozva...én nem néztem bele a forráskódba, csak a "marketingre" hagyatkoztam, de ha te utánajártál a dolognak, és le tudnád írni, hogy mit találtál, akkor akár egy külön posztot is szívesen szentelek a témára.

A te igazadat támasztja alá egyébként a fent belinkelt exploit, ami bedönti a komplett böngészőt, ugyanakkor már az IE8-cal kapcsolatban is lehetett olvasni ilyen sandboxing megoldásról, persze nyilván az MS-féle szöveget is célszerű kritikával fogadni.

"@synapse: Hol van a Windowsban chroot?"

HAHHAHAHAA En most operacios rendszerrol beszeltem :D Fikat felre teve biztosan meg lehet csinalni, gondolok itt a windows SOKKAL fejlettebb filerendszer acl-jeire. Mert ugye ott per user beallitod a jogokat mig linuxon csak usergroupother suxxsag van. Default policy: senki nem csinal semmit, chrome-usernek nem adsz explicit jogot. Game Over

"@buherator: Hogyan csinálsz Windowson kernel támogatás nélkül "sandboxot"?"

Szerintem kernel support nelkul is lehet sandboxot csinalni (bar per pill nem tudom hogyan). Nyilvan meg kell vedeni az oprendszer szolgaltatasait (syscallok, libek, stb), hogy csak egy jol definialt interface-en keresztul nyulhasson hozzajuk. Ott meg lehet szurni es atengedni ami legitim. Hogy ezt technikailag hogy csinalod meg azt nem tudom, mert a process az process. Ha valaki errol tud valami infot az irja meg legyenolyanszives ;)

"amikor majd lesz hozzá OS támogatás "

lol

synapse

Lehet hogy túlbonyolítjuk a kérdést:

Anélkül, hogy a technikai részletekbe belefolynánk tény, hogy Windowson is működik JVM, virtualizáció stb. Az ezek által szabott korlátok ugyan bizonyos esetekben átléphetőek, de azért mondhatjuk, hogy ezek a megoldások elég erős szeparációt képesek biztosítani az operációs rendszertől. Ezek alapján miért ne tehetné meg ugyanezt egy böngésző?

A JVM a 100% managelt kód. Ahogyan a .NET is. A Java nyelv (és a .NET) tervezésekor első lépésként definiáltak egy teljesen processzort, és annak egy teljesen új speciális utasításkészletet.

Első lépésként megírtak egy olyan szoftvert, ami emuláltja ezt a nem létező CPU-t, azaz emulációban futtatni képest azt a kitalált byte-kódot. A Java (és a :NET) fordító program pedig nem nem az Intel CPU utasításkészletére fordítja le a Java és C# forráskódot (mint ahogy a C/C++ fordító viszont igen), hanem ennek a kitalált CPU utasításkészletére fordítja le a kódot.

A Java ezért hordozható, mert ahol megírod azt a szoftvert (C/C++-ban) ami képes értelmezni és végrehajtani a kitalált CPU utasításkészletét, az képes lesz futtatni azt a byte-kódot. Így a Java és a .NET gyakorlatilag legfelső felhasználói szinten létrehoz egy "virtuális" gépet a VASTÓL kezdve, azaz a CPU-tól építkezve, az opercáiós rendszer szerepét meg átveszik a hatalmas szoftver könyvtár készlet amit "Managelt" nyelvekhez adnak. Így valódi szeparációt és valódi védelmet lehet megvalósítani. Ezt hívják menedzselt kódnak. Ilyen a Java és a .NET.

Azonban a Google böngészője C++ nyelven íródott, a fordító program pedig a gépben lévő Intel CPU utasításkészletére fordítja a kódot. Ezért csak az operációs rendszer támogatásával védhető meg és csak az operációs rendszer támogatásával lehet sandboxot csinálni. És hát minek csinált volna a Google egy új managelt rendszert, ha ott a Java meg a .NET (meg a Mono).

A Geckó egy köztes megoldást választott az XUL-el. A megjelenítő azaz GUI kód, az 100% Javascript és XHTML, CSS. Ami szintén jó megoldás lenne, ha a megjelenítő motor is Javascript lenne. De az sajnos C++.

Ami pedig a fájlrendszer ACL-t illeti, fájlokhoz hozzáférési jogokat lehet beállítani, de a az csak fájlokra vonatkozik, a túlcsordulásos támadás pedig a memóriában zajlik a futó processzek között, nem fájlok felülírásával. A vírusok már régóta nem úgy fertőznek, hogy közvetlenül módosítanak egy fájlt. Hiszen ott az ACL. Hanem előbb a memóriában megtámad egy másik processzt ami magasabb jogokkal fut, és aztán annak a kontextusából módosítja a fájokat és akkor lesz joga hozzá.

Másrészt, ha csak ACL-re hagyatkozunk. Tegyül fel, hogy baromi jól beállítasz ACL-el eyg fájlrendszert és feltételezzük, hogy az a biztonság záloga. Ez esetben miért kevésbé biztonságos egy Firefox egy Chrome-nál, hiszen mind a kettőt védi az ACL...

Az ACL-el sajnos processzekhez hozzáférési jogokat nem lehet beállítani. Linuxon erre való az SELinux, de Windows esetén erre nincs megoldás, ezért fejleszti gőzerővel a Microsoft a 100% managelt kódú Windowst. (nem a 7, az még natív lesz).

"És hát minek csinált volna a Google egy új managelt rendszert, ha ott a Java meg a .NET (meg a Mono)"

Én nem azt mondom hogy megcsinálta, hanem azt, hogy megcsinálhatta volna. Mint mondtam, én nem láttam a forrást, de ezek szerint ilyen szintű szeparáció ebben a konkrét esetben nem valósul meg. Ha viszont ez így van, akkor nem igazán tudom mire vélni ezt a virtual machine "hype-ot"...

Amit a webes javas .net-es reszrol leirtal az korrekt.

De!

"Ami pedig a fájlrendszer ACL-t illeti, fájlokhoz hozzáférési jogokat lehet beállítani, de a az csak fájlokra vonatkozik, a túlcsordulásos támadás pedig a memóriában zajlik a futó processzek között, nem fájlok felülírásával. A vírusok már régóta nem úgy fertőznek, hogy közvetlenül módosítanak egy fájlt. Hiszen ott az ACL. Hanem előbb a memóriában megtámad egy másik processzt ami magasabb jogokkal fut, és aztán annak a kontextusából módosítja a fájokat és akkor lesz joga hozzá."

Igen, a memoriaban zajlik, de egy processen belul (altalaban). Ezt nem lehet megakadalyozni. A virusok nem ugy fertoznek hogy megpatchelnek egy masik magasabb privilegiummal futo processt. Hallottal mar a protected mode-rol mint olyan? Userspace-kernelspace kulonbsegek, processor ring-ek megvannak?

Ha rendszergazda-kent (root) vagy beloginolva kkor van jogod ra, mezei juzerkent nincs: ugyanis egyik process sem baszogathatja semelyik masikat, csak a kernelen keresztul - pl.: ptrace() rootkent. ring3-ban futva general protection fault lesz abbol, ha olyan helyre nyul a process ahova nem szabadna. Ezt a kernel elkapja es a processnek jelzi (SIGTERM signal). ring0-ban (kernel) mindent megtehet, de itt csak es kizarolag a kernel fut. Ha rendszergazdakent fut a bongeszod akkor mindegy, mert windowson barmit megtehet, kernel modult beolt etc... Bar nem ismerem a wint, de linux alatt biztosan igy van.

Vegyuk azt az esetet, hogy az en sima felhasznalokent futo bongeszom felett atveszik az iranyitast. Ok. Olvashatjak, szerkeszthetik a filejaimat, stb de a rendszerrel nem tehetnek semmit. Ha nem az en juzeremmel fut a bongeszo, hanem egy masik privilegizalatlan juzerrel akkor pedig meg azt se. Ilyenkor nyilvan kulon foldert kell letrehoznom ahova lementem az adatokat. Jogot kell neki adni a filerendszer ezen reszere (cache, cookie, miegymast tudjon tarolni), de barmikor kompromittalodik semmi bajom nem lehet belole, mert ved a filerendszer. Ha letolrli az cache-em akkor nem izgulok. Cookie mar kenyesebb de meg mindig jobb mintha a /home repulne vagy az egesz rendszer. Ez a privilege separation.

"Másrészt, ha csak ACL-re hagyatkozunk. Tegyül fel, hogy baromi jól beállítasz ACL-el eyg fájlrendszert és feltételezzük, hogy az a biztonság záloga. Ez esetben miért kevésbé biztonságos egy Firefox egy Chrome-nál, hiszen mind a kettőt védi az ACL..."

Amigy egy user alatt fut minden process addig teljesen lenyegtelen.

"Az ACL-el sajnos processzekhez hozzáférési jogokat nem lehet beállítani. Linuxon erre való az SELinux, de Windows esetén erre nincs megoldás, ezért fejleszti gőzerővel a Microsoft a 100% managelt kódú Windowst. (nem a 7, az még natív lesz)."

Nem is kell, ket process ne nyulhasson egymashoz semmilyen korulmenyek kozott. Egymas memoriajat nem cseszegethetik, szignalt kuldhetnek, de azt elkaphatja, az elkaphatatlan szignalra(SIGKILL, SIGSTOP) nyilvan terminalasra vagy megallasra kenyszeritheto, de compromittalni nem lehet.

100% managelt-kod. Nezd meg a minixet. Egy syscall csak 160x lassabb rajta. De secure :)

Ez az oka tobbek kozt, hogy a linux monolitikus kernel (hibrid igazabol a modultoltes miatt), hogy C++-ban irjak a bongeszot es minden mast is. Java-ban, javascriptben meg lehet irni, biztonsagos is lesz viszont hasznalhatatlanul lassu. Mellesleg pedig lehet secure kodot irni ezekben az insecure nyelvekben is (djbdns, qmail, vsftpd, etc...). Csak modszertan kell hozza amit nem nagyon tanitanak.

synapse

@A virusok nem ugy fertoznek hogy megpatchelnek egy masik magasabb privilegiummal futo processt. Hallottal mar a protected mode-rol mint olyan? Userspace-kernelspace kulonbsegek, processor ring-ek megvannak?

Igen. Az Intel CPU 4 szintet támogat. Ebből a nulladikon fut a kernel (ntoskrn.exe) és a driverek (*.sys), minden más processz (*.exe) a 3. szinten fut, azaz AZONOS szinten. Windows és Linux esetén egyaránt. Tehát jelenleg 2008-ban, ha elindítasz egy Firefoxot és egy Word-ot, akkor AZONOS jogokkal, azonos CPU szinten futnak.

Windowsról beszélünk, mert a CHROME jelenleg csak Windowson fut.
www.codeproject.com/KB/threads/winspy.aspx

"Igen. Az Intel CPU 4 szintet támogat. Ebből a nulladikon fut a kernel (ntoskrn.exe) és a driverek (*.sys), minden más processz (*.exe) a 3. szinten fut, azaz AZONOS szinten. Windows és Linux esetén egyaránt. Tehát jelenleg 2008-ban, ha elindítasz egy Firefoxot és egy Word-ot, akkor AZONOS jogokkal, azonos CPU szinten futnak."

hu. Nincs tobb kerdesem.

Vannak a processor ringek. Meg vannak a processek. Ez a ketto az ket kulonbozo dolog. ring3-ban vannak megkotesek, ring0-ban nincsenek. ring3-ban fut tobb process, egymastol teljesen kulon, kulon juzerkent. Probalj meg valamit kiloni ami rendszergazdakent fut sima juzerrel taskmgr-bol. Nem fog menni. Hiaba azonos ring.

synapse

Mármint úgy értettem, hogy a CPU szemszögéből azonos jogokkal. Természetesen a processzek saját virtuális memóriában futnak, de nagyrészük azonos CPU ringen, így ezek egymás számára írhatóak, némi trükközéssel.

A token, ami egy operációs rendszerben leírja egy processz képességeit, az egy logikai szintű szeparáció. Amikor X tokennel rendelkező processz le szeretne "lőni" egy Y tokennel rendelkező processzt, akkor elmész az opercáiós rendszerhez, és megkéred, hogy legyél szíves nekem lelőni az Y tokennel bíró processzt. Mire az operációs rendszer közli, hogy ezt nem teszi meg neked, mert úgy döntött, hogy a te X tokened erre téged nem jogosít.

Tehát ki kéne kerülni az operációs rendszert, hogy lelőhessem az Y processzt. Ehhez a nulladik ringbe kellene kódot juttatni, de hiába kérem meg az OS-t, hogy töltse be nekem ezt a kódot a nulladik szintre, az X tokenem miatt nem teszi meg. De Y processznek megengedné az OS, pedig az is a 3. szinten fut.

Na ilyenkor jön a hack, kódot juttatsz az AZONOS ringben futó de más tokenne rendelkező processz memóriatartományába, és onnan kéred meg az OS-t, hogy töltse be a kódod a nulladik szintre. Akkor már megteszi, és ha már a nulladik ringen vagy, azt csinálsz amit akarsz azt OS-t megkerülve.

Így működnek a rootkitek. Linuxon is.

És ez azért lehetséges, mert minden felhasználó alkalmazás (a rendszergazdaként futók is, annak csak a logikai tokenje más), azonos CPU szinten fut, így a memória módosítható a processzek között.

"""És ez azért lehetséges, mert minden felhasználó alkalmazás (a rendszergazdaként futók is, annak csak a logikai tokenje más), azonos CPU szinten fut, így a memória módosítható a processzek között."""


Illetve a leggyakoribb módszer, a túlcsordulásos támadás, amikor a több logikai jogot tartalmazó tokennel futó processzben lévő hibát kihasználva juttatod be a kódot (akár távolról).

Vagy ennél szebb, amikor a kernelben (legalsó ringen) futó kódban található hibát közvetlenül használod ki, ezzel a módszerrel. A linux történetében is volt ilyen, egyszer egy a kernelben lévő TCP/IP hiba miatt távolról közvetlenül a nulladik ringbe lehetett kódot juttatni egy hibásan formázott TCP csomaggal.

Akkor lehetne egyet lépni előre, ha mondjuk a rendszer/rendszergazda tokennel rendelkező processzeket nem a 3. ringen, hanem mondjuk a második CPU ringben futtatná az OS. Minden más felhasználó jogokkal futó processzt pedig a 3. szinten. A kernel meg maradna a nulladikon. De valóságban ez nem így van. Linuxon sem.

"""És ez azért lehetséges, mert minden felhasználó alkalmazás (a rendszergazdaként futók is, annak csak a logikai tokenje más), azonos CPU szinten fut, így a memória módosítható a processzek között."""

Természetesen nem csettintésre mert abból segfault lenne. Kis trükközéssel és találékonysággal. Ezt csinálják a hackerek.

De a segfault az egy logikai védelem. Amikor a ring 3-ban, A processsz hozzáfér B processz virtuális memóriájához, akkor a CPU dob egy kivételt, amit az operációs rendszer memóriakezelő kódja elkap. A CPU nem azért dobja a kivételt, mert az azonos ringen ez tilos lenne, hanem, azért, hogy az OS logikai szinten eldönthesse, hogy ezt megengedi-e.

Tehát két ring 3. processz közül egyik piszkálja a másikat, jön a CPU kivétel, az OS pedig lefuttat egy szoftvert, amely ellenőrzi mindkét processz tokenjét (egy-egy bájthalmaz, szabad/nem szabad bitekkel) és az alapján - a szoftver - eldönti, hogy ezt megengedi-e vagy sem.

Tehát nem a CPU védi a rendszergazdaként futó processzt a felhasználóként futó processztől, hanem az operációs rendszer, memóriakezelő szoftvere.

És mint minden szoftver, vagy hibák vannak benne, vagy megkerülhető. Hogy melyik és hogyan, ez a hackerek dolga. :)

webjuzer: respect. egy par dolgot sikerult megertenem, ami eddig misztik kategoria volt. koszi. lesz min agyalnom, mert emberi modon irtad le a dolgot.

ez igaz a tobbiekre is a vita szempontjabol.

a ggl chrome amugy jo kezdemenyezes. semmi bajom az apple webkitjevel, en azert maradok az ff+opera kombonal, amig nem forr ki a dolog. bar akkor is csak second lesz. eddig meg csak problermakrol olvastam vele kapcsolatban.

a nagy teso mar annyira szerteagazo szolgaltataskinalattal rendelkezik, hogy hazon belul siman profilt epithet a felhasznalokrol.

"Na ilyenkor jön a hack, kódot juttatsz az AZONOS ringben futó de más tokenne rendelkező processz memóriatartományába, és onnan kéred meg az OS-t, hogy töltse be a kódod a nulladik szintre. Akkor már megteszi, és ha már a nulladik ringen vagy, azt csinálsz amit akarsz azt OS-t megkerülve."

Na ez atomnagy faszsag, nem irsz bele masik process memoriateruletere. Call gate-en (pl.: syscall) keresztul csinalhatsz extra dolgokat (mint filet nyitni, irni, olvasni, memoriat allokalni, etc...), ott pedig a kernel van aki eldonti, hogy jogosult vagy-e.

"Így működnek a rootkitek. Linuxon is."

Nem, altalaban /dev/kmem-et, /dev/mem -et patchelnek vagy betoltheto kernelmodulok. Ha nem kernel-rootkit hanem sima userspace akkor meg ptrace()-el bepatcheli magat egy masik processbe (nade itt a ptrace()-hez kernel kell ami csak akkor engedelyezi ezt, ha uid==0!);

"És ez azért lehetséges, mert minden felhasználó alkalmazás (a rendszergazdaként futók is, annak csak a logikai tokenje más), azonos CPU szinten fut, így a memória módosítható a processzek között."

PRO-TEC-TED MODE! Teljesen hulye vagy?

"Természetesen nem csettintésre mert abból segfault lenne. Kis trükközéssel és találékonysággal. Ezt csinálják a hackerek."

Na, latom kozben rajottel hogy nem ugy megy az.

"Tehát nem a CPU védi a rendszergazdaként futó processzt a felhasználóként futó processztől, hanem az operációs rendszer, memóriakezelő szoftvere."

Mondd meg kerlek, akkor mi is generalja a pagefaultot elso korben? IIIIGEN, a proci (MMU). Amit a kernel pagefault handler-e elkap es ellenorzi amit kell. Mert ugye nincs bemappelve A proc address space-ebe B proc page-e (hacsak nem sharedmem), ezert elsosorban pagefaultot fog generalni. Ugyanis linux alatt a page kikerulhetett swapre (vagy mas okbol nincs ott /demand paging/) es akkor a kernel pf handler-e betolti azt onnan. Ezert minden esetben a pf handler-hez fut be az ilyen exception. Ha mar az address space-ben benne van a page es az access nem stimmel rajta akkor az protection fault (szinten cpu dobja), amit a kernel csak kernel codepath-ben kezel (ugyanis usermodu process adress space-ebe nem kerulhet be ilyen invalid page)!

Remelem mostmar ertheto.

synapse

"webjuzer: respect. egy par dolgot sikerult megertenem, ami eddig misztik kategoria volt. koszi. lesz min agyalnom, mert emberi modon irtad le a dolgot."

NEMNEMNEM

Ez van amikor emberek hitelesen adjak elo a hulyeseget :( Olvass utana ne higyj el minden szart

synapse

@synapse

Elbeszélünk egymás mellett. Ugyanazt írod csak pepitában. Ami Windowson a WriteProcessMemory, az Linuxon a /dev/mem. stb. Én leírtam a Windows világot, te meg ugyanazt írod, csak Linux világban. Igen a kettő nem teljesen egyforma, csak a működési elv ugyanaz.

@synapse Ez van amikor emberek hitelesen adjak elo a hulyeseget :( Olvass utana ne higyj el minden szart

Ember. Te LInuxról beszélsz én meg Windowsról.

webjuzer:

x86 architekturarol beszelunk nem win-lin kulonbsegekrol. Es marpedig x86 architekturan protected modeban ugyanugy mukodik a ketto.

Ketlenem, hogy a windows kernel siman engedi egy privilegizalatlan processnek hogy barmelyik masik process memoriajaban turkaljon...

synapse

synapse: hatha hazaerek mar vegre akkor utanaolvasok. vagy lusta dog modjara kivarom a thread vegkifejletet :)

azert azt mindenki elismerte, hogy bizonyos tekintetben webjuzernek igaza van. attol fuggetlenul, hogy x86 arch- e vagy sem, szerintem (laikuskent) nem azonos a retegkezeles l/w. bar konnyen tevedhetek. azert erdekes vita.

"""Ketlenem, hogy a windows kernel siman engedi egy privilegizalatlan processnek hogy barmelyik masik process memoriajaban turkaljon...""

Nem engedi. Neked. Meg az átlag felhasználónak. De egy hacker máshogy áll hozzá. :) És neki a hold és a mars együttállásakor, engedi. Ennyi. Linuxon és szép számú rootkit létezik, majdnem annyi mint Windows esetén. A hacker ott kezdi, hogy találkozik a PHP által generált weboldaladdal. Megnézegeti a képeket, mert a szöveget ugye nem érti, aztán hozzáfog a buherához, 10 perc múlva már lesz neki remote shellje apache júzerként, további 10 perc után pedig már root lesz, és telepíti a rootkitet.

De szerinted ez nem lehetséges. Én ezt értem, csak a gyakorlat mást mutat. :)

Bár a link lehet, hogy elveszett a thread közben.

www.codeproject.com/KB/threads/winspy.aspx

III. CreateRemoteThread & WriteProcessMemory WinNT only all processes, including system services

Most nem arrol volt szo, hogy nem lehetseges, hanem hogy NORMAL_KORULMENYEK kozott nem igy mukodik. Azt allaitani, hogy "előbb a memóriában megtámad egy másik processzt ami magasabb jogokkal fut" egyszeruen abszurd, mert mashogy nem tudod tamadni, csak a filejait cseszegetheted (szignal nem jatszik, mert nem kuldhetsz neki, memoriajat nem manipulalhatod).

Marad a kernel amit lehet tamadni. A masik software-bol meg nem latsz semmit ugyebar. Ha megcsinalod, hogy www-data userrel felboritod a root-kent futo xterm-emet, akkor veszek neked egy rekesz sort, maradjunk ennyiben.

synapse

Akkor ennyiben maradunk, mert szerintem lehetséges az amit írtam, és én nem tartom abszurdnak.

Én nem foglalkozom a témával, de pár ezer ember él a földön akiknek máris indulhatnál a boltba sörér. :)

A CreateRemoteThread és a WriteProcessMemory kernel hívások. Tehát azt mondod, hogy a kernel segítségével bele tudsz írni másik processzbe...

Ez megfelel vagy keressek másikat?

media.weth2o.com/wp-content/uploads/2008/02/screenshot_ubuntu.png

A CreateRemoteThread és a WriteProcessMemory csak egy példa. Számos más lehetőség létezik, az eredeti téma pedig a túlcsordulásos támadás, csak aztán elúszott a thread. :)

Kerestem hozzá forráskódot is, hogy otthon is kipróbálhasd.

jolmos.blogspot.com/2008/02/linux-vmsplice-local-root-exploit.html

De a sört nem szeretem sajnos. :)

De azon senki nem vitatkozott, hogy túlcsordulásos támadás lehetséges, csak azon, hogy két processz nem tudja egymás memóriáját írni a kernel közbeiktatása nélkül. Erre pedig a példa igencsak rossz.

Ez egy localroot kernel exploit. Ez nem egy masik processbe injektal kozvetlenul barmit, hanem a kernel syscall interface hibaja miatt elteriti azt.

synapse

"hogy két processz nem tudja egymás memóriáját írni a kernel közbeiktatása nélkül."

Ezt nem vitatta szerintem senki. Szerintem arról volt szó, hogy ez ettől függetlenül lehetséges-e. Lehet, hogy linuxon nem (de inkább még csak nem derült ki), de én azt gondolom, hogy Windows esetén biztosan igen.

És ezért gondolom ezt, mert ezt a kernelben egy szoftver felügyeli és nem a CPU.

""És ezért gondolom ezt, mert ezt a kernelben egy szoftver felügyeli és nem a CPU.""

Mielőtt megint félreértené mindenki: igen a CPU is részt vesz benne, de ő csak szól, a döntést a szoftver hozza meg, hogy szabad vagy nem szabad.

"""Ez egy localroot kernel exploit. Ez nem egy masik processbe injektal kozvetlenul barmit, hanem a kernel syscall interface hibaja miatt elteriti azt."""


Ja mellesleg CPU ring 3.-ban futó szoftver módosít egy CPU ring 0-on futó kódot. És fentebb valaki azt írta, hogy ez is lehetetlen. :) Akkor most a CPU vigyáz vagy nem a CPU vigyáz? Mert ha a CPU vigyáz akkor miért számít, hogy a syscall-ban hiba van, hiszen a CPU-nak meg kéne akadályoznia a hozzáférést. De nem tette... Hát akkor kiderül, hogy ez is lehetséges.

"a mellesleg CPU ring 3.-ban futó szoftver módosít egy CPU ring 0-on futó kódot. És fentebb valaki azt írta, hogy ez is lehetetlen. :)"

Hol irtam en ezt? Te be vagy gombazva ember?

synapse

Jaaa, azt hiszem mar ertem hogy mi a felreertes targya. A masik programszal (a kernelthread) ATVESZI az adatot egy jol definialt interface-en keresztul a userspace programtol. Mivel igy csinal, szurni es ellenoriznie kellene az adatot, ami nem minden esetben van igy. En azt mondtam, hogy egy masik process memoriajat nem modosithatod (gondoltam egyertelmu, hogy annak tudta nelkul). Ha o direkt atveszi toled az adatot akkor az mar mas kerdes, az az o hibaja ha beborul tole. Ha nem mutat feled olyan interface-t ahol pofazhatsz neki akkor nem fogod tudni felboritani.

synapse

"""En azt mondtam, hogy egy masik process memoriajat nem modosithatod (gondoltam egyertelmu, hogy annak tudta nelkul)."""

mnin.blogspot.com/2007/05/injecting-code-into-privileged-win32.html

OK. Mivel sajnos működő demó kód most nincs kéznél, így egyelőre el kell fogadnom amit írsz.

Viszont az eredeti téma az volt, hogy a chrome virtualizációja csak marketing. :)

"First, it is necessary to adjust the token privileges of your program so that debugging (SE_PRIVILEGE_ENABLED) is allowed."

DEBUG MODE! Mit pofaztam idaig? ptrace()? HEEEE? Kernelbol belenyulni a masik processbe? Nem process-masikprocess interakciorol van szo am! proc-kern-masikproc interakciorol! Nem ugyanaz!

De hat vegul is hagyd figyelmen kivul amit irok es helyette mormold a sajat faszsagaidat az orokkevalosagig hogy akkor is a tied legyen az utolso szo, hogy a @%&!$(#%)!^#)!#!!!!!!

synapse

BOCS. Azt linket tényleg nem olvastam végig. Sorry.

synapse te miert vagy ilyen aggressziv? az emberek hajlamosabbak elfogadni amit mondasz, ha nem ilyen gorombaskodva teszed, csak egy jotanacs.

egyebirant meghajolok a tudasotok elott, en tanultam belole.

Emberek!
Én annyira kisgyerek vagyok ehhez a témához, hogy csak a névelőket értettem a vitából :)

De lenyűgöző volt ez a vita és respect mindkét félnek a tudásáért!

Webjúzernek a stílusért is :)

akkor vegul is ket dologrol hullot le a lepel nagyjabol. egyreszt webjuzernek es synapsenek is igaza van. de synapsenek jobban. masreszt, hogy a chromeot jobb egyelore mellozni, mert a szeparalt processek velhetoen csak reklamfogas reszei. agyonhypeolt brozi, mint az android telo szinten a nagy tesotol. epito volt vegigolvasni. lesz minek utananeznem a heten. tnx

@.Andrei
A szeparált processzek léteznek, nézd meg a feladatkezelőt (vagy ps), csak a sandboxing nincs megvalósítva (legalábbis webjúzer szerint)

kutyacica:

Csak. Es bunko is vagyok, bar ez szerintem feltunt

synapse