Marcelo Tosatti: Linux 2.4.28

Azert az se gyenge, hogy a javitott local root exploit mar augusztus vegen ismert es jelentett volt.

exploit? mutasd mar meg hol (ugye nem az 5-re gondolsz, mert az kesz rohej onmagaban, letoltom az rpm-et vagy deb-et, es megvan a file, nem kell 'exploit' hozza ;-). az isec 5 bugjabol 4 semmire nem jo (nem security bugok, azert nem rohant vele senki), egyedul a 4. sorsa kerdeses, de arra meg az isec sem tudott exploitot irni, szoval meg ha security bug is, akkor sem trivialis az exploit.

En abban a hitben voltam eddig, hogy az isec-es bugok local root exploit-ot jelentenek...

Mondjuk jobban megnezve az advisoryban csak ,,may gain root privilages'' .

Az isec.pl -en van vmi forraskod ezzel kapcsolatban. Ez nem exploit?

Most akkor mi az igazsag?

hmmm... nos, a 4. buggal a rendszer fagyását elő lehet idézni az biztos.

Az 5. eset akkor lehet hasznos, ha egy adott suides binárisban (su, mount, stb.) van egy kihasználható hiba, amelyre azért nem tudsz írni működő exploitot, mert nem olvasható (csak futtatható és suid flag van rajta) és egyedileg fordított, nem kész csomagból származik (nem rpm, deb). Pl. egy gentoo linux alatt egyedileg fordított suid bináris olvasási jogok nélkül. Ebben az esetben jó segítség lehet, hogy mégis olvasni tudod a fájlt, könyebb eltalálni az offset címeket a suid bináris exploithoz. ;)

'jelenthetnenek', nem 'jelentenek', ugyanis a szukseges feltetelek kb senkinek a gepen nem allnak fent. az a forraskod meg az 5. bugrol szol (ami nem ad root-ot direkt), ami szerintem jo nagy zoldseg, lasd alabb a hungernak adott valaszom.

osszuk 3 csapatba a linux (vagy akarmilyen) felhasznalokat:

1. aki csak a sajat disztroja altal szolgaltatott suid-kat tart (debian, redhat, stb). itt a bug erdektelen, hiszen barki hozzajut a binarishoz, nem kell hozza semmilyen bug vagy akar csak local access.

2. aki csak a sajat disztroja altal szolgaltatott suid-kat tart, de sajat maga forditja (gentoo vagy fejlesztok, akiknek nincs jobb dolga, mint suid-t forditani naphosszat ;-). itt a kerdes az, hogy egy tamadonak hany parametert kell kitalalnia, hogy ugyanazt a binarist sajat maga is elo tudja allitani, aztan vegigprobalni az adott suid elleni exploitjat a lehetseges kombinaciokon. a kodgeneralasnal ugye csak a gcc jatszik szerepet, ott pedig az optimalizacioval ill. architekturaval kapcsolatos kapcsolok. szerintem a legtobb felhasznalo, aki ilyenre adja a fejet, az 20-nal tobbet nem hasznal (en igy fejbol pl. meg se tudnek nevezni ennyit ;-). az meg csak 1 millio kombinacio (es a tobbsege valoszinuleg nem is ad kulonbozo eredmenyt), azt pedig nem tart sokaig vegigprobalni (tehat a bug megint semmi extrat nem ad, legfeljebb gyorsabba teszi az exploitot).

[erdekes, a formazatlan szovegben az onmagaban allo kisebb jel nem akar atmenni, a fogado szkript vmi vegtelen ciklusba kerul es 30 mp utan lelovi a rendszer... bug/ feature? ;-]

3. aki 'titkos' suid-t tart a gepen (vagyis aminek a forrasa ill. binarisa az adott tamado szamara nem elerheto). nos, ez az egyetlen eset, amikor ez az ominozus 5. bug erdekesse valhat - kerdes, hogy ez a felhasznaloknak hany szazalekat erinti. megsaccolom, hogy kevesebb, mint 0.01 ;-). es mivel itt eleve privat kodrol van szo, egy disztro semmit nem tehet az ugyben, max fixalhatja a kernel bugot abban a remenyben, hogy nincs mas, amivel ugyanezt el lehetne erni. magyaran, aki a 711-re bizza a root-jat, az megerdemli.

tehat a bug megint semmi extrat nem ad, legfeljebb gyorsabba teszi az exploitot

De mi ez ellen is védekezni szeretnénk, nemde? ;) Hisz ugyanezt a célt szolgálják a PaX-os randomizációk is, lassítják a sikeres exploitot... ;D

Nekem pl. van saját suidos programom a szerveremen és az összes binárisomnak csak futtatható joga van, tehát akár érinthetne is a bug. Szerintem jó ötlet minden binárist, csak futtathatóra állítani, hisz egy sima usernek egyébként sincs szüksége arra, hogy olvassa azokat a fájlokat, egy támadót meg lehet hogy épp ez gátol vagy lassít le. Ez pedig nem csak a suidos binárisoknál lehet így. (Pl. olyan ftp daemonnál, amelyik külső parancsokat [ls, stb.] hív meg, a támadót lehet, hogy épp az gátolja meg, hogy shellt szerezzem, hogy az ls-ben lévő bugot nem tudja exploitálni, mert a bináris jogai csak futtathatóra vannak állítva, így nem tudja letölteni a fájlt és az offset címeket kiszámolni. Nevezzem el ezt az ötletemet R^X-nek? ;)

tevedes ;-), lasd http://marc.theaimsgroup.com/?l=debian-devel&m=106804968406987&w=2 , ami fontos most:

in any case, you're missing the point behind randomization. it's an

obscurity feature, however efficient it may turn out to be in certain

cases. i did it because it was extremely cheap (speaking of the PaX

implementation, not Exec-Shield) so i said 'why not'. randomization

serves NO purpose in the grand scheme, it does not provide guaranteed

protection against the PaX attack model (arbitrary read/write access

to the address space).

magyarul a randomizalas egy olcso es adott esetben hatekony vedekezes, de nem oldja meg a problemat, csak legfeljebb elodazza a betorest. amugy meg az egesznek ugy van leginkabb ertelme, ha nem a lassitasra jatszasz ra, hanem a crash detektalasra ill. tovabbi futas megakadalyozasara (RES_CRASH a grsec-ben).

az 'ls' eppen rossz pelda, mert azzal az 1. vagy 2. csoportba kerulsz, ahol pont erdektelen, hogy tudod-e direkt olvasni a cel file-t vagy sem. amugy meg megerdemled ;-).

Akkor most miért tévedés az amit én mondtam? :) A randomizálás nem 100%-os védelem, csak lassítja a sikeres exploitálást... kb. ugyanazt mondjuk mind a ketten, csak máshogy megfogalmazva. ;-P

Mit érdemlek meg? Engem nem érint a hiba... ;)

en az 'ez ellen is vedekezni szeretnenk'-re irtam, hogy nem (vagyis en nem ;-), tehat a pax-ban az, hogy egy exploit lassabba valik a randomizalas hatasara, az mellekhatas, nem az a cel vele (hanem a folyamatban levo tamadas detektalasa, es a reagalas). az nem vedelem/security, hogy olbe tett kezzel nezem, ahogy a hacker vegigprobalja mind a 10 millio (vagy akarmennyi) kombinaciot.