[0day] Új időszámítás: Grsecurity 4.5 kernel, egyedülálló PaX RAP védelemmel

Az IT ipar évtizedek óta küzd a puffer túlcsordulás és a kapcsolódó memóriakorrupciós hibákkal. Ugyan ezek a problémák még jó ideig velünk is maradnak, azonban egyre fontosabb szerepet tölt be az ezekhez köthető biztonsági problémák kihasználásának ellehetetlenítése. A 16 éve fejlesztés alatt álló PaX védelem ezeknek a hibáknak a kihasználását hivatott ellehetetleníteni, vagy legalábbis annyira megnehezíteni, hogy a támadóknak már ne érje meg az ilyen tipusú sérülékenységeknek a kihasználására erőforrást fordítani. Ahogy a hadi iparban, úgy a manapság zajló "kiber" háborúban is a közgazdaságtan a fő mozgatórugója azoknak a fegyvereknek, amelyeket a virtuális térben arra használnak, hogy a célpont infrastruktúrájába behatolhassanak, vagy a már megszerzett területeken a hatókört kiszélesíthessék. Ezeknek az "exploit" elnevezéssel illetett támadókódoknak az értéke annak függvényében változik, hogy a támadásra kiszemelt rendszereket mennyire könnyű sikeresen megtámadni. Egy elhanyagolt, évek óta nem frissített általános operációs rendszeren elérhető szolgáltatásokat sokkal kisebb erőforrással lehet sikeresen megtámadni, mint egy naprakészen tartott, proaktív biztonsági elemekkel védett lebiztosított rendszert.

A PaX védelmi patch ennek az elgondolásnak a mentén próbálja a támadások cost-benefit arányát olyan szinten elmozdítani, hogy a sikeres támadásokhoz jóval több időre és ezáltal pénzre legyen szükség. Ennek köszönhetően egy sérülékenység megjelenésekor a rendszerüzemeltetőknek több idejük marad a már publikussá vált sebezhetőségek befoltozására és a levédett rendszerek nagyobb valószínűséggel állnak ellen a nem ismert, nulladik napi támadásoknak is. Ezeket az exploit mitigációs technikákat manapság már széles körben alkalmazzák, nem csupán a szoftver, de mostanra már a hardvergyártók is. Azokat az innovációkat, amelyeket a PaX több mint egy évtizede szoftveresen valósított meg, jelenleg az Intel és az ARM processzorokban külön funkcionális, vagy utasításkészlet bővítéssel oldanak meg, így általánosságban elmondható, hogy az újabb rendszerekkel könnyebben implementálhatók biztonságosabb környezetek.

Ugyan a memóriakorrupciós hibák kihasználásához egyre szofisztikáltabb támadási módszerekre van szükség, az exploit írok lépést tartva a védelmi megoldásokkal, szintén egyre okosabb módszereket találnak ki. Míg régebben egy puffer túlcsordulásos hiba esetén az adatok helyére injektált gépi kódokkal könnyedén át lehetett venni az irányítást a rendszerek felett, addig a mai memóriakorlátozásoknak köszönhetően az adatokat tartalmazó memóriaterületeken már nem hajthatók végre kódok. Ezeket az ötleteket egykor a PaX még szoftveres emulációval, memória szegmentálással és rengeteg kreatív trükkel valósította meg. A mai processzorokban azonban már évek óta elérhető hardveresen a nem végrehajtható memórialapok felcímkézésének lehetősége. A legújabb fejlesztések pedig már olyan prevenciós technikákat tartalmaznak, amelyek a rendszermagok önvédelmét segítik elő, így egy kernelben található biztonsági hibának kihasználásával a támadók nem képesek a felhasználói memóriaterületen lévő kódokat magas privilégiummal végrehajtani (Intel SMEP, ARM PXN), vagy egyáltalán adatként felhasználni (Intel SMAP, ARM PAN).

A támadók azonban már egy ideje olyan módszereket alkalmaznak, ahol nem új, hanem a memóriacímtérben már létező kódok egyedi sorrendben való végrehajtásával érik el a kívánt eredményt. Ezeket a támadási formákat hívják ROP (Return oriented programming), JOP (Jump oriented programming) rövidítéssel. Ezekre a támadási formákra eddig nem volt igazán hatékony védelem, a legtöbb ilyen CFI (Control Flow Integrity) megoldás vagy kijátszható volt, vagy nagyon nagy teljesítményveszteséggel járt. A PaX-ban bemutatkozó RAP védelem egy sokéves fejlesztés eredménye, amely erre a problémára igyekszik hatékony megoldást garantálni. Az eljárás egy GCC plugin formájában érkezik, amely bármilyen C és C++ nyelven írt forráskód lefordításával olyan egyedi ellenőrzésekkel felvértezett program binárist segít előállítani, amely ellenáll a ROP támadásoknak. Az új védelmi mechanizmus a Grsecurity legújabb test patchében mutatkozott be és a Linux kernel védhető le segítségével. A grsec patch alkalmazása után a sok egyéb PaX és Grsecurity biztonsági funkció mellett megtalálható az új RAP védelem is:

Prevent code reuse attacks (NEW)

Bekapcsolásával a fordítási folyamatba beépül a PaX gcc plugin és a ROP támadásoknak is ellenálló kernel bináris keletkezik. Ez a demo verzió hivatott bizonyítani az eljárás működőképességét és hatékony védelmét, de számos extra funkciót, C++ támogatást, teljesítmény optimalizációt és fordításidejű statikus kódanalízist nem tartalmaz. Ezeket a Grsecurity mögött álló amerikai Open Source Security Inc. cég teszi elérhetővé az érdeklődők számára.

A bejelentés itt található:

https://grsecurity.net/rap_announce.php

Gyakran ismételt kérdések:

https://grsecurity.net/rap_faq.php

RAP védelemmel kiterjesztett PaX patch a Linux 4.5 kernelhez innen tölthető le:

https://grsecurity.net/~paxguy1/pax-linux-4.5.2-test1.patch

A PaX patchet tartalmazó, további biztonsági funkciókat is szállító biztonsági megoldás itt érhető el:

https://grsecurity.net/download.php#test

Hozzászólások

W. O. W.!

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

(nagyon off) Vajon mennyi erőfeszítéssel lehetne ilyen kiegészítést LLVM/Clang-hoz írni?

Van próbálkozás CFI-re ott is az eredeti fejlesztők részéről, de nagyon gyatra mind biztonsági, mind overhead szempontjából.

