Biztonsági incidens a kernel.org-on

Titkosítás, biztonság, privát szféra

A The Linux Kernel Archives legfrissebb híre szerint ismeretlen elkövetőknek sikerült betörniük a kernel.org infrastruktúrájába. A jelenleg ismert adatok alapján augusztus hónap során több szerver is a támadások áldozatául esett. Az üzemeltetők - akik az incidenst augusztus 28-án észlelték - valószínűsítik, hogy egy kompromittálódott account-ot használtak fel támadók, akik root jogot szereztek a "Hera" nevű szerveren. A kernel.org csapata jelenleg úgy hiszi, hogy a forráskód tárolók érintetlenek, de ennek bizonyítására vizsgálatot indítottak. Emellett ígéretet tettek a biztonság további fokozására. Az érintett szervereket lementik, újrahúzzák. A támadásról értesítették az Egyesült Államok-beli és európai hatóságokat. A részletek itt olvashatók.

Frissítés: Jonathan Corbet - az LWN főszerkesztője - írása a témában.

( bastya_elvtars | 2011. 09. 01., cs – 09:52 )

"Biztonsági incidens a kernel.org-on"
magyarul: feltörték a g***be
"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

Ez csak feltételezés, de végül is ha jelszóval/kulccsal mentek be, akkor sem várhatjuk el mindenkitől, hogy különbséget tudjon tenni az "ajtót kinyitották kulccsal" vs. "pajszerrel felfeszítették" közt. Utána azért nyilván meg is törték, hiszen ez olvasható a kernel.org-on.

--
trey @ gépház

a kompromittálódott user acc egy dolog. a privilege escalation egy másik, blamásabb dolog.
a gyengébbek kedvéért kiemeltem a lényegi részt, mely szerint a kompromittálódott account-ból valahogy (egyelőre fingjuk nincs hogyan) sikerül root jogosultságot kiverni és pl. belepiszkálni az rc3.d-be. mindezt úgy, hogy az üzemeltetőknek fel sem tűnt.

Logkai ellentmondás. Ha nem tűnt fel, akkor hogyan vették észre? Az egy dolog, hogy szereztek root-ot. Aztán valószínűleg a HIDS vagy nevezzük bárminek, ami ellenőriz - samhain, tripwire, stb. - sikított. Ennyi. Az meg, hogy nem tudják: észrevették, lehúzták, jelentették. Utána meg vizsgálnak. Ez a korrekt eljárás. Nem lehet mondani, hogy el is hallgatták. Szerintem teljesen korrekt volt a dolog.

eh, remek intrusion detection system lehet az, amelyik minimum másfél hetet elfilózik, mielőtt elkezd sikítozni. (persze lehet, hogy az üzemeltető szart rá magasról)

"Earlier this month, a number of servers in the kernel.org infrastructure were compromised. We discovered this August 28th."

"Break-in seems to have initially occurred no later than August 12th

[...]

Files belonging to ssh [...] were modified and running live. This seems to have occurred on or around August 19th."

szóval szerinted ez így oké, probléma egy szál se? ideologizáld már meg lécci, thx :)

Ha a kernel.org-t feltorik, akkor azt a cikk cimeben csak ugy kell emlegetni, mint "biztonsagi incidens", de ha masrol van szo, akkor ott mar lehet hasznalni a feltortek szot. Vicc.
Ha igaz, a level tartalma, amit linkeltem, akkor tobb mint 2 hetig nem is vettek eszre a csodauzemeltetok. Csak, hogy ez sem derul ki innen.

Nem erdemes ennyire tulmisztifikalni a dolgot.
Ha ugy erzed, hogy vmi hianyzik a cikkbol, akkor kuldj be egy uj hirt "Újabb fejlemények a kernel.org feltörésével kapcsolatban" cimmel, amiben reszletesen kifejtheted a gondolataidat. Ha nem tartalmaz tul nagy csusztatasokat, akkor Trey biztosan engedni fogja a megjelenest. Ennyi. Persze egyszerubb fikkantani.

"tobb mint 2 hetig nem is vettek eszre a csodauzemeltetok."
- gondolom mivel egy egyébként valid loginnal ment a császkálás. de kíváncsi lennék, te vajon mennyi idő múlva vennél észre a saját rendszereden egy hasonló történetet?

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( wachag | 2011. 09. 01., cs – 10:00 )

Ciki.

Avagy: "Én mondom, kegyetlen világban élünk!"

( ptomi | 2011. 09. 01., cs – 09:59 )

"Linus Torvalds, creator of the Linux kernel, says he's fed up with what he sees as a "security circus" surrounding software vulnerabilities and how they're hyped by security people."
Csak így tovább elvtársak...

Ugye tudod, hogy az általad idézett mondat több, mint 3 éve hangzott el, és a jelenlegi incidenshez semmi köze? (Már csak azért sem, mert úgy néz ki nem szoftveres sebezhetőséget használtak ki, és a kernel.org infrastruktúrájának üzemeltetéséhez valószínűleg nem sok köze van Linusnak)

