azért ugye azt te is érted/érzed, hogy ha most Hunger neked tényleg valami olyat adna ami valóban működik, akkor jogilag simán támadhatóvá válna. Kb olyannak érzem a felvetést, mint amikor a serdülők heccelik egymást, hogy "úgy se mered bedobni azt az üveget ezzel a kővel, Mcfly, mert nyuszi vagy". Szóval szerintem erről a részről nyugodtan mondj le.
Egy próbát megért ;-)) Veszítenivaló nem volt. Legalábbis erről az oldalról. :-D
Érdekes lett volna megnézni amolyan "feketedoboz módszerrel" egy chrome-hoz hasonló firefox bugot virtuális gépen, és a feladat az lett volna, hogy a bug kihasználását meggátolni pl. noscript vagy grsec acl használata nélkül ?
Hátha fel lehet húzni valami védelmi sablont az adott hibakategóriára, ami mondjuk nem noscript. Tehát a laboratóriumi környezetben szándékosan hibás régi firefox verziót alkalmazni, hátha testre szabhatóbb védelmet lehet találni későbbi hasonló esetekre.
Nem biztos, hogy lett volna türelmem, kedvem, szabadidőm erre, de a talonba benne lett volna, hátha mégis. :-D
Lehet hogy ez is bele került volna a soha meg nem valósult elméleti tesztek közé, mint pl. hogyan reagál pl. a windows nt kernel arra,
ha a SAM fájlt kiszerkesztik alóla hex. editorral olyan módon hogy ugyanazzal az UID-el két felhasználó szerepel két eltérő jelszóval. :-D
betöltéskor helyesen észreveszi-e a külső manipulációt, és pl. kék halállal elpánikol, vagy engedi a belépést, és mivel ua UID van két névnél, két felhasználónévre is engedi a belépést, és hozzáférhetőek a fájlok mert ua. uid-re vannak a jogok beállítva ? tehát pl. a guest-et feloldják a zárolás alól berakják a rendszergazda csoportba, de az uid kódja ua. lesz mint a rendszergazdának, hozzáfér-e a rendszergazda fájlokhoz ?
anno nt4 korában jutott eszembe ez az elmebeteg ötlet, amikor jelszókiütéshez elég volt a sam fájlt törölni, sose próbáltam ki egyik win verzióval sem. mostmár biztosan nem is fogom sosem.
Ehelyett lehet jobban jársz, ha az elméleti háttérrel barátkozol, ami úgy szól, hogy ha egy program működését irányítani tudjuk, akkor az adott jogosultsági szinten a program azt csinálja amit mondunk neki - calc.exe-t hív, vagy amit akarunk (vagy akár perl /tmp/hunger.pl-t). Innentől fogva a TPE-t én is kicsit gyengének érzem, mivel a támadási felület innentől már csak abból áll, hogy valahogy az áldozat gépét rábírjam, hogy futtassa is amit a támadó akar.
Ezt én nem is vitattam. Az user nevében futó szkript, vagy program mindent megtehet, amit maga az user is megtehet. Kérdés, hogy a szkriptet el tudjuk-e indítani.
A bináris programról mindenesetre azért nehezebben mondod meg mit csinál, mint mondjuk egy szkriptről :-) , és a szkript azért alapvetően csak azokat a programokat használhatja, amik a célrendszeren elérhetőek.
Ráadásul a szkript futását adott esetben el is kell rejtened valamilyen egyéb eszközzel, mert ahol pl. TPE van, ott esetleg jobban megnézik milyen szkripteket futtatnak le. tehát az user interakció esélye erősen csökken.
Ehhez persze sok esetben kell valami user interakció
Igen. Pl. Ha az user van olyan birka, hogy kiadja pl. az rm -rf /-t, mint rendszergyorsítót, akkor nincs olyan erő ami ebben meggátolhatja :-)), míg egy bináris fájlban nagyjából tjképpen bármi lehet akár akarja azt az user, akár nem.
aztán egy másik (magasabb jogosultsággal futó) kód hibáját kihasználva akár privilégium szint emelést is el tud érni (ez lehet kernel, kernel driver, vagy simán root joggal futó szolgáltatás, vagy akár csak SUID program
Igen, de most akkor elvi síkon ott tartunk, hogy a TPE miatt idegen binárist nem tudsz bejuttatni simán,
- csak ha van egy megfelelően sebezhető program megfelelő verziója a célgépen, amivel pl. egy idegen script futtatására rá tudod bírni a célszámítógépet.
Tehát azért a TPE nehezített valamennyit a dolgodon, vagy nem ?
Ami nem feltétlenül lehet pl. mem. korrupciós bug sem, mert mondjuk másik védelmi elem, pl. PaX lecsapja. Az idegen kód bejuttatása innen már cseppet sem optimális, túlságosan sok idegen tényező léphet be, ami a sikeredet gátolhatja.
Ha pedig a Hunger által linkelt chrome-s hibához hasonló sebezhetőség van, ott meg kell egy viszonylag konkrét böngészőverzió / ez mondjuk honlap user-agentből megvan adott esetben, ha nem hamis :-) / , de lehet hogy van hozzá olyan kiegészítő (pl. noscript a firefoxnál), amivel viszont ez a próbálkozás is lehet, hogy elhasal. Vagy a kihasználni kivánt függvény egyszerűen bugos mert a firefox verzió az adott distro által szétpachelt, agyonpatkolt, rosszul megvalósított az adott környezetben.
céloztál kernel bugra, ott is lehet ilyen.:
pl. a 3.14-es kernelben amit használok a win16-os környezet teljesen használhatatlan, mert elkurták a modify_ldt()-t, mert találtak benne valami korai verzióban biztonsági problémát / nem tudok részleteket, nem nyomoztam nagyon a témában, amit találtam magyarázatként valami listában az informatív "security fix" szerepelt :-), és a javítás során sikerült teljesen használhatatlanná tenni.
Innentől nagy biztonsággal kijelenthető, hogy wine+win16 alkalmazás révén nem lesz pl. priv. emelés, mert egyetlen rohadt win16 alkalmazást sem lehet normálisan elindítani :-)
Abban igazad van, hogy ezek a védelmi megoldások (noscript, PaX, grsec) önmagukban nem csodaszerek.
A noscript hiába van, ha ki tudsz használni egy memkorrupciós kernel bugot, a PaX is hiába van, ha van egy ilyen jó kis chrome-szerű sebezhetőség, és mindkettő hiába lehet, ha letöltünk egy jó kis idegen bináris fájlt mint a topicban szereplő jószág, és futtatjuk, mert nincs restrickió az idegen binárisokkal szemben. :-)
De ha egy biztonsági eszköz (TPE) megkerülésére feltételezel egy másik eszköz másik biztonsági hibáját (böngésző script), akkor lehet, hogy arra is van adott esetben egy másik védelmi eszköz (pl. noscript)...
Ezzel persze nem mondom azt, hogy ilyen jellegű veszélynek vagy most kitéve, csupán azt, hogy megvan az elméleti lehetősége annak, hogy megfelelő idővel és tudással bíró ember ezeket a hibalehetőségeket kiaknázza,
Én ezt nem vitatom, de a trend a könnyebb ellenállás útján megy egyelőre, ahogyan mindig, amennyire én látom. Tény, mivel nem foglalkozok informatikával, nem látok túl sokat :-))
Mindenesetre amíg az alap linuxok simán támogatják idegen binárisok futtatását, nagy biztonsággal megjósolható, hogy nem a szkriptekkel fognak ilyen módon támadni.
Sokan még egy noexec-et sem írnak be home fájlrendszer csatolásba, (tudom nem kell mondanod mennyire könnyű adott esetben kikerülni, bár lehet hogy ez változott az utóbbi 7-8 évben),
addig nem az ilyen chrome-szerű bonyolult több sebezhetőséget egyszerre kihasználó eszközök adják a kártékony viszonylag széles körben terjedő cuccok tömegeit.
de épp ez miatt 1 konkrétat kiragadni és Szent Grálként kezelni hülyeség, mert ezzel mintha kijelentetted volna, hogy a többi amúgy csak dísznek van,
Hú, ha ez jött le a hsz-eimből akkor az nagyon félrement. :-) Én erre az egy esetre a topicban, erre a bináris cuccra ami a témában van fókuszáltam. mert ez abszolút tényszerű, időben is stimmel, kvázi kézzelfogható, hogy úgy mondjam "ismert".
És jegyeztem meg a nyitó szálban, hogy mégis csak ér a TPE valamit ezek szerint. Ez a témában szereplő cucc azért nem használ ki a fentebb linkelt chrome-os sebezhetőséghez hasonló esetet, nem keres privilégiumemelésre lehetőséget, kernelbugot sem használ ki.
Egyszerű bináris fájl, felhasználói jogkörrel, amiből tjképpen 12 egy tucat.
Nyilván lehet hogy lesznek majd ilyen "chrome-hibát" kihasználó 60E USD-s valóban csodaszkriptek, igen, lehet hogy lesznek. most ebben az időben jelenleg publikusan széles körben (még) nincsenek.
lehet hogy holnap estére már lesznek, ki tudja, és akkor lehet röhögni popcorn-al vagy anélkül :-))
találkoztam olyannal, hogy a SUID-os bináris direktben hívott másik scriptet (bash-en keresztül), aminek a paramétereit lehet irányítani - ott pl a shellshock egész új értelmet nyert nálam)) és onnan meg már nyitott kapukon kell csak ki-be sétálgatni.
Hát itt én is alkalmazok a saját rendszeren egy enyhén sáros sudo szkriptet.
Ezért érdekelne elméleti síkon a véleményed, kritikád, ha szabad. :-)
/ ennyire amit írsz, talán nem sáros :-) / ez paraméterként ip címet fogad el , ami gpg-vel titkosított emailben jön netbook mobilnetről egyéb megkötésekkel (pl. amolyan időbélyeg, időkorlát is van), és iptables-n módosít, ezért kell a root jog sudo formában. :-)
tehát ha menet közben az emailt elfogják, és "újraküldik", a benne levő lejárt időbélyeg miatt pl. hatástalan.
Természetesen van eredmény ellenőrzés, titkosítás sikerességének ellenőrzése, ip cím formátum ellenőrzés, stb. :-)), de vagy ez van, vagy a nap 24 órájában nyitott az egyik port ssh-nak. /hitelesítés kulcsos /
Mert ezzel azért be tudom szűkíteni távolról, hogy mikor legyen nyitva, honnan engedje be a nagygép a netbookot. /dinamikus ip-k ipv4en, ipv6 nincs /
Az email mindenképpen szükségesnek tűnik, mert a nagygép email visszaigazolást küld a netbook email címére sikeres beállítás után, aminek forrása x-originating ip-ként tartalmazza a nagygép ip címét, akármennyire is dinamikus. Így tudom a netbookon hogy "kit keressek úgymond". :-)
A sáros rész ugye ott van, hogy mikor az ellenőrzés lezajlik, és az eredmény (ip cím), felhasználói kóddal / amelyik az emailt kapja / ki van írva az adott fájlba.
Majd elindul a sudo szkript , hogy ugyanezt a fájlt visszaolvassa, itt van némi elvi síkú probléma, ha a köztes időben a fájlt módosítja egy külső hatás / de akkor rohadt gyorsnak kell lennie /. ami mondjuk nem könnyű mert ez a felhasználói kód lokálisan sosem lép be, tehát külső kód futtatására nem könnyen lehet rávenni, hacsak a gpg-ben nincs olyan hiba, hogy ihaj, idegen kódot is futtat, meg még pluszban a dekódolást is elvégzi. :-)
Ez a felh. kód csak az adott feltételeknek megfelelően érkező email dekódolást végzi, meg ssh-n léphet be kulccsal, és akkor is amolyan sock proxyként üzemel.
ha biztonságtechnikailag ehhez van valami tipped/tippetek érdeklődéssel hallgatom. végül is én felettem már nagyon eljárt az idő ilyen téren ez tény. :-))
A másik sáros rész ott van, hogy a folyamatban túl sokféle eszközt/prg-t kell felhasználni. De ezen nem hiszem, tudok segíteni. túl komplex az igény.
--------
Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.