RETGUARD - Újabb exploit mitigációs technológia az OpenBSD-nél

OpenBSD

Theo de Raadt tegnapi, openbsd-tech@ levlistára küldött levelében az OpenBSD legújabb exploit mitigációs techológiájáról, a RETGUARD-ról adott előzetest.

pomt ez volt a kerdes...mert nem ertettem mit akar azzal hogy hu ez mekkora innovazio majd linkeket vagott be a Paxteam eloadasara. Szarkazmust ereztem, meg egy kicsit a faszi munkajanak leszolasat, hogy o csak lemasolta masok nagyszeru munkajat.

Szoval en ugy erzem mi egyetertunk, de meg mindig nem tudom mi akart ez az innovaciooooo lenni.

Tényleg nem értek hozzá, tényleg csak amatőr vagyok, tényleg csak a partvonalról figyelem, tényleg csak a töredékét sem ismerem a paxteam / grsec kontra világ sztorinak, de azért belepofázok...

Alapvetően sokmindenre rá lehet húzni, de a szabadszoftveres világ sokkal inkább Nooszférában létezik mint az anyagiban. Ez a világ némely tekintetben nagyon hasonlít a fizikai világra: jön valaki, kinevez magának egy bizonyos területet, körbekeríti, és ha úgy tetszik Locke-i értelemben tulajdonjogot formál: olyan szakmai munkát végez, valósít meg, új módszert eszel ki, amit előtte még senki nem tett, csinált úgy, ahogy... A szimbolikus tulajdonjogot pedig mások általi szakmai, ne adj isten anyagi elismerés jelenti.

Szóval probléma itt tulajdonképpen az, hogy paxteam/grsec nooszférikus kertjének ledöntötték a kerítését, elhordták a frissen ültetett facsemetéket, amelyek ma már máshol hozzák a termést, miközben senki nem tudja, hogy honnét vannak ezek a szép növények - mindezért cserébe ráadásul még bele is szartak és hugyoztak a kert közepébe, majd az ezzel kapcsolatos firtatásra csak annyi a válasz, hogy hálából csak megtrágyázták a földet....

bocsánat! autós hasonlatra most nem futotta. :)

Senki sem mondta, hogy a GPLv2-es Linux kernelhez kell biztonsági megoldást reszelni. Ha pedig valaki erre adja a fejét, vállalja a következményeit. A Linux kernel licence szabadon olvasható, tanulmányozható. Az volt már akkor is, amikor nekiálltak a projektnek. Nem utólag módosultak a játékszabályok.

--
trey @ gépház

Hat igen, a hasonlat is ugy nezhetne ki inkabb, hogy bekeredzkettek fat ultetni kernelkert szelere, de aztan nem nagyon figyeltek a kert okoszisztemajara, csak a sajat faikra, igy megbetegitettek mas termenyeket neha. Erre a kert gazdaja azt mondta, hogy nem ultethetik a faikat a kert kozepere. Na erre beduhodtek es kiteptek a sajat faikat, majd arrebb ujra elultettek oket, harommeteres falat huztak kore es onnan kopkodnek a masik kert fele.

A masik oldalon meg lattak, hogy van abban racio, ahogy a sajat faikat metszik es hasznaljak a modszert. De hat hogy is mereszelik????

Ja KOZOSSEGI kertrol beszelunk.

Nem nagyon megy neked még mindig a licenc és a copyright megkülönböztetése, teri.

A GPLv2 licencnek köszönhetően a munkáik nyugodtan felhasználhatók, szívesen adják tovább a stafétát és nyugodtan viheti tovább bárki, amit eddig összeraktak. Meg lehet mutatni azt is, hogy hogyan kell ezt jobban csinálni (várják azóta is).

Az viszont nem járja, hogy a munkáikat egy az egyben lemásolják, majd a copyright átírásával a sajátjuknak tüntetik fel...

Szépen kikerülted a választ. A Linux kernel úgy jött ide, hogy ha nem tetszenek a játékszabályok, akkor lehetett volna eredendően BSD kernelhez megoldást reszelni (biztosan arra is ráfért volna). Kevésbé megkötő licenc mellett.

Ja, hogy akkor val'szeg a "siker" is kisebb lenne...

--
trey @ gépház

Az szál elején olvasható értetlenkedésre regálva írtam le a véleményem. Szóval ha az ilyen hülyék, mint én értem, hogy mit takar ''''innovációóó'''', akkor komolyan felvetőtik a kérdés, hogy miféle (jóesetben csak) buborékban él az a nálam okosabb / tájékozottabb valaki mégiscsak értetlenkedik. :)

Ez alapvetően ,,,,,szerintem,,,,, nem licenszjogi kérdés. Nem közvetlenül a forráskódhoz van köze. Kieszeltek egy új megoldást, megközelítést, felszínre hoztak, próbáltak hozni egy új szemléletet, de a közösség hangadói nem értik, hogy miről van szó, vagy ami rosszabb nem akarják érteni, ami megmégrosszabb, vannak akik az eredeti ötletet/megvalósítást felhasználva feltalálják újból a spanyolviaszt, megcímkézik és saját megoldásként hirdetik.

Az meg más kérdés, hogy egyéb részletkérdésekben kinek van igaza és miben. Nem tudom megítélni és nem is akarom... :)

Jól értem, hogy szerinted Theo egy illedelmes úriember (hát azért ugye tudnánk egy-két példát felhánytorgatni a múltból, ugye)? Kihez képest? Linuxhoz képest?

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Hagyd, ezen a "theo jol megcsinal valamit" kitételen egyébként is halálra röhögtem magam és mindenki más is, aki vette a fáradtságot és megnézte a kódot... Lényegében az eredeti koncepciót is sikerült tarkonbaszni azzal, hogy nem egy titkos XOR canaryt használnak, hanem az offset címmel xorolnak (== infoleak esetén simán kijátszható az egész védelem, amelyre az ASLR miatt már egyébként is szükség van, tehát lószart se ad hozzá ez a RETguARD "védelem").

PaXTeam legalább megcsinálta rendesen (CPU regiszterben tárolt egyedi XOR cookie, amit nehezebb leakelni) és elmagyarázta a 2015-ös előadásában, hogy mi a különbség a RAP különböző összetevői között (probabilistic vs. deterministic védelmek, korrekt threat model, stb.), ráadásul nem adta elő, hogy ez a XOR canary megoldás valami eredeti ötlet lenne részéről, hanem korrekten felhozta az előadásában az 1999-es(!) StackGuard kiadást, amely már akkor hasonló ötleten alapult. De persze ezt a slideot már nem látta a "nem arrogáns paraszt" kommentelő... ;)