Érdekesség viszont, hogy eredetileg LLVM/Clang alapokon lett elkezdve a PaX RAP fejlesztés is, csak amikor a gcc-ben megjelent a plugin támogatás, akkor leváltásra került. Sajnos akkoriban az is komoly munkát igényelt, hogy Clang segítségével egyáltalán lefordítható legyen a Linux kernel, ezért egyszerűbb volt gcc pluginra átállni, amikor arra lehetőség adódott.

Ennek ellenére távlati tervekben nem kizárt, hogy licenc okokból lesz LLVM/Clang verzió is PaX RAP védelemből.

Minek a rövidítése a RAP? Vagy csak jól hangzik, mint a RIP ROP?

Szerk.
Megtaláltam: return address protection

Ez ugyanaz a csapat aki egy a kernelpatch-ük által injektált szarvashibát megtaláló és kitwittelő Hector Martint bannolták a saját twitter feedjükről és kitiltották a saját szerverükről?
Jahm, és még azokat is bannolták akik likeolták vagy retweetelték a hibát?

Kíváncsi lennék, hogy ezután ki mer hibát keresni és publikálni a védelmi rendszerükben. ;)

Forrás:
http://www.theregister.co.uk/2016/04/27/linux_security_bug_report_row/
https://www.reddit.com/r/programming/comments/4gn0dr/hector_martin_on_t…

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