Azért nézzük meg, hogy mihez tudtak hozzáférni. Módosítani tudtak a Linux kernel kódjában? Vagy egy bármilyen más célt szolgáló gépre léptek be? Az is lehet, hogy üzemeltetői hanyagság volt -> jaj, nem kell frissíteni, csak lokális kernel explioit. Távolról nem fognak belépni. Láttam már ilyet. Aztán csak pislogtak, mint hal a szatyorban, mikor látszólag nulla belépett userrel valaki ügyködött a gépükön. Ez van.

( current88 | 2011. 09. 01., cs – 10:04 )

Ez az aminek nem kéne előfordulnia, de mégis előfordul, egy kis piálás után kiszedték az egyikből a jelszavát :P
Vagy megjegyezetette a jelszavát egy nyilvános böngészővel... Előfordulhat, szerintem baleset. Csak sok munkát csinált vele. Remélem lebasszák érte az account tulaját rendesen.

( gabor2 | 2011. 09. 01., cs – 10:04 )

Inkabb a kinaiak. Mostanaban Ok nagyon aktivak.

Könyörgöm, aki nyitott szemmel jár, az tudja, hogy oda mennek be manapság ahova akarnak. Sony, bankok, CA-k, RSA, amerikai hadiipar beszállító, FBI, rendőrségek, amerikai kormányzati hivatalok. Meddig soroljam? Mindegyiknek nagyobb büdzséje és szakértelme kell hogy legyen mint a kernel.org-nak. Lassan kijelenthetjük, hogy csak oda nem törnek be, ami érdektelen.

Természetesen ez nagy probléma. Ez minden IT-t üzemeltető problémája. És a helyzet valószínűleg nem jobb, hanem egyre rosszabb lesz.

--
trey @ gépház

Egy kernel.org -ot nem azert tornek fel, mint egy bankot, vagyis ha a kernel.org egy, a lehetosegekhez kepest jol vedett rendszer lett volna, akkor nem tortek volna fel, mert nincs semmmilyen olyan adat ott, amihez maskepp nem tudnanak hozzajutni, es erdemes lenne heteket/honapokat/eveket szanni arra, hogy feltorjek.
Ha igaz, hogy privilege escalation tortent (es miert ne lenne az), akkor az az uzemeltetes bune, es pont, ilyet nem szabad megengedni egy produktiv rendszeren, foleg olyanon, amely ennyi felhasznalot szolgal ki. Arrol nem is beszelve, hogy az uzemeltetesnek fel kellett volna, hogy tunjon, hogy megprobaljak az oldalt feltorni.

(Eleve a kompromittalodott jelszo egy vicc a SSH publikus kulcs vilagaban, de ez mar az en privat velemenyem.)

-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

szerintem arra gondolt, hogy le vannak jelszavazva a privat kulcsok, es hiaba szereztek meg, nem tudjak a hozza tartozo jelszot, ennek a feltoresere mondta hrgy a komoly teljesitmenyt.
szerintem azt felejti el, hogy egyreszt felhivtak a figyelmet, hogy kompromittalodhattak az erintett szervereken tarolt kulcsok, masreszt ha vegiggondolja az ember, hogy peccselt sshd futott a szerveren, akkor onnantol kezdve nyilvan nem sima shellt kaptak a belepett userek, hanem szepen logolt mindent, tobbek kozott az erintett geprol tovabbsshzasnal megadott privat kulcshoz tartozo jelszot is.
szoval szerintem sanszos, hogy aki az adott idoszakban arrol a geprol hasznalta a privat kulcsat, azt mar fujhatja.

Tyrael

itt komoly szakemberekrol beszelunk, akik a linux nevu jelenseget fejlesztik.en sem ilyen komoly szakember, sem linux-fejleszto nem vagyok, de a notebookom titkositott merevlemezen (es annak a szinten titkositott mentesen) kivul sehol nincs meg a privat kulcsom.ha x gepen keresztul kell belepnem valahova, agent forwardingot hasznalok.ha meg adnek a securityre, egy tokenben tartanam a kulcsomat, amirol meg en sem tudom kinyerni.akkor itt mirol beszelunk? jelszavak, szervereken levo kulcsok..
--
zsebHUP-ot használok!

Ha mindenutt pubkey-only authot hasznaltak volna, akkor csak akkor kompromittalodhattak volna a kulcsok, ha valamely fejleszto desktop geperol loptak volna el a kulcsokat (es esetleg a hozzajuk tartozo jelszot).

Es onnantol mindegy, hogy a vedett rendszeren _belul_ hany helyen van meg a privat kulcs. Ha kompromittalodik a fejleszto gepe, akkor tokmindegy, ha meg nem, akkor meg mintha pancelban lenne. En azt latom problemanak, hogy volt olyan pontja a rendszernek, ami jelszavas authot engedelyezett.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

+1

És ez szerintem így is lesz még sokáig, mielőtt kellő szintre fejlődnek a protokollok, az auditálás, kriptográfia stb., hogy ne legyenek ilyen szinten sebezhetőek a szerverek.

Azt hozzá kell tenni, hogy a kernel.org esetében a repositoryk nem érintettek, és az állományokat a hash check miatt egyébként sem lehetséges észrevétlenül módosítani.

Igy osszegezve a hup kozonsegenek atlagos reakcioit a biztonsagi kerdesekben valami ilyesmi kep rajzolodik ki:

- ha feltorik a Sony szervereit, h akkor jon a "muhaha, ezek a gyokerek meg egy apacsot sem tudnak beloni"
- ha megnyomjak a Google-t a kinaiak, akkor jon az ajvekolas, h báncsák a jócéget!
- ha megnyomjak a kernel.org-ot akkor pedig azt olvasom mindenhol, h "hat igen, van ilyen", vagy "bezzeg te mikor vetted volna eszre". :)

Ez a sztori mar csak akkor lehetett volna stilusosabb, ha egy remote root kernel hole-on at toljak meg a szervereiket. :)

---
pontscho / fresh!mindworkz

Rosszul emlékszel :) Amikor a sony szerverei voltak terítéken, akkor a szoftverfejlesztők is gyökerek voltak az SQL-injekciójukkal együtt. Amikor a guglit, és még pár ámerikai multit, meg a grummant is megnyomták a kínaiak, akkor meg a ms volt a kocsog, mert "fél éven keresztül nem ment át" az "integrációs teszteken" a (nem létező) "fix", ami a "böngészőjüket" javította volna.

Mint láthatjuk a szervezetek, vállalatok szervereinek jelentős részét fel képesek kompromittálni, a kernel.org esetében akár azt is kijelenthetjük, hogy üzemeltetésből fakadó rendszerszerűség történt (minthogy a szerverek üzemeltetése rendszerszerűen azzal járhat, hogy kompromitálják azokat). ;-)

Sőt, azt is mondhatnánk, hogy a kernel.org infrastruktúrája kiemelten biztonságos, hiszen ezidáig nem sikerült kompromittálni és alighanem most is független tényezők vezettek ahhoz, hogy részben, de közel sem egészben ez megtörtént. ;-)

Magyarul: szerinted az, hogy a kernel.org-ot annyira felnyomták hogy root hozzáférésük volt, nem is komoly probléma, sőt, akár még komoly eredmény is lehet a biztonság szempontjából!

Gratulálok.

Amúgy trey is ilyesmit próbál sulykolni a "bárkivel megtörténik" szöveggel meg az "ugye nálatok is volt már" szavazással... Fájhat neki is eléggé.

Értem. Tehát ez ("nem csak a kernel.org egy szervere lett felnyomva, hanem egy rakás más gép is, többekközt a HPA saját gépe, aki az egyik x86 maintainer") egyátalán nem meglepő, durva, vagy megengedhetetlen, hiszen "üzemeltetésből fakadó rendszerszerűség történt".
Teljesen normális hogy jöttmentek root jogot szereznek pár gépen néha és bármit kompromittálhatnak, egy tök átlagos nap a melóban.

Szerintem ilyenért jobb helyen fejek hullanak és egyszer sem történhetne meg. Persze a Linuxot (mint projectet és mint rendszert) bántani tilos, a szarvashibákat pedig el kell bagatelliználni ahogy itt próbálják páran, a portálmesterrel az élen.

"Teljesen normális hogy jöttmentek root jogot szereznek"
- nyilván nem, de nem is állított ilyet (viszont nem is jelenti hogy bug lenne a rendszerben, hacsak a usert nem tekintjük annak, akinek kikerült a jogosultsága).

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Szerintem Hungerrel szellemeket kergettek, senki sem bagatellizál el semmit (felteszem ha ezt gondolod a smileyk ellenére még nem esett le, hogy csak trollkodok), ellenkezőleg, ti vagytok azok akik felnagyítjátok ezt az egészet, hogy ilyen soha, sehol nem történhet vagy történhetne meg, pedig igenis benne van a pakliban.

És hogy mennyire benne van azt jól mutatja, hogy a vállalatok, kormányok, kutatóközpontok stb. több mint 80%-a érintett lehet.

... félnek tőle és tesznek ellene...?

Mondjuk megalapozottabban lehetne osztani az észt, ha lehetne tudni, hogy hogyan is zajlott le ez az egész, mert anélkül egy kicsit mókás ez a sok kinyilatkoztatás.

Más esetekben is amiatt indultak meg az anyázások, mert kiderült, hogy ki hol kúrta el, és valóban orbitális hibákat vétettek. De most még egyelőre senki nem tudja h kinek a kvaanyja.

Nem gondoltam volna, hogy ő üzemelteti az összes beenugz szervert

Amúgy meg, don't glorify Linus. Ő is egy ember, véleménnyel. Lehet nem egyetérteni vele, én a magam részéről nem különösebben tartom jónak, ha egy bárakármilyen vezetői pozícióban lévő ember ennyire nyersen fogalmaz. Le lehet szarni, hogy milyen desktopot használ függetlenül attól, hogy binugzot használ az ember. Gondolom a win júzerek sem ugyanazt a tusfürdőt használják, amit Ballmer. Ilyen kritérium csak az apple-nél van :)

Ellenben a biztonsági biznisz "vírus" és irtó írása kezd olyanná fejlődni, mint az élelmiszer- és gyógyszeripar. Velük kapcsolatban nekem is hányhatnékom van.

Szerintem Hungerrel szellemeket kergettek, senki sem bagatellizál el semmit

Ó, hát persze, hogy nem, és mosdatás se történik, se itt, se a mindjárt utána berakott kamu-szavazás által... ;)

Meg az újra és újra visszatérő "nem bug volt, hanem user hiba" se az. :)

ti vagytok azok akik felnagyítjátok ezt az egészet

én nem nagyítok fel semmit, a helyén kezelem:

a kernel.org-os adminok kijelentései ellenére ez nem egy jól megtervezett - "szofisztikált" - támadás volt, mint a Lockheed Martin esetén (ami ugye itt példaként is felmerült egyeseknél, mint párhuzam, más célzottan támadott cégekkel egyetemben ;), hanem egy script kiddie galoppolt végig a szervereken egy gagyi Phalanx rootkittel, aminek még a működését se értette.

Látod, kettőnk között ez a különbség, hogy én el is olvastam az összes kapcsolódó levelezést és beszéltem hozzáértőkkel a témában (és nem mellesleg már jóval korábban tudtam az esetről, mielőtt publikálásra került volna), te meg csak trollkodsz itt tudatlanul, infók nélkül. ;)

No ennek örülök, hogy ekkora szakember veszi körül ezt a nyomorék hupot (néha nem is értem, hogy miért is süllyedsz le a szintjére), ilyen bennfentest ritkán látni, igazán büszke lehetsz magadra.

Annyit akkor el is tudnál mondani, hogy mi is lehetett a célja ennek a tudatlan kis suttyónak ezzel a kis epizóddal, mielőtt publikálnál egy "No Kernel Panic" üzenetet a körzetedbe tartozóknak :)

Hamar leszarom, hogy milyen információkat tud/hisz a magáénak. A kivagyiságot megtarthatja magának, ahogy te is -- ha eddig nem vetted le. Nem érdekel a mikéntje, csámcsogjon rajta, akinek ez a dolga, és akasszák fel, aki sáros benne.

Engem inkább az érdekel, hogy miért mentek be a szerverekre.

A suttyó esetleg "talált" magának egy módszert/eszközt, aztán nem tudott mihez kezdeni élete nagy lehetőségével? Vagy csak meg akarták mutatni, hogy ide is be lehet törni? Vagy éppen urban legendeket, FUD-ot akartak gyártani a kernellel kapcsolatban? Vagy szimplán csak ki akartak konkrétan valakivel kúrni?
Erre válaszoljál inkább, ha már te is hozzászakértettél.

Konkrétumok terén azért még mindig Hunger vezet, még ha meglehetősen szűkszavúra is méri, akár oda is figyelhetnél rá ha már nekiesel.

A miértek biztosan érdekesek, de arról jelenleg senki sem tud semmit, egyelőre a hogyanoknál tartunk, meg annál, hogy milyen szervereket, szolgáltatásokat stb. kompromitáltak a több mint 3 hét alatt észrevétlenül.

No végre egy emberi hozzászólás. Egy dolog miatt "estem neki", éppen a teljesen felesleges szívózása miatt. Pár lelki nyomorékot leszámítva még itt sem érdekel ez a része senkit, ahogyan a win isós topikban is.

Az meg hogy a "hogyanoknál tartunk" stb. rendben van, de akkor hagyjuk már ezt a rakás csúsztatást/összemosást (mások részéről is), hogy sony/gugli/gyugyugyu. Bár lehet h túl nagy dolgokról beszélek...

Ó, hát persze, hogy nem, és mosdatás se történik, se itt, se a mindjárt utána berakott kamu-szavazás által... ;)

Na várj, trey mindjárt kirak egy statisztikát is, hogy a HUP-on is már többször megtörtént hogy random hülyegyerek root jogot szerzett, tehát a kernel.org elleni támadás nem nagy ügy... Ellenben a Windowsok eddig hiányzó isofs támogatása, na az a hét híre és legnagyobb IT problémája! ;)

Bocsi, de a nap folyamán kevésbé értem rá. Mi a kérdés? Hiszen 11 órakor elismertem, hogy ez üzemeltetési hiba. A Windows ISO szálban elismertem, hogy a desktop Linux üzletileg szar. Képes vagyok én beismerni dolgokat. Nekem megy, látod. De neked megy-e már azzal kapcsolatban, hogy a Windows-ba mégiscsak jó lenne natív ISO támogatás, vagy a tagadási szakaszban vagy még mindig? :D

--
trey @ gépház

Én leginkább terelést láttam a részedről, főleg a szavazás kiírásával (kb "ugye, hogy máshol is előfordul?"), de ez az üzemeltetési hiba is megér egy misét.

Hogy minek a hibája hogy root jogot is szereztek, egyelőre nem derült ki. Root jelszót nem kaptak, úgyhogy az hogy te "elismerted" hogy üzemeltetési hiba, nem jelent semmit.
Feltehetően üzemeltetési hiba is közrejátszott.

A szavazás kiírása szerinted és Hunger szerint terelés, de valójában azt a célt szolgálta (huh, kulisszatitok), hogy amíg napközben mással vagyok elfoglalva (ennél sokkal, de sokkal fontosabb dologgal) és nincs időm tartalmat kitenni, addig is legyen valami az oldalon. A téma adott volt, egy szavazást 2 perc összehozni. Jól is mértem fel, ez a két "sztori" el is vitte a napot anélkül, hogy a kis ujjamat meg kellett volna mozdítani. A szavazás számomra meglepetés. Főleg az, hogy ennyi őszinte ember van.

"Az meg, hogy minek a hibája hogy root jogot is szereztek, egyelőre nem derült ki."

Azt mondanám elsőre, hogy az üzemeltetésé, de ha tudsz jobbat mást, ne tartsd vissza. Sajnos nem volt időm a szálat elolvasni, így csak tippelni tudok.

--
trey @ gépház

Azt mondanám elsőre, hogy az üzemeltetésé, de ha tudsz jobbat mást, ne tartsd vissza. Sajnos nem volt időm a szálat elolvasni, így csak tippelni tudok.

Féretéve a "Linux szent és feltörhetetlen" axiómát én inkább első körben valami új local root sebezhetőség kihasználására gyanakodnék, ami csak az "üzemeltetési hiba" elég tág értelmezése (ti. az üzemeltető kötelessége felderíteni és kijavítani az általa üzemeltetett szoftver ismeretlen és/vagy eddig javítatlan hibáit is) esetén tekinthető ennek.

Ellenben, ha feltesszük hogy valóban olyan hibásan üzemeltetik a kernel.org servereit, hogy bárki észrevétlenül legfelső jogosultsági szinttel ki-be járkál 3 héten át, akkor ezt a vmlinuzizét nagyon gyorsan gyalulni kéne az összes gépről, mert hasonló üzemeltetési hibák során bárki hagyhatott benne jópár kis meglepetést.

( BlinTux v | 2011. 09. 01., cs – 10:47 )

Lehet, hogy csak én látom túl egyszerűnek a dogot, de miért akarna bárki is ellopni egy egyébként ingyenes forráskódot? Tehát mi van ott mit védeni kell?

Hogydejolmondod. Nekem is ez ugrott be elso gondolatkent amikor olvastam valahol a hirt. Bar... Nem tudom az alrendszerek karbantartoi milyen utvonalon keresztul toljak Linus fajaba a valtozasokat, de ha ez nem megy keresztul a kernel.orgon akkor EMIATT nem kell aggodni a kod tisztasagaert.

http://gpsforum.hu - Navigációról szájkosár nélkül

Lenne egy kérdésem, szeretném megtudni, hol tévedek:

ugyebár többen fejlesztenek. E/1-ben fogok beszélni az egyszerűség kedvéért, bár nem vagyok kernel fejlesztő (hála az égnek). Egy git pull esetén kiderül, hogy valami módosult. Ha egy olyan file volt, amibe én szoktam kotorászni, de tudom, hogy én nem nyúltam bele, viszont conflict van, nem nézem meg, mi is a probléma? Nem veszem észre, hogy valaki belenyúlt? (konkrétan Subversiont használtam jó ideig, ott tudtam követni mikor mit nyúltak bele).

Szóval a git (meg általában egy verziókövető rendszer) nem támogatja a backdoor-beültetésnek a kivédését? Nagy meló, de azért kezelhető, nem?

Jogosnak tartom amit mondasz. De azért bízom abban, hogy van annyi ellenőrzés a kernel kódja felett, hogy ha valaki rosszindulatú kódot akarna beletenni, akkor azért kiderül még a beolvasztás előtt. Nem mint ha feltételezném, hogy linus végigolvas minden sort amit beolvaszt.

Egyébként ha valaki belenyúl egy fájlba, amiben te szoktál ügyködni nem jelenti azt, hogy conflict keletkezik, hacsak nem ugyanazt a sort módosítja amit te is, halkan mergeli a fájlokat. Azt meg vagy észreveszed miközben generál néhány ezer sort, vagy nem :)

De azért bízom abban, hogy van annyi ellenőrzés a kernel kódja felett, hogy ha valaki rosszindulatú kódot akarna beletenni, akkor azért kiderül még a beolvasztás előtt.

majd beolvasztja a támadó közvetlenül a mainlineba... neki nem kell végigjárni azt az utat, amit a fejlesztőknek, hogy bekerüljenek a módosításaik ;)

Peldaul jol idozited es telekurod meg a logot nehany kobmeter hasznos/haszontalan informacioval. Volt ra pelda, h egy egy karakteres gyengeseget 1000 soros patch-ben rejtettek el es siman atcsuszott minden ellenorzesen, pusztan mert emberek vagyunk es egyben idiotak is.

---
pontscho / fresh!mindworkz

Ezt hogyan kell elkepzelni?

Valamikor valaki commitol valamit xxx hash-re, feltehetoleg erre a commitra is erkeznek ujabb commitok.
Ekkor valaki betor a kernel.org-ra, atirja az xxx commitot, a hash-t is megvaltoztatja xxy-ra. De ilyenkor mi lesz azokkal a commitokkal, amiknek xxx volt a parentje?

Tenyleg erdekel, mert nem tudom.
--
HUP Firefox extension

Többféle módszert eltudok képzelni, de nem akarnék nagyon tippeket adni...