A valóságban az történt, hogy a srác bejelentett egy hibát (a valóságban egyébként egy fals pozitív problémát, amely a gcc korai optimalizációja miatt jön elő a size overflow plugin használata mellett). Ezt a bejelentést megköszönte a size overflow fejlesztője ( https://forums.grsecurity.net/viewtopic.php?t=4342&p=16222 ), de nem sikerült elsőre megfelelően átírni az érintett kódterületet, hogy a hamis riasztás megszűnjön.

Erre a srác széttrollkodta twitteren az egész témát és úgy adta elő, mintha a világ legnagyobb biztonsági hibáját találta volna meg. Hatalmas hadjáratot csinált a srác és elérte, hogy rengeteg hasonlóan hozzá nem értő retweetelje a dolgot, a helyzet valódi ismerete nélkül. Ezt megelégelve spender kitiltotta a srácot és az összes többi trollt, akik ezen rugóztak.

Lehet túlreagálta spender, de teljesen megértem, hogy egy idő után már megunta a dolgot. Én is sokszor hiába tépem a számat egy adott témában, nem értik meg egyesek és hozzáértés nélkül megy az okoskodás...

Nah, kicsit árnyaljuk azt a képet, Hector saját szavaival:
"grsecurity is a security-oriented patch set for the Linux kernel. It includes a rather temperamental compiler plugin that tries to detect integer truncation and overflow bugs. Unfortunately, it often reports false positives, and such reports crash all or part of your kernel (paranoia, security before uptime).

One such false positive in the Linux TTY layer can be triggered by writing a bunch of data into a TTY at once. This can be done using the above command (script allocates a pseudo TTY), or simply by pasting a bunch of text into a terminal window (how I originally found it).

Another user hit this first, and reported it. The grsecurity devs tried to fix it (work around the false positive) by changing the type of a bunch of variables from int (signed 32-bit) to size_t (unsigned 64-bit on 64-bit machines). Unfortunately, the code very obviously has the variable going negative under some circumstances, so the patch, instead of fixing the false positive, actually introduced a real integer underflow bug, that was caught by the compiler plugin (now no longer a false positive!), and the kernel still crashed. Worse, if you build without the plugin enabled, the code is now subtly broken.

I then hit the bug, figured out what happened, reported it, and found it ridiculous so I tweeted it. They should've never let that patch go in without effective review and testing.
"
(Forrás: https://www.reddit.com/r/programming/comments/4gn0dr/hector_martin_on_t…)

Alapvetően, az zavar, hogy false pozitív hibából valósat csináltak, nem is kicsit. A másik, hogy fele ekkora hírverés lett belőle, ha nem reagálják túl. Ha profi csapat képét akarják mutatni, akkor nem bannolunk, meg kitiltjuk az illetőt, hanem küldünk neki egy láda sört.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Abszolút offtopic ez most egyébként az eredeti téma szempontjából, de azért leírom az én véleményemet a történetről:

- "Unfortunately, it often reports false positives, and such reports crash all or part of your kernel"

Először is tudnia kellene, hogy hogyan működik és hogyan érdemes használnia ezt a size overflow plugint. Ezért van minden dokumentálva és ezért nem javasolja a csapat éles használatra ezt a plugint (legalábbis rizikóanalízis nélkül), mert ilyen fals pozitív hibákat előidézhet. Ezt aki érti és foglalkozik a témával az tudja. A srác viszont láthatólag nem foglalkozott vele, ellenben teleharsogta vele a twittert és a sajtót, hogy ő most mekkora biztonsági hibát talált.

Ha utána olvasott volna, akor tudott volna pl. arról is, hogy egyébként létezik egy pax_size_overflow_report_only opció, amely kizárólag loggolja a detektált hibákat és nem küldi panicba a rendszert. Lásd még Linux kernel alapbeállításai között is található panic_on_oops sysctl, amelyel szabályozható, hogy kernel által detektált problémák esetén próbáljon helyreállni a kernel, vagy mindenképp panicoljon. Ezek szabályozása az üzemeltetők feladata, ahogy az ő döntésüktől függ az is, hogy milyen komponenseket használnak fel a grsec patchből éles környezetben.

- "actually introduced a real integer underflow bug, that was caught by the compiler plugin"

A "real integer underflow bug" kifejezés megint félreérthető és remekül lehet vele manipulálni a felületes olvasókat, ahogy az előző kijelentésével is. A valóságban az előidézett integer alulcsordulásnak semmiféle biztonsági vonzata nem keletkezett (kb. annyi történt, hogy ennek következtében nem beepelt a tty amikor megtelt, vagy valami hasonló nem kritikus probléma). A size overflow plugin azonban pont az ilyen alul- és felülcsordulásokra készült és az ilyen jellegű problémák felderítésére alkalmas. Ezek a túlcsordulások azonban ahogy az előbb is írtam nem feltétlenül jelentenek valódi biztonsági problémát, ezért a szakértők általi felülvizsgálatra szorulnak. A plugin azonban nem tudja eldönteni, hogy az a csordulás biztonsági probléma vagy sem, ezért hívja meg a kernel panicot a hiba környezetének loggolása után (vagy csak loggolja és fut tovább, amennyiben a pax_size_overflow_report_only opció van használatban).

Lényegében a plugin jól vizsgázott és rendesen lenaplózta az egyébként fals pozitív hibát. Mivel a srác nem ért hozzá és ész nélkül bekapcsolgatott mindent a saját kernel konfigjában, ezért ő ezt DoS támadásnak vette, mert a size overflow plugin nála szépen kernel panicot hívott, amikor detektálta a csordulást. Ezt hívja ő folyamatosan, de tévesen "crash"-nek, pedig itt egy szabályos függvényhívás történik, teljesen stabil környezetben és kontextusban...

Alapvetően, az zavar, hogy false pozitív hibából valósat csináltak, nem is kicsit.

Ahogy az előbb leírtam, valódi biztonsági hiba nem keletkezett. A srác rosszul értelmezte a kódot, de cserébe teleharsogta vele a médiát. A korábbi posztomban linkelt fórum bejegyzésben PaXTeam elmagyarázta részletesen neki, hogy hol tévedett és miért nincs igaza, de ezzel már nem foglalkozott. Egyértelműen szenzációkeltés volt a srác érdeke.

https://forums.grsecurity.net/viewtopic.php?t=4342&p=16222#p16224

Ha profi csapat képét akarják mutatni, akkor nem bannolunk, meg kitiltjuk az illetőt, hanem küldünk neki egy láda sört

Ez így van. Azonban amikor azt látod, hogy többszöri elmagyarázás után is csak a FUD keltés megy és a trollkodás, akkor hamar rájössz, hogy nem tudsz jó képet vágni a dologhoz.

Én akárhányszor jelentettem hibát náluk, azt mindig korrekten kezelték és a changelogban is megemlítettek, mint hibabejelentőt, vagy patch beküldőt. Sose tiltottak ki, ahogy több száz más hibabejelentőt sem. Egyedül ezt a srácot. Vajon miért?

Ahogy mások is megjegyezték a twitteren, a srác a szenzációkeltésével sikeresen elérte, hogy több száz like és retweetje legyen, miközben azzal nem foglalkozott, hogy az adott funkció kifejezetten nem javasolt éles használatra rizikóanalízis nélkül.

Miután spender megunta a trollkodást és kibanolta, utána pedig eljátszotta hipokrita módon azt, hogy ő nem gondolta, hogy ekkora balhé lesz belőle, hogy még bulvárhírt is kreálnak róla. Nem ő felelős, ő csupán egy ártatlan hibabejelentő!

Egyébként ettól függetlenül is az a véleményem, hogy undorító ez a twitterező és facebookozó társadalom. Az embereket like-vadász, szenzációkereső, álszent és képmutató bulvárgyárakká alacsonyítja. Sokan mindent megtesznek azért, hogy egyel több like és retweet érkezzen a szaros írásaikra, függetlenül attól, hogy mennyi azoknak a valódi értékük vagy igazságtartalmuk.

Persze mit várunk abban a korban, ahol teljesítmény nélküli hírességek ("celebek") akasztják le a legtöbb követőt és rajongót...

"(kb. annyi történt, hogy ennek következtében nem beepelt a tty amikor megtelt, vagy valami hasonló nem kritikus probléma)."
How to panic a current @grsecurity kernel as any user... Végülis, mikor elpánikol a kernel, utána nem beepel a tty... Ez tényleg nem súlyos biztonság tekintetében. Egy elpánikolt kernelű gép valóban bitonságos.

Egy entitásnak, csoportnak, különösen ha az professzionálisnak akar tűnni, nincsenek érzései, nincsenek érzelmei, ahogy azokat épp adott pillanatban képviselő embereknek sem. Nem gurulhat el a gyógyszere, nem kezdhet ámokfutásba.
Azzal, hogy spenderék, hisztis picsaként bannolgatni kezdtek, pont azt a félisteni mítoszt taposták páros lábbal a földbe, ami minden securityvel foglalkozó informatikus álma. A security, legyen szó crackerekről, vagy épp biztonsági megoldások fejlesztőiről, PR részről semmi másról szól, mint felülemelkedni a plebs programozókon azáltal, hogy az ő hibáikat javítják vagy épp használják ki és ezáltal mutatják ki szakmai felkészültségüket és tudásukat.

Ha tudják milyenek a twitterező és facebookozó társadalom, akkor miért etetik őket?

Hmmm, ha úgy vesszük sokszor a securityvel foglalkozók is ilyen celebek. Mert más kismillió szoftverkomponensben egy hibásat találni és utána véres kardként körbehordozni, és más kismillió szoftverkomponenst hibátlanul megalkotni.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Végülis, mikor elpánikol a kernel, utána nem beepel a tty... Ez tényleg nem súlyos biztonság tekintetében. Egy elpánikolt kernelű gép valóban bitonságos

Nem tudom elolvastad-e amiket még írtam. A kernel panicot a size overflow plugin hívta meg, mert nem report-only módban használta. Ezt a plugint nem javasolják használni éles környezetben előzetes tesztelés és risk analysis nélkül, mert ilyen fals pozitív riasztásokat okoz. Én is futottam bele néhányba, jelentettem és kivizsgálták. Ezt a plugint akkor szabad csak bekapcsolni, ha előtte megbizonyosodtál róla, hogy a saját környezetedben nem okoz hamis riasztásokat, valamint egy potenciális kernel panic nem okoz szolgáltatás kiesést. Cserébe egy alaposan kitesztelt és jól felépített infrastruktúrában meg lehet vele csípni olyan APT támadásokat is, amelyeket más esetekben nem lehetne. Ezt kell mérlegelnie, ha valaki használja ezt a komponenst.

A Grsecurity patchet nem lehet ész nélkül úgy használni, hogy az egyszeri user gondolkodás nélkül bekapcsolgat mindent a kernel configban és azt hiszi, hogy ettől már biztonságos lesz. Rengeteg beállítás pont ellenkezőleg, kontraproduktív, azaz ha bekapcsolja a user, akkor pont hogy gyengíti a védelmet, nem pedig erősíti. Emiatt kell elolvasni a dokumentációt és konzultálni hozzáértőkkel arról, hogy hogyan érdemes bevezetni saját rendszereken, infrastruktúrában.

Sokan hozzáértés nélkül bekapcsolgatnak minden funkciót, aztán utána hisztiznek, hogy kernel panicol a rendszer. Ez nem a Grsecurity hibája, hanem azoké a felhasználóké, akik nem olvasnak utána és ész nélkül kapcsolgatnak be mindent.

Ennyi erővel lehetne amiatt is riadót fújni, hogy simán a vanilla kernelben található egyes funkciók bekapcsolásától kernel panicol a rendszer, vagy akár be se bootol, vagy csak egy maggal és nagyon lassan (pl. kmemcheck). Ennél mégis jobban érzed gondolom, hogy mennyire abszurd lenne cikkezni miatta a The Registeren, hogy bizonyos kernel config mellett kernel panicol a rendszer.

Azzal, hogy spenderék, hisztis picsaként bannolgatni kezdtek

Ha megnézed a srác többi twitter bejegyzését, akkor láthatod, hogy kifejezetten erre játszott rá. Feljött a #grsecurity IRC csatornára is trollkodni, aztán amikor spender kidobta onnan is, akkor utána sietősen twittelte screenshotokkal az esetet, hogy őt üldözik. Miközben ő kezdett el mindenhol balhézni. Ha elolvastad a már két alkalommal is linkelt fórum bejegyzést, akkor láthatod, hogy teljesen korrekten és normálisan volt kezelve a hibabejelentése. A hisztizést ő kezdte el és nem lehetett neki elmagyarázni, hogy nincs igaza, folytatta a hadjáratot a Grsecurity ellen, mert az bizonyos beállítások mellett kernel panicot hív.

Ha valaki tökön lövi magát egy sörétes puskával, mert nem tudja hogyan kell használni, attól még nem a puska a hibás.

A sörétes puska hasonlatod jó, csak hibás. Ugyanis a legtöbb IT tool olyan sörétes puska, amin kismillió bizgentyű és kallantyú van, aminek az állítgatásával lábon tudod magad lőni. A sörétes puskán meg csak egy van, és van benne olyan védelmi mechanizmus, ami pont az önlábonlövés ellen véd. Egy jól megírt security patchnél tervezési elvnek kell lennie, hogy a felhasználó ne tudja magát lábon lőni.
Egy mezei rendszergazdától ne várjuk el, hogy millió plusz egy kapcsolót ismerjen. Vagy nekik szánjuk és akkor kihagyjuk/elzárjuk ezeket a kapcsolókat (lásd: developement release/production release), vagy nem dobjuk ki publikusba a kódot, hanem csakis megfelelő feng-suizó embereken át terjesztjük. Az utóbbi viszont elég veszélyes, lévén akkor más felelősségvállalási szintek vannak...

Egy vanilla kernelbe a default konfig olyan, hogy az esetek 90%-ban csont nélkül lehet működő kernelt előállítani.

A másik, hogy nagyon hibás szemléletnek tartom a kernel elpánikoltatását a biztonság nevében. Egy DOS támadás esetén, emiatt, pont triviális hibák kihasználásával is célt érhet a támadó, pont egy biztonságos kernelnél.

Igen. Továbbra is tartom, ha nem etetik a trollt, nem lesz belőle balhé. TheReg-nek is azért lépte át az ingerküszöbét, mert dráma lett belőle.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

„Egy mezei rendszergazdától ne várjuk el, hogy millió plusz egy kapcsolót ismerjen.”

Akkor a mezei rendszergazda olvassa el a dokumentációt, vagy ne használja a Grsecurity-t, esetleg kérjen/fizessen meg valakit, aki megfelelően beállítja.
Elolvastam a a linkelt anyagokat, teljesen egyetértek Hungerrel.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Ez az egész emlékeztet arra amikor a debian-nál az openssh kulcsgenerátorára ráengedték a valgrind-et aztán reklamáltak, hogy "nem jó, mee' az az izé csipog hogy nem jóóó". Hiába próbálták elmagyarázni, hogy: de itt ez most OK, a vége egy csomó szar kulcs lett, mert a csomagkarbantartó kijavította fű alatt, hogy a valgrind ne csipogjon.

Értem én, hogy ha egy átlagembernek azt mondod, hogy ezt entrópia növelés miatt kell, akkor nem fogja megérteni. De könyörgöm az ilyen ne tartson karban ilyen csomagot. Ha mégis akkor amikor válaszolnak neki legalább nézzen utána mit is írtak.

A valgrind egy jó tool, de arra kéne használni amire való. A kernelkapcsoló mellet is ott van (gondolom) a help-ben, hogy: IF UNSURE SAY NO (lehet, hogy ez nem véletlen?).

"Hiába próbálták elmagyarázni, hogy: de itt ez most OK"

Kik és hol próbálták ezt hiába elmagyarázni?
http://marc.info/?l=openssl-dev&m=114652287210110&w=2
A debianos figura kérdésére egy válasz érkezett @openssl.org-os emailcímről, és még az is azt mondta, hogy "If it helps with debugging, I'm in favor of removing them."

"If it helps with debugging, I'm in favor of removing them."

Azt érted ugye, hogy azt mondta hogy:nyugodtan eltávolítható a _debugoláshoz_. Nem azt, hogy az éles felhasználáshoz az a pár sor nem kell.

Meg is mondták neki, hogy ha valgrinddel akar _hibát ketesni_ akkor fordítsa hibakereséshez -DPURIFY=1 paraméterrel. Mellesleg így ugye nem is kell kikommentelni semmit.

Az hogy ezek után Kurt kikommentelte a sort és így készítette a Debianhoz a csomagot az nem az openssl fejlesztőinek a hibája.

"Azt érted ugye, hogy azt mondta hogy:nyugodtan eltávolítható a _debugoláshoz_."

A "debugoláshoz"-t csat te emelted ki, az @openssl.org-os figura nem, így egyáltalán nem egyértelmű. Főleg azt a megjegyzését követően, hogy az inicializálatlan memóriából való olvasás nem sok entrópiát jelent.

Egy mezei rendszergazdától ne várjuk el, hogy millió plusz egy kapcsolót ismerjen

Nem kell ismernie, felkérhet egy szakértőt rá, aki ismeri. Akár a Grsecurity csapata is szívesen segít a saját infrastruktúrán való bevezetésben.

Vagy nekik szánjuk és akkor kihagyjuk/elzárjuk ezeket a kapcsolókat

Azt azért érzed, hogy éppen arról beszélgetünk, hogy saját egyedi kernelt fordít az a "rendszergazda" és azt próbálod megmagyarázni, hogy a kernel configban ne lehessen ezeket beállítani. Ugye tudod mennyi kernel hacking és debugging eszköz érhető el a vanilla kernelben is, amelyek szintén kernel panicot okozhatnak? Akkor Linusék azokat is távolítsák el, mert egyesek utánajárás nélkül vakon bekapcsolhatják és lábon lőhetik vele magukat?

hanem csakis megfelelő feng-suizó embereken át terjesztjük

Ahogy írtam, felkérhet egy szakértőt. Senki se mondta, hogy a fénymásolókat karbantartó rendszergazdának is értenie kell ezekhez a dolgokhoz. Ha viszont ész nélkül elkezdi használni és lábon lövi magát vele, akkor azért ne a Grsecurity fejlesztők legyenek a felelősek...

A másik, hogy nagyon hibás szemléletnek tartom a kernel elpánikoltatását a biztonság nevében. Egy DOS támadás esetén, emiatt, pont triviális hibák kihasználásával is célt érhet a támadó, pont egy biztonságos kernelnél.

Itt most arról az esetről beszélünk, hogy a támadók már bejutottak a szerverre és rootot szeretnének szerezni egy privilégium eszkalációs kernel exploittal. Dönthetsz: vagy folyamatban lévő lokális támadást detektálva azonnal leállítod a rendszert, hogy megelőzd a sikeres root szerzést (kernel panic), vagy lenaplózod a próbálkozást és hagyod, hogy tovább próbálkozzon amíg vagy ő sikerrel jár, vagy te észreveszed a logban az eseményt (veszélyes ötlet, de ott van a report-only mód, amely használata esetén ezt is megteheted).

Amikor már lokálisan benn vannak a szervereden és ismernek egy kernel hibát, akkor a DoS támadást nem tudod megúszni. Akár report-only módban is megtehetik azt, hogy végtelenciklusban triggerelik az adott kernel hibát annyira, hogy csak a loggolással legyen elfoglalva a rendszer.

De lássuk be, a DoS támadásra ennél sokkal egyszerűbb megoldások léteznek. Ha valaki már bejutott a rendszeredbe, akkor nem DoS támadást akar elkövetni...

Igen. Továbbra is tartom, ha nem etetik a trollt, nem lesz belőle balhé.

Amikor már nem etették a trollt, akkor is még feljött az IRC csatornára kekeckedni.

Lehet itt most utólag okoskodni a teljes történet ismerete nélkül, csak butaságnak veszi ki magát.

TheReg-nek is azért lépte át az ingerküszöbét, mert dráma lett belőle.

Normális újságíró ismeri azt a régi mondást, hogy "Audiatur et altera pars", azaz hallgattassék meg a másik fél is. Ezt a The Registers újságírója nem tartotta be.

A szakértőségnek van egy olyan árnyoldala, különösen ha adatbiztonságról van szó, hogy felelősségvállalással jár. Millió plusz egy olyan embert lehet találni, aki megmondja a tutit, hogy miképp kell biztonságossá tenni egy szervert vagy egy adatközpontot, de amikor ott áll a szerződésben, hogy X összegig felelősség vagy kötbér terheli őket, máris nem olyan nagy szakértők.
Pl. a grsecurity milyen felelősséget vállal?

Nah lassítsunk. Vegyünk példának okáért egy authentikációs szervert, amin fut egy front-end. Ha a front-end lehal, akkor a szerver, az újraindulásáig megfogja a többi szerveren futó folyamatokat. Namost, ha biztonságossá tesszük a kernelpánikoltatás logikája mentén az authentikációs szerverünket, akkor ha a front-endben egy olyan bug van amit a biztonsági patch false pozitívan azonosít és elpánikoltatja a kernelt, akkor mindenféle privilégiumszint emelése nélkül be lehet avatkozni a rendszer működésébe. Példának okáért authentikáció nélkül processzeket indítani, mert nem lesz ami megfogja a többi szerveren a folyamatokat. Hogy ez egy baromira rossz architektúra tervezés? Meglehet. De a világ tele van rosszabbnál rosszabbul összerakott rendszerekkel.
Egy hackernek nem csak adatszerzés lehet a célja. Lehet épp a hálózat elemeinek működésének a befolyásolása. Egy logokon keresztüli DOS támadás nyomokat hagy.

TheReg még ha bulváros is a stílusa elég komoly oldal és itt pusztán csak a szituáció túlreagálása elég volt a hírértékhez. Mikor pusztán retweetért és likeolásért tiltanak ki embereket egy twitter feedről, az olyan szintű ovisság, amire az üzleti életben nincs elfogadható magyarázat.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

de amikor ott áll a szerződésben, hogy X összegig felelősség vagy kötbér terheli őket, máris nem olyan nagy szakértők.

Nem tudom ez a kijelentésed honnan ered, van-e erről bármiféle statisztikád, releváns információd, vagy csak jól hangzik és ezért leírtad, mert konkrétan vállaltam már én is ilyen munkát kötbérrel, pedig nem gondolom magam akkora szakértőnek a témában, mint amilyen a Grsecurity mögött álló Brad Spengler, vagy a PaX Team mögött álló pipacs.

Pl. a grsecurity milyen felelősséget vállal?

Kérdezd meg tőlük.

authentikációs szervert, amin fut egy front-end. Ha a front-end lehal, akkor a szerver, az újraindulásáig megfogja a többi szerveren futó folyamatokat

Tehát nincs redundancia az authentikációs szervernél és ha valakinek lokális hozzáférése van arra a szerverre, akkor elérhetetlenné tudja tenni, feltéve, hogy a béna felépítés ellenére viszont van annyira penge, hogy használ PaX kernelt, de nem report-only módban fut a size-overflow védelem.

Ugye nem baj, ha ezt a képzeletbeli infrastruktúrát most nem fogom komolyan venni és nagyon elgondolkozni rajta, hogy vajon tényleg a size-overflow plugin-e itt a legnagyobb probléma?

Egy logokon keresztüli DOS támadás nyomokat hagy.

Ahogy már írtam, ennél egyszerűbb módszerekkel is lehet DoS támadást végezni.

Akár néhány dollárért bérelni is lehet a feketepiacon olyan botnetet, amelyel sok tízgigabites DDoS támadást lehet intézni bármilyen hálózat ellen...

Amit én láttam eddig, egy 5,5 milliós szerződésnél, 7,5 milliós kötbér mert nem építettek ki nyomásmérési pontot a nyomás alatt lévő kábelcsatornában.
Egy átlagos fejlesztőcégnek az E&O biztosítása évente 6500-8000 USD körül mozog és ez durván 1 millió USD-ig jelent fedezetet. Ugyanez a biztosítás PLI néven fut security részen és évente 13-20000 USD-be fáj hasonló fedezethez, viszont baromira nehéz biztosítót találni. Ez a belépő szint. Minél magasabb a tétje a dolognak annál nagyobbak az összegek. Hogy ez mekkora az igazán nagyoknál azt nem tudom, én csak egy forrasztó ember vagyok.

"Grsecurity and gradm are licensed under the GNU GPL version 2 only."
"NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. "

Nem kell, elgondolkodnod rajta. Csak ne lepődj meg amikor ilyen rendszerrel találkozol. A klasszikus közbeszerzésen "nyert" rendszer, biztonságtudatos rendszergazdával.

DDOS és DOS nem ugyanaz a kategória. Igen, sok mindent el lehet érni DDOS-al, de amikor meg akarod dugni a rendszergazda nőjét, akkor nem DDOS-al lövöd ki a rendszerét, mert ez esetben átfordul a másik oldalára, míg a sima DOS-nál felkel, bekúszik a céghez és eltölt négy órát azzal, hogy rájöjjön, miért áll megint a rendszer. És ez csak az egyik felhasználási lehetősége a DOS támadásnak. Egy jól kivitelezett DOS támadásnál a célpont hónapokon keresztül szopik adott alkalmazás vagy keretrendszer debugolásával, mire rájönnek, hogy támadás alatt állnak.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Amit én láttam eddig, egy 5,5 milliós szerződésnél, 7,5 milliós kötbér

Tehát volt szerződés és mégsem álltak el tőle a márisnemolyannagyszakértők.

"Grsecurity and gradm are licensed under the GNU GPL version 2 only."

Nem tudom mi köze ennek ahhoz, hogy a Grsecurity mögött álló cég mit vállal egy szerződéses munka keretében...

amikor meg akarod dugni a rendszergazda nőjét, akkor nem DDOS-al lövöd ki a rendszerét

Jajó, mondhattad volna előbb is, hogy te is csak trollkodni akartál és fotelsecurityzni, mint a twitteres gyerek.

Egy jól kivitelezett DOS támadásnál a célpont hónapokon keresztül szopik adott alkalmazás vagy keretrendszer debugolásával, mire rájönnek, hogy támadás alatt állnak.

Értem. Tehát egy támadó, aki bejut az autentikációs szerverre és hozzáférése van a felhasználói adatokhoz, valamint meg tudja személyesíteni bármelyik usert, az a támadó nem ezt fogja tenni, hanem csak simán leállítja a szervert. Logikus.

Nem, ez speciel a másik eset volt. Mikor nagyon szakértőnek gondolták magukat, de arra sem voltak képesek, hogy elolvassák a tervezési doksit.

"Please note that due to high demand and the nature of services we provide for our open source software, we are unlikely to accept projects that require unnecessarily long/boilerplate contracts."
Ez nagyjából összefoglalja bullshit nyelven.

Miért? Lehet másképp securityzni a HUP-on?

Nem, nem kell bejutnia a szerverre. Elég elhasaltatnia a front-end-t, és elég ha csak a front-end jogosultságával rendelkezik. A többit elvégzi a rosszul beállított patch.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Mindenben van hiba, nyilván a PaX-ban is. A "kernel self-protection" (ön)védelme azonban pont arról szól, hogy az ismeretlen hibák kihasználása ellen is biztonságot nyújt. A kernelben önmagában létező rengeteg biztonsági hiba és a saját hibáinak kihasználása ellen egyaránt.

Ahogy tette jelen esetben is. Saját összetevője fogta meg a túlcsordulást és a konfigurációnak megfelelően kernel panicot hívott meg. PaX nélkül ez a hiba nem is derült volna ki.

Azért azt tegyük hozzá, hogy eddig szerintem egy olyan védelmi mechanizmus nem lett implementálva, ami -főként a kezdetekkor- nem tört volna meg valamit. És mint ahogy a történelem megtanította itt nincs értelme a kompromisszumnak, hanem a tényleges kód részt javítani kell, és kiszedni belőle a kókányolt/fércelt munkát, hogy átláthatóbb is legyen a kód, meg biztonságosabb is.
Ha valaha használtál GrSec-et (igaz nekem ez már évekkel ezelőtt volt) akkor te is tapasztalhattad, hogy csomó program már akkor nem bírta elviselni, hogy határok közé szorítsák, és rendre crashelt is ez miatt (aztán jöhetett a forráskód letöltés + kód javítás/patchelés + újrafordítás-os szélmalomhalc minden releasnél amíg a tényleges javítást bele nem olvasztották a forrás fába).
Ezért sincs alap járaton egy ilyen se bekapcsolva, hanem elvárják a cégtől (aki ezt be akarja vezetni), hogy igen is tesztelje ki amit tud (ha tudja javítsa), csináljon normális risk assessment-et majd döntse el hogy meg akarja e tartani az egészet, ne pedig úgy viszonyuljon hozzá, hogy "na megvettük ezt az XY terméket, felraktuk default beállításokkal és most már minden rendben is lesz"
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Ez ugye még mindig azért kell, mert a fejlesztők nem tudnak rendesen puffert kezelni?

--

Ha jól értem, akkor még több kódot viszünk a rendszerbe, hogy védjük azokat a kódokat, amik biztonsági problémát okoznak/okozhatnak?

Nem lenne egyszerűbb ha a GCC adna egy *SECURITY WARNING* üzenetet, hogyha látja, hogy a lefordított kódban biztonsági rések vannak? Majd a fejlesztő addig finomít a kódon, amíg a *SECURITY WARNING* el nem tűnik fordításkor?

Ezt hívják statikus analízisnek. Vannak azonban hibák, amelyek csak futásidőben jönnek elő. Gondolj egy dinamikusan allokált memóriaterületre, amelynek méretét és a beleírt adatok mennyiségét a program menet közben számolja ki. Ezeket nem lehet fordításidőben kielemezni.

A RAP által hozzáadott "több kód" nagyon alacsonyszintű gépikód, néhány processzorutasításnyi művelet annak ellenőrzésére futásidőben, hogy a vezérlés olyan területre adódik-e át, amely forráskód alapján várható és linkelési időben látható (melyik függvényből melyik függvények vannak meghívva, visszatéréskor hova térhet vissza, stb.).

Én a "less code - less bug" elv híve vagyok.

Gondolom ez a RAP által hozzáadott "több kód" egyszerűen kapcsolható lesz majd a menuconfig-ban. Azokon a helyeken, ahol minden órajel számít, fölöslegesen nem lesz belefordítva sem a kernelbe sem pedig user-space alkalmazásba. Egy kapcsolható lehetőség marad, kernel fordításkor.

A GCC-t viszont fel kéne ruházni olyan képességekkel, hogy előre lássa már fordítási időben, hogy később, futási időben bizonyos kódokból security probléma lehet. Dobhat egy "security warning" üzenetet, esetleg le is állíthatja a fordítást.

Én a "less code - less bug" elv híve vagyok.

És ha az a plusz kód csak plusz ellenőrzés a már meglévő kódokhoz?

kapcsolható lesz majd a menuconfig-ban

Jelenleg is az: CONFIG_PAX_RAP.

A GCC-t viszont fel kéne ruházni olyan képességekkel

Vannak jelenleg is ilyen warningok, a fejlesztők azonban nem feltétlenül törődnek vele...

Hm. Ez működik C++-nál is? Illetve függény pointer-ekkel dolgozó kóddal? Gondolom, muszáj neki, mert a driver-ek általában függvény pointer-es struktúrákkal regisztrálódnak.

Szerk.: látom, a FAQ említi a függvény mutatókat. Kíváncsi lennék, a gyakorlatban ez hogyan tud működni, mert ez nem sima RAP.

Szerintem ez attól függ, hogy mit mitől akarunk védeni. A kernelt akarjuk védeni hibásan megírt user-space alkalmazásoktól? Vagy az egész gépet akarjuk védeni külső támadásoktól?
Ha a kernel-space és a user-space kódokat egy zárt egységként kezeljük, és csak ellenőrzött kód kerülhet futásra, akkor kasztolási problémák, hibás pufferkezelések és halting problémák és hasonlókból adódó security rések nem jöhetnek létre.

"Szerintem ez attól függ, hogy mit mitől akarunk védeni. A kernelt akarjuk védeni hibásan megírt user-space alkalmazásoktól? Vagy az egész gépet akarjuk védeni külső támadásoktól?"

Marmint hogy fugg ettol? De legyen mondjuk egy user-space alkalmazas, amit tavoli tamadoktol akarunk vedeni, az a legegyszerubb.

"Ha a kernel-space és a user-space kódokat egy zárt egységként kezeljük, és csak ellenőrzött kód kerülhet futásra, akkor kasztolási problémák, hibás pufferkezelések és halting problémák és hasonlókból adódó security rések nem jöhetnek létre."

Ezt nem ertem.

Van egy PC. Fut rajta egy kernel. A kernel nem tartalmaz semmilyen biztonsági rést. Fut rajta egy user-space1 alkalmazás, ami szintén nem tartalmaz biztonsági rést. Ez esetben a külső támadásoktól védett az egész rendszer.

De mi van, hogyha van egy másik user-space2 alkalmazás, amelyik már valamilyen módon tartalmaz biztonsági rést? Kérdés, hogy melyik a célravezetőbb? Az önmagában már biztonságos, hibamentes kernelt és user-space1 alkalmazásokba plussz kódot bevinni, hogy lekezelje user-space2 alkalmazás hibáit vagy egyszerűen megszüntetni user-space2 alkalmazás hibáit?

Ezek ilyen jól hangzó frázisok, csak nem lehet velük mit kezdeni. Például először is a misztikus "biztonságossá tehető" kifejezést kellene definiálni, mert jelenleg arra a problémára amiről a topic szól, nincs jobb megoldás. De ez is csak a biztonsági problémák kihasználásának egy részére nyújt védelmet, viszont így is egy nagyon régóta létező és megoldatlan problémára.

Ha a kernel tokeletesen biztonsagos, akkor definicio szerint a hibas alkalmazas (privilegiumaival tevekenykedo tamado) sem tud vele mit kezdeni, tehat felesleges bele barmilyen plusz ellenorzes. A RAP epp azert van, mert tudjuk, hogy a kernel nem tokeletesen biztonsagos, belathato ideig nem is lesz az.

Az eredeti allitas viszont az volt, hogy nincs olyan algoritmus, ami barmilyen programrol egyertelmuen meg tudja mondani, hogy tartalmaz-e biztonsagi hibat (meg akkor sem, ha a "tartalmaz biztonsagi hibat" kikotest nagyon szuken ugy ertelmezzuk, hogy helyes-e a pufferek meretenek kezelese).

Ha a kernel tokeletesen biztonsagos, akkor definicio szerint a hibas alkalmazas (privilegiumaival tevekenykedo tamado) sem tud vele mit kezdeni, tehat felesleges bele barmilyen plusz ellenorzes.

Ez így van. Nem kell erőforrást fordítani plussz ellenőrzésre futási időben. Ha egy rendszer többféle módon biztonságossá tehető, akkor azt a megoldást kell választani, ami a legkevesebb kóddal jár.

Az eredeti allitas viszont az volt, hogy nincs olyan algoritmus, ami barmilyen programrol egyertelmuen meg tudja mondani, hogy tartalmaz-e biztonsagi hibat (meg akkor sem, ha a "tartalmaz biztonsagi hibat" kikotest nagyon szuken ugy ertelmezzuk, hogy helyes-e a pufferek meretenek kezelese).

Azok az emberek, akik biztonsági rések keresésével,kutatásával netán kihasználásával foglalkoznak, ők hogy találják meg ezeket a biztonsági hibákat?

"Azok az emberek, akik biztonsági rések keresésével,kutatásával netán kihasználásával foglalkoznak, ők hogy találják meg ezeket a biztonsági hibákat?"

Nehanyat? Neha egy sima regexp-el. :) Az osszeset? Sehogy.
Nagyon nagy kulonbseg van akozott, hogy megtalalsz egy hibat, ki tudod mondani egy adott, specialisan igy fejlesztett szoftverrol, hogy hibamentes (aminek az ellenkezoje nem az, hogy "hibas", hanem hogy "nem tudtam bizonyitani, hogy hibamentes"), vagy barmilyen szoftverrol egyertelmuen meg tudod mondani, hogy tartalmaz-e hibat, vagy sem. Az elso konnyu, a masodik nehez, a harmadik lehetetlen.

Algoritmizálni kell a hibakeresést, fordítási időben. Itt jöhetnek be mindenféle trükkös algoritmusok, kódelemzők. Léteznek ilyen kódelemzők, például: http://www.coverity.com/

Tekintve, hogy a userek döntő többsége előre lefordított binárist futtat, így a futási idővel kell spórolni és több erőforrást kell áldozni a fordításra, kódelemzésre.
Kíváncsi lennék, hogy egy coverity miket dobna ki egy sima linux kernel tree elemzése után...

Leírtam egy konkrét példát amelyet nem lehet fordítási időben kiértékelni. Se "trükkös algoritmusokkal" (bármit is jelentsen ez), se kódelemzőkkel, se ima könyvel és ima malommal, se ráolvasással, se ördögűzéssel...

A Coverityt folyamatosan futtatják a Linux kernelre, a FreeBSD-re és nagyjából minden népszerű és modern nyíltforráskódú szoftverre. Ettől még egyik sem hibamentes.

Leírtam egy konkrét példát amelyet nem lehet fordítási időben kiértékelni. Se "trükkös algoritmusokkal" (bármit is jelentsen ez), se kódelemzőkkel, se ima könyvel és ima malommal, se ráolvasással, se ördögűzéssel...

Oké, elhiszem.

Véleményem szerint a kevesebb kódot igénylő jó megoldás felé kell menni, ez pedig ezt jelenti, hogy a statikus kódelemzőknek kell fejlődniük, mint pl. coverity és valgrind...

De ha elhiszed, hogy fordításidőben nem lehet minden hibát megtalálni, akkor miért írod le mégis, hogy ezeknek a kódelemzőknek kell fejlődniük és ez a jó megoldás?

Arról már nem is beszélve, hogy összekevered a programozási hibákat a sebezhetőségektől és összekevered ezeknek a biztonsági hibáknak a kihasználásától. Ez három külön dolog. Egy kódelemző programozási hibákat tud megtalálni, de nem tudja eldönteni, hogy biztonsági szempontból mennyire relevánsak ezek a hibák, kihasználható-e privilégium szerzésére. A PaX viszont még tovább megy és a sebezhetőségek _kihasználásánál_ fogja meg a támadást.

Ha egy csoda kódelemző minden hibát meg is tudna találni (ami messziről sincs így és nem is lesz így soha), akkor is ott lenne a probléma, hogy a fejlesztők ezeket a talált hibákat nem fogják kijavítani egytől-egyig és sose lesz a hibák száma nulla. Viszont a szoftvert attól még szeretné használni a user, lehetőleg minél nagyobb biztonság mellett. A RAP ebben segít.

Kicsit Dunning–Kruger hatást érzek nálad.

sub

Van hova fejlődnöm, úgy érzem...

Érdemes lehet ezzel a GCC pluginnal az összes binárist újrafordítani?

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Nyilván a legtutibb az lenne, ha egy teljes disztribúció lenne vele lefordítva és nem csak a kernel, hanem minden alkalmazás is védve lenne az ilyen jellegű támadásokkal szemben.

Sajnos azonban ez elég sok munkát igényel. A forráskódok tele vannak programozási hibákkal (kasztolási különbségekkel), amelyeket ki kell javítani ahhoz, hogy a védelem működőképes legyen. A tapasztalat pedig azt mutatja, hogy még a formálisan ellenőrzött seL4 mikrokernelben is vannak függvénymutatókat érintő kasztolási hibák. A Linux kernelben is rengeteg módosításra volt szükség és még vannak olyan területek, amelyek további átnézést és javítást kívánnak (már jelentettem is ilyet a paravirtualizációs kernel kódokban).

A PaX patch már így is 1 megával növekedett csak ezeknek a javításoknak köszönhetően. Az átlagos alkalmazásokban valószínűleg még ennél is több javításra lenne szükség. PaX Team létrehozott egy RAP védett Chromiumot, amelynél nem csak a böngésző kódja, hanem a hozzá kapcsolódó függvénykönyvtárak is védve vannak, de az se volt kis munka. Arra viszont jó volt, hogy bizonyítsa a védelem működőképességét és használhatóságát, valamint a kis overheadet, amelyet okoz. Az előadásanyagában vannak erről pontos számok javascript benchmarkokból.

"PaX Team létrehozott egy RAP védett Chromiumot, amelynél nem csak a böngésző kódja, hanem a hozzá kapcsolódó függvénykönyvtárak is védve vannak, de az se volt kis munka."

Azt nem tudod veletlenul, hogy chromenal hogy kezeltek a JIT-generalt kodot? Kapott a JIT-compiler is egy patchet, hogy generaljon RAP check-eket? Hogy lettek meghatarozva az indirect control transfer tag-ek?

A JIT-compiler nem lett patchelve, mert a Research arról szólt, hogy egy ekkora terjedelmű projektet lehet-e egyáltalán RAP védelemmel fordítani és ha igen, akkor mekkora overheaddel jár utána futásidőben. Szóval csak a C++ -> JIT átmenetnél van ellenőrzés, a JIT-en belül még nincs, de tervben van az is.

Benne van egyébként a FAQ-ban, ami most került ki:

https://grsecurity.net/rap_faq.php

"A tapasztalat pedig azt mutatja, hogy még a formálisan ellenőrzött seL4 mikrokernelben is vannak függvénymutatókat érintő kasztolási hibák."

Az eleg erdekes, ugyanis az sel4-ban egyaltalan function pointer hivasok sincsenek. Function pointert egyedul ott hasznalnak, ahol ez a hw miatt kell (pl. IDT), meg a debug kodban, de az nem resze a proofnak.

Valamit elfelejtettem megköszönni: a hírt!
Egyrészt hogy beküldted, másrészt pedig, hogy így megfogalmazva küldted be! (vagy lefordítva, nem néztem utána)

Köszönöm!

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

OpenSSL Security Advisory [3rd May 2016]

Memory corruption in the ASN.1 encoder (CVE-2016-2108) Severity: High
Padding oracle in AES-NI CBC MAC check (CVE-2016-2107) Severity: High
EVP_EncodeUpdate overflow (CVE-2016-2105)
EVP_EncryptUpdate overflow (CVE-2016-2106)
ASN.1 BIO excessive memory allocation (CVE-2016-2109)
EBCDIC overread (CVE-2016-2176)

http://permalink.gmane.org/gmane.comp.encryption.openssl.announce/208