Mivel alapvetően root jogot is szerzett az emberke és az sshd-t is lecserélte, innentől kezdve különösebb erőfeszítés nélkül akár a git-daemont is lecserélhette volna (meg a git klienst is).

Egy ügyesen módosított gittel pedig eljátszható akár az is, hogy minden egyes kliensnek kicsit mást szolgáljon ki. Pl. X és Y fejlesztőknél a backdooros commitot úgy adja át, hogy X azt hiszi Y-tól ered a módosítás, Y pedig azt, hogy X-től.

Egy módosított gittel bármi kivitelezhető, csak erre kevesen gondolnak, mindenki azon agyal csupán, hogy magával az eredeti gittel hogyan lehetne gonosz commitot injektálni észrevétlenül, holott ennél sokkal távolabbról kell megvizsgálni a problémát (pláne, hogy több rendszer érintett, közte fejlesztői gép is).

az a lenyeg, hogy azt a historyt nem tudod meghamisitani amit mar masok lattak.
ugy epulnek egymasra a commitok, mint az eletronikus szamlazasnal a kiadott szamlak.
http://www-cs-students.stanford.edu/~blynn/gitmagic/ch08.html#_indistin…

tehat, ha hozza is fersz a repoboh fizikailag, 2 dolgot tudsz megtenni:
betolod a backdoort a headbe, es remenykedsz, hogy senki nem szurja ki.
vagy megpeccseled a git szervert, hogy linus-nak mutatod a vanilla verziot, a tobbieknek pedig becsempeszel 1 latszolag linustol szarmazo commitot, ami a backdoort tartalmazza.
ha azt nem szurja ki senki, akkor jo vagy addig, amig nem akar linus valakitol pullolni(nyilvan akar, hiszen igy tortenik a fejlesztes), mert akkor ki fog derulni, hogy a 2 clone historyja divergal egymastol csunyan.

mindket esetben utolag visszakovetheto, hogy a tamadas idopontja utan tortent-e modositas a repoban.

szerintem.

Tyrael

Ne önálló backdoor commitban gondolkodj, hanem egy fejlesztő valid commitjának részeként, amely akár on-the-fly patchelésre került úgy, hogy a többiek az eredeti commitot nem is látták. Eleve mindenki a backdooros committot kapta, az eredeti fejlesztőnél van csak a backdoor mentes változat, ő meg egy pull alkalmával megkapja a backdoort egy másik fejlesztő commitjának részeként és a kör bezárult, mindenkinél a backdooros verzió lesz, csak egyvalakinél más lesz a history, de ettől még ütközést nem okoz.

De mint írtam egyszerűbb a fejlesztő oldaláról kivitelezni az egészet, ahol a dev önmaga fogja akár commitolni a már backdooros kódot és sehol se marad nyoma.

Mivel a kernel.org-on localban is történik ilyen commit, ezért akár azon is kivitelezhető ez, nem szükséges a fejlesztő saját gépét feltörni hozzá külön (de mint látható az se kivitelezhetetlen).

igy van, a legjobb megoldas amit tehettek, hogy a fejleszto valid lokalis modositasi koze csempesztek be a backdoort.
igy mindenki ugyanazt latta, a fejleszto nem lepodik meg, hogy van egy commit amit nem o csinalt, a tobbiek jo esetben megbiznak benne, ezert nem nezik at olyan alaposan.
viszont ezzel eljutottunk odaig, hogy csak a tamadas utan tortenhetett az a commit, ami becsepmeszte a backdoort.

Tyrael

"Ne önálló backdoor commitban gondolkodj, hanem egy fejlesztő valid commitjának részeként, amely akár on-the-fly patchelésre került úgy"
ertem a peldadat, es el is tudom kepzelni, hogy ezt szo nelkul lehuzta volna a tobbi fejleszto alaposabb atnezes nelkul.
viszont amirol en (es szerintem a tobbiek is)beszeltem az az volt, hogy visszamenoleg a history-ban nem tud modositast csinalni feltunes nelkul, mert ott nem a fejlesztok hanem a git mindenkeppen csipogni fog erte, tehat a backdoort tartalmazo commit csak a szerverekre tortent behatolas utanra datalolhat, ezert hiaba fertek hozza a repohoz.

"backdooros committot kapta, az eredeti fejlesztőnél van csak a backdoor mentes változat, ő meg egy pull alkalmával megkapja a backdoort egy másik fejlesztő commitjának részeként és a kör bezárult"
ez nem igy mukodik, ha nem a fejlesztotol erkezett a patkolt commit, hanem utolag patkolta bele a commitba a tamado a modositast, akkor mas hasht fog latni 2 klon, ezert nem fog visszacsorogni az megszemelyesitett fejlesztohoz a backdoor.

Tyrael

hogy venné észre... egy rakás fejlesztő tolja be a kódját, nem csak egyirányú commitok vannak, a backdoor meg lehet egy egyébként legitim nagyobb frissítésbe is beágyazva, amit ő szépen nyugtázva elfogad

de ha nagyon megzavarja a gondolkodásodat a backdoor, akkor gondj rá úgy, mint egy bugra... szoktak becsúszni bugok a commitokba, vagy bug-free a kernel?

Ettől függetlenül, ha egy adott kernelfejlesztő által karbantartott részterületnél a git pull/push panaszkodna, akkor azt észreveszi, és mivel az a terület az övé (ahhoz ért a legjobban), nyilván megnézi, mi is okozta az ütközést.

Mindenkinek van saját repositoryja a saját gépén, amin dolgozik, a kernel.org publikálásra való. Ebből a szempontból érdektelen, hány gépet törtek fel ott.

Viszont mindenkinek igaza van, többet kellett volna tenniük az üzemeltetőknek, hogy lehetőleg ne fordulhasson elő local root exploit. valamint a binárisok módosítása.

Egyrészről találkoztunk már olyannal, hogy egy adott részterületnek nem volt karbantartója... ;) Másrészről 10000+ commit van releasek között és csak szép álom az, hogy mindegyiket alaposan átnézi mindegyik fejlesztő.

Továbbá azt se mondta senki, hogy ütközést fog generálni a backdoor... Akár magán a fejlesztői gépen is módosíthatja a támadó azt a részt, amelyről aztán - egy nagyobb volumenű frissítés részeként - commit készül és a rendszer részeként megy tovább. Ha ez egy olyan fejlesztő, akitől a Linus pull-oz, akkor jó eséllyel kapásból be is kerülhet Torvalds úr fájába. ;)

Nem mondtam, hogy könnyű kivitelezni egy ilyen backdoor bejuttatását. Azt se, hogy a jelenlegi incidensnél történt ilyesmi, viszont hogy nem lehetetlen megoldani, abban biztos vagyok. Se digitálisan nincs aláírva minden egyes fejlesztői commit, amely a tartalmának a sérthetetlenségét szavatolhatná, se a fejlesztői gépek nem feltörhetetlenek (mint ahogy a jelenlegi eset is mutatja), úgyhogy van bőven támadási felület.

"Se digitálisan nincs aláírva minden egyes fejlesztői commit, amely a tartalmának a sérthetetlenségét szavatolhatná, se a fejlesztői gépek nem feltörhetetlenek (mint ahogy a jelenlegi eset is mutatja), úgyhogy van bőven támadási felület."

=> Igen.

De mindent meg lehet ideologizálni.

----------------
Lvl86 Troll

Nem arról van szó, hogy törhetetlen-e vagy sem, mert minden az, hanem arról, hogy többet vártak volna attól, hogy egy ilyen jelentőségű gépet így megtörjenek.

@Digitális aláírás: helyfüggő és szoftverfüggő nyilván. Ami alapból támogatja, azzal nyilván egyszerűbb is megoldani.

http://en.wikipedia.org/wiki/Comparison_of_revision_control_software#Fe…

(És, mielőtt kérded, nem, nálunk sem volt digitális aláírás az SVN-n a volt munkahelyemen, igaz nem is a világ elszórt pontjairól commitolgatott egy csomó egymás számára ismeretlen ember hanem csak néhány az irodából.)

----------------
Lvl86 Troll

"Nem arról van szó, hogy törhetetlen-e vagy sem, mert minden az, hanem arról, hogy többet vártak volna attól, hogy egy ilyen jelentőségű gépet így megtörjenek."

Sorry, de ezt a választ nem is értem.

"@Digitális aláírás: helyfüggő és szoftverfüggő nyilván. Ami alapból támogatja, azzal nyilván egyszerűbb is megoldani. "

Akkor felteszem a kérdést úgy, hogy a FreeBSD, OpenBSD, NetBSD, DragonFly BSD, nyílt forrású szoftverprojektek, meg a szoftverfejlesztéssel foglalkozó egyéb - zárt forrású - vállaltoknál mennyire bevett szokás ez?

Esetleg csináljunk belőle kamuszavazást?

--
trey @ gépház

"Akkor felteszem a kérdést úgy, hogy a FreeBSD, OpenBSD, NetBSD, DragonFly BSD, nyílt forrású szoftverprojektek, meg a szoftverfejlesztéssel foglalkozó egyéb - zárt forrású - vállaltoknál mennyire bevett szokás ez?"

Sose értettem, hogy miért kell a szomszéd portájára mutatni, hogy "de nem csak mi hagyjuk ott rohadni a szemetet a lakásajtó előtt"...

Fentebb meg linkeltem egy táblázatot az SCM-ekről. Elég jól látszik belőle, hogy mi támogat alapból aláírást. Van köztük nem kevés olyan, amit nagyobb vállalatoknál használnak.

----------------
Lvl86 Troll

Nem mutogatok, hanem beszélgetünk, aminek keretében információkat kérek. Arra vagyok kíváncsi, hogy mivel lehetne javítani ezt a folyamatot. Nyilván, ha azt a választ adod, hogy mindenki használja, csak itt nem használják, arra azt fogom mondani, hogy valóban baromság, hogy nem teszik. Ha azt mondod, hogy van ez a lehetőség, de a gyakorlatban szinte senki sem használja, mert lassítja/nehezíti a munkát, az is egy válasz.

De úgy fest neked valamiért nehezedre esik válaszolni.

--
trey @ gépház

Igazából bennem pont az a kérdés merült fel, hogy ha egy kiddie ennyi bénázás mellett ezt tudta kivitelezni és ennyi ideig még így is észrevétlen maradt, akkor az azt jelenti, hogy ezen a gyereken kívül senki se próbálkozott vagy azt, hogy más - komolyabb - arcok is bementek, csak azokat észre se vették... ;)

nyilvan az ellen nem ved.
amit szerintem erdemes eszben tartani, hogy a beszelgetes kiindulopontja az volt, hogy eszrevetlenul meg tudjak-e modositani a kernel forrast.
nyilvan sokkal egyszerubb elrejteni a backdoor-t, ha az idok kezdete ota barmelyik revizioban benne lehetne a kerdeses modositas.

Tyrael

Ezt a gondolatmenetet követve érdekes lenne megnézni, hogy a kernel AUTHORS fájljában hány olyan Név + email szerepel, akit még soha senki nem látott, és egyáltalán nincs azonosítva. Kellően ügyes támadó relatíve egyszerűen felépíthet egy "jószándékú kernel fejlesztő" legendát, aki kicsi de "hasznos" bugfixekkel segíti a fejlesztést, egy kevésbé ismert, de sokak által használt alrendszerben, ahol jó eséllyel könnyebben tud bejuttatni egy backdoort a "bizalom körébe", ahol már nem reviewzzák újra a kódjait mielőtt bekerülne a vanilla release-be.

Mondjuk én ha támadó lennék, és sok kliensgép fertőzése lenne a célom, inkább a disztrókat céloznám meg, pl. az Ubuntu-t. Ha egy kellően zavaró driver hiányt vagy bugot sikerül "javítanom", akkor szerintem elég egyszerűen be lehet juttatni. Legalábbis a 10.04 kernel karbantartása során végzett szerencsétlenkedésük alapján (LTS-ben egy bugfix release elrontja az LXC támogatást ... stb.), nem nézem ki belőlük, hogy felismernének egy jó backdoort.

Üdv,
Gergely

( bajnokk | 2011. 09. 01., cs – 11:19 )

Arról nem szól egyik írás sem, hogy a letölthető .tar.bz2 file-okba került-e backdoor. Gondolom, nem egy olyan van, aki használja (pont ezért letölthető), az most szívott.
Azért azt feltételezem (bár biztos nem lehetek benne), hogy egyik disztribúció-maintainer sem csinált ilyet, mert mindenki gitet használ.

( thuthu | 2011. 09. 01., cs – 11:34 )

Eddig csak joindulattal raktak bele lukakat... :)

( uid_228 | 2011. 09. 01., cs – 12:34 )

Remote root exploitot találtak a kernelben, gyorsan frissítsen mindenki! Oh, wait... :)))

--
Steve Jobsot nagyra becsülöm üzletemberként és sajnálom, mint magánembert.
Viszont mint vallásalapítót, ki nem állhatom.

( balintdavid | 2011. 09. 01., cs – 12:41 )

subscribe for the lulz
----------------------------------------------------------
relaxen und watchen das blinkenlichten

( wachag | 2011. 09. 01., cs – 13:36 )

Nézzük a jó oldalát: a jóegypár éves OpenSSL sebezhetőség helyett a továbbiakban lehet majd ezen lovagolni néhány évig.

( asm v | 2011. 09. 01., cs – 13:49 )

Errol jut eszembe, vegulis mi lett a vege a "regota backdoor van az openbsd kerneleben" storynak? Talaltak vmit vagy bizonyitek hianyaban elsorvadt a tema?

( b | 2011. 09. 01., cs – 14:16 )

Huh, ki a faszt érdekel... Linus gépe számít csak. Majd mehet neki egy git clone request. Kernel.org-osok meg majd jobban vigyáznak...

--
GPLv3-as hozzászólás.

Nem olvastam el azt a szálat csak a linkelt posztodra reagáltam itt. Kifejezetten erre a rész mondatodra:

> de ha nagyon megzavarja a gondolkodásodat a backdoor, akkor gondj rá úgy, mint egy bugra...

A poszt kontextusát nem ismerem, de erre a mondatra szívesen reagáltam ebben a szálban. :P

--
GPLv3-as hozzászólás.

AAaahahahahahhahhhahahhahhahhahhahahh :D

Az ÉV kommentje!

Gyengébbek kedvéért: vajon mi lehet a fontoabb?
- Egy ember saját homokozója, amit bármikor cserélhet, mintha csak az alsóneműjét cserélné.
- Egy központi szerver, amiből a fél világ dolgozik.

----------------
Lvl86 Troll

( csicsa55 | 2011. 09. 10., szo – 12:52 )

Láttátok ma a kernel.org-ot?

Nem tudom lehet-e összefüggés a múlt heti dolog és e között, vagy pusztán csak karbantartás.

*****************************************************************************
Mielött beletaposnál a lelki világomba a 7 perc 30 másodperctől nézd meg ezt.

Debián forevör

""Jay És Néma Bob Viss..."
Ez a videó már nem érhető el, mert a kapcsolódó YouTube-fiókot megszüntettük harmadik felek ismétlődő szerzői jogi értesítései miatt; a panaszosok közé tartozik például:

Record Industry Association of Japan
Weinstein
Weinstein"

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség