Biztonsági incidens a kernel.org-on

 ( trey | 2011. szeptember 1., csütörtök - 8:37 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

ez a microsoft...

ez most mit jelent?

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

Tudod, mindig az MS a hibás ;)

de most kivételesen Gyurcsány.
------------------------------------
A Windowsról sokat elárul, hogy Slackwaret könnyebb telepíteni.

"Blame Canada!" :)
__
http://fodi.be

semmit, csak ideböfögtem valamit. írhattam volna, hogy ennyi a leenugz, meg bezzegazosx, meg ilyesmi, de mivel nem en vagyok gabu, igy csak a huptudat egy megnyilvanulasat irtam le.

Valoban szukseges volt.

---
pontscho / fresh!mindworkz

köszönöm a bátorítást.
illetve a szerkesztés link mellett nincs töröl link.

"Ne azon tűnődj, hogy hozd helyre vétked, inkább azon, hogy ne kövesd el azt."

Köszönjük a hasznos észrevételt. Egyáltalán nem közhelyes.

utanakerdeztem microsuxosoknal, azt mondtak, hogy "monkey" ballmer megbizott egy csoportot azzal, hogy lopjak el a linux kodjat, hatha fel tudnak belole hasznalni valamit.vegiggondoltak, hogy ha a windowset kellene ellopniuk, mit tenenek, majd elloptak.
--
zsebHUP-ot használok!

de nem az apple? :)

"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."

áh, ők a google-be törnének be, törölni az androidot a gitből:)

minek, a tarolt valtozatbol barmikor visszaallnak :)

thatsthejoke.jpg

"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"

Csak akkor ha a kapanyél kilóg a szádból, mint esetedben vélelmezhető, minden más esetben biztonsági incidens a kernel.org-on.

márpedig ezt felnoymták a f@szba.
neked meg nem áll jól a hivataloskodás, nem ügyvéd vagy egy bírósági tárgyaláson...

> márpedig ezt felnoymták a f@szba.

Dicséretes hogy nem csinálsz úgy, mintha értelmiségi lennél.

ha valamit feltörtek a g**be, vagy felnyomtak a f@szba, akkor azt miért ne lehetne kimondani?
miért álszenteskedsz ezen? ez történt.

Dicsértelek, ne reklamálj.

merthogy valamennyire is figyelembe kéne venni, amit írsz?

Már megtetted.

neked komplexusaid vannak?

Új lehetsz errefelé. :-)

> neked komplexusaid vannak?

Köztünk szólva: nincs; nyilvánosság előtt viszont tagadom.

nem kell ahhoz ügyvédnek lenni hogy feltűnjön a paraszt stílus...de ráadásul a kettő között meg semmi összefüggés nincsen..

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

Ha legközelebb valakinek a stílusát nehezményezed, érdemes odafigyelni a központozásra, ellenkező esetben hiteltelenné válhat a mondanivalód.
Ez elég cizellált volt? :D


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

még szerencse hogy ez a veszély nálad nem fenyeget..

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

Fenti hozzászólásodat a többi, jelen hírhez írt kommented tükrében értékelem és kezelem helyén.
szerk.: most látom, hogy nem hangsúlyoztam eléggé a központozás hiányát. :-(


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

"Fenti hozzászólásodat a többi, jelen hírhez írt kommented tükrében értékelem és kezelem helyén."
- igazán megtisztelsz vele, bár nem ezt vártam tőled!

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

Ezért szoktam én azt mondani, hogy érdemes mindig a legrosszabbra számítani, mert csak pozitívan csalódhatsz. :D


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

Ilyenről szó nincsen, azért amiért te pozitívan csalódtál, attól még én ugyanezt nem osztom veled kapcsolatban...

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

"valószínűsítik, hogy egy kompromittálódott account-ot használtak fel támadók,"
- fel bazeg', volt hozzá jelszavuk...lol

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

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

bocs, ez nem neked szólt hanem a fenti okostojásnak...

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

fel bazzeg'
"We believe they may have gained this access via a compromised user credential; how they managed to exploit that to root access is currently unknown and is being investigated."

"valószínűsítik, hogy egy kompromittálódott account-ot használtak fel támadók,"
- ez szerinted ugyanazt jelenti?

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

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 :)

"Aztán valószínűleg a HIDS vagy nevezzük bárminek, ami ellenőriz - samhain, tripwire, stb. - sikított."

Valoszinuleg nem.
A trojan maga sikitott. :)

--
"You're NOT paranoid, we really are out to get you!"

Most mit kell ezen csodalkozni. Ez a hup. Itt nem lehet a cimbe kiirni, hogy feltortek a linux kernel-t kiszolgalo infrastrukturat. Arrol meg vegkepp hallgatni kell, ami itt olvashato. Szokasos tereles trey modra.

ha igazad lenne, akkor most nem lenne mire reagálnod, nem lenne hová kommentelned...

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

Mond, te mirol beszelsz?

És te? Elég egyértelmű a cím minden a csirkénél komplexebb idegrendszerű lény számára, te meg itt osztod, hogy bullshit. Minek, nincs jobb dolgod?

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.

ezert van a link, hogy utanaolvass.

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

Ez nem túl jó fordítás. Bár, igaz, azt is szokták mondani hogy "feltörték az ivivem", amikor az történik, hogy bejelentkezve hagytad a könyvtárban, a következő ember meg kíváncsi volt.

hát ha a local privilege escalation nem fér bele ebbe a kategóriába, akkor nem tudom, mi a feltörés :-)


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

Ciki.

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

"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)

Már csak azért sem, mert úgy néz ki nem szoftveres sebezhetőséget használtak ki

persze, a root prompt meg csak úgy előpattant a semmiből

biztos benne volt a sudoers-ben az adott acc :D


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

“Files belonging to ssh (openssh, openssh-server and openssh-clients) were modified and running live”
“A trojan startup file was added to rc3.d”
security rulz...

Hint: a kernel.org -on linuxot hasznalnak. Fussunk neki megegyszer, hogy kinek mihez mennyi koze van?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

inb4: "nem a Linux hibája, hanem az xyz csomagé ami nem is a Linux része, mert a Linux csak a kernel!!!44"

És nem a kernel(.org)-t törték meg? ;)

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.

Vitéz Úr! Vit'z lett vóna.

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.

Utana holnaptol ne legyen commit joga. Aki ennyire biztonsagtudatos, az inkabb ne fejlesszen kernelt.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Mondd a tutit.
Oktass!
Taníts!

(az itteni megnyílvánulásaid alapján akkor viszont téged nem szabadna éles rendszer közelébe engedni...)

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

Benne van ebben az üzemeltetés, nyilván. Viszont amire félezer embernek van account-ja az minden, csak nem jól védett rendszer. A kompromittálódott jelszót honnan vetted? SSH kulcsok cseréjét emlegették a kernel.org-on.

--
trey @ gépház

"That said all users may wish to consider taking this opportunity to change their passwords and update ssh keys (particularly if you had an ssh private key on hera)."

Igen. Az SSH privkey feltorese komoly teljesitmeny lett volna, ha pedig kompromittalodott volna egy ssh privkey, akkor pedig mas lenne a hir cime.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

SSH privkey-t minek feltörni? Elég ha megszerzik és használják...

"ha pedig kompromittalodott volna egy ssh privkey, akkor pedig mas lenne a hir cime."
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Továbbra se értem mit szeretnél mondani.

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

Nem kell hozzá sshd-ben mindent loggolni, elég akár csak az ssh klienst patchelni, hogy az loggolja le a beütött jelszót (én anno egy pentest alkalmával pl. így csináltam... ;)

az konkretan szerepelt a bejelentesben, hogy az sshd meg volt patkolva, ezert hoztam fel ezt peldakent, nyilvan onnantol hogy rootjuk van a gepen barmit lecserelhettek.

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!

sok a fixálandó bug, ők nem érnek rá ilyesmire :)

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

Egyrészről fejlesztői gép is kompromitálódott, ergo onnan _is_ lophattak kulcsot. Másrészről a kernel.org szerverekre is voltak feltöltve privát kulcsok, amiket szintén kompromitáltnak kell tekinteni. Innentől teljesen mindegy, hogy jelszavas authentikáció volt vagy sem.

De ez most a kernel.org, és ezért most szar a binugz, éééted-e?

+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.

miért a hasheket hol tárolják? ;)

A hasheket elő lehet szedni backupból is. Remélhetően ügyesebbek lesznek a kód sértetlenségének ellenőrzésében mint az üzemeltetésben...

Tíz cégből nyolchoz betörtek az elmúlt évben

A maradék kettőben meg nem vették észre.

--
trey @ gépház

Ilyen ez, köztudott, hogy az informatikai biztonság western korában vagyunk, a banditák csak hihasználják a helyzetet.

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

A "vedd észre" STP egy nagypofájú "nyílt a forrás, miért nem te javítottad ki" benyögésére volt válasz. Megérdemelte.

Szinten csak egy kiragadott pelda volt, nem a jogossagat vettem figyelembe (amugy ha mar szobakerult, jogos volt:).

---
pontscho / fresh!mindworkz

Vigyázzatok!
Mindkettőtöknek bevéstem egy q nagy fekete pontot! :)
(Mondjuk csigán poncsót is ritkán lát az ember. Lehet, hogy mehikói?)

Nem értelek, hogy miért ebbe a szálba toltad, hiszen a postod előtt már leírtam, hogy az üzemeltetés ebben benne van.

--
trey @ gépház

"vagy "bezzeg te mikor vetted volna eszre". :)"
- nem bezzeg, bazeg'. eléggé szelektív a lista, oda kellet volna írni a sötét oldal reakcióit is.

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

vartal komolyabb hozzaallast? :)

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.

Az ember mar csak ilyen, ritkan tud objektiven hozzaallni a dolgokhoz. Azt is hallottam, hogy sokan vannak olyanok, akik meg sajat magaukkal is ellentmondasba kerulnek.
--
HUP Firefox extension

Ez igy van, ezert nyujt elvezetes humorforrast a gorbetukor.

---
pontscho / fresh!mindworkz

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é.

nem, magyarul nem ezt állította, tessék nekifutni még egyszer!

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

É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

És hogy hogyan lett root, azt ismét leszarjuk... biztos nem valami bug miatt.

és vajon a user hozzáférés hogy került a támadó kezébe? biztos a háta mögül leleste a jelszót és/vagy a privát kulcsát... ;)

biztos... ha te mondod, csak is így történhetett...

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

"biztos nem valami bug miatt."
- nem biztos, de az ellenkezője se :)

--
"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.

A különbség csak az, hogy egyik helyen félnek tőle és tesznek ellene, miközben a másik helyen...

... 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.

Linus Torvalds: Don't glorify the security "monkeys"

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.

"a kernel.org-os adminok kijelentései"

Nekem elég csak Linus security témakörben tett kijelentéseit visszakeresni, hogy elsápadjak.

Ha ténylegesen egy script kiddie tette ezt egy rootkittel akkor ez meglehetősen nagy presztízsveszteség, sőt.

No dejó, hogy így megszakértetted ennyi infó alapján. Látod én még azt sem értettem, hogy a hangulatkeltésen kívül mi célja lehetett ezzel a betöréssel az illetőnek, de te most világosságot gyújtottál. Thx

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 :)

"ilyen bennfentest ritkán látni, igazán büszke lehetsz magadra."

Hamar elfogytal.

--
"You're NOT paranoid, we really are out to get you!"

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...

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

Dehogy ment be. Beesett szerencsetlen. Veletlenul.

--
"You're NOT paranoid, we really are out to get you!"

Idézet:
Ó, 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

Idézet:
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.

Az üzemeltetési hiba nálam ott kezdődik, hogy mi a faszér' van egy ilyen kritikus gépparkra 48x embernek local accountja. Próbáljunk meg a forró kályha felé menni és ne onnan elindulni.

--
trey @ gépház

Az a kijelzőpaneltől és beállításoktól (fényerő, kontraszt), valamint a böngészőtől is függhet, hogy mennyire tartom ezt eredménynek a biztonság szempontjából.

azt is mondhatnánk, hogy a kernel.org infrastruktúrája kiemelten biztonságos

mondhatnánk, hangos kacarászás közepette

ezidáig nem sikerült kompromittálni

de, ez már legalább a 3. alkalom

"oda mennek be manapság ahova akarnak"

mert ezen is linux fut!

--
NetBSD - Simplicity is prerequisite for reliability

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?

Nem ellopni, hanem pl. trójait tenni bele és hivatalos serveren, hivatalos kódként terjeszteni.
Így már kicsit más a helyzet nem?

Igazad van! Erre nem is gondoltam hirtelen :)

Ez azt jelenti, hogy root jogot könnyebb szerezni a kernel.org-on, mint commit jogot.

lol

Pontosan a forraskodot kell vedeni, hogy ne tegyenek bele backdoort.
Eleg ciki lenne ha az uj 3.1-es kernel igy jelent volna meg...

Mert, nem igy jelent meg? :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Mivel ezt pont észrevették, pont ezzel, nem adják ki.

És ha van olyan, amit pont nem vettek észre?

Nyílt a forrás. Olvasd el, vedd észre.
--
unix -- több, mint kód. filozófia.
Life is feudal

FreeBSD-t jobban szeretem. Keresgesse, aki akarja.

Nem baj. FreeBSD-n is lehet Linux kernelt olvasgatni :P
--
unix -- több, mint kód. filozófia.
Life is feudal

Lehet, de nem kötelező.

A git felepitesebol adodoan gyakorlatilag az osszes fejleszto gepen ott a teljes, sertetlen backup.

--
Always remember you’re unique, just like everyone else.

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?

A cikkben linkelt Corbet írás pont ezzel foglalkozik.

--
trey @ gépház

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 ;)

Ahhá, akkor ez csakis Con Kolivlas lehetett ;]

Ugyan, a multkori massziv OpenBSD + IPsec musor megmutatta, h ez az ut sem olyan rocogos igy az opensource qa-ban. :)

---
pontscho / fresh!mindworkz

Git eszkozoket ad a change/backlog manipulalasahoz is.

---
pontscho / fresh!mindworkz

... amik használatával értelemszerűen megváltozik a módosított file-ok és commit-ok sha1 ellenőrző összege, és a következő fetch-nél vagy push-nál egyből kiböki a szemedet, hogy nem az van a szerveren, mint aminek lenni kellene.

Ha megfelelo kontosbe bujtatod, akkor megoldhato, h eszrevetlen el tudjon bujni. Sokszor bizonyitotta mar ezt a valosag.

---
pontscho / fresh!mindworkz

És hogyan tudod megfelelő köntösbe bújtatni?

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

Teljesen másról beszélsz.

Szerintem nem. Csak egyszerubb peldat hoztam fel hosszas magyarazat helyett.

---
pontscho / fresh!mindworkz

értelemszerűen megváltozik a módosított file-ok és commit-ok sha1 ellenőrző összege

loop

Nem csak a kernel.org-on, hanem a fejlesztők gépein is, hth.

Majd git pull esetén lecsorog a fejlesztőkhoz is a backdoor a sok más committal együtt, hth.

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

Hunger, ^-- erre valaszolnal legszives. Alapvetoen arra vonatkozik a kerdes, hogy mikeppen tud egy ilyen modositas visszacsorogni a fejlesztokhoz?
--
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#_indistinguishable_from_magic

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).

Az eltérő history eltérő sha1 checksumokat jelent, azok viszont git-en kívül is utaznak, úgyhogy ez sem maradna észrevétlen.

"De mint írtam egyszerűbb a fejlesztő oldaláról kivitelezni az egészet"

Ott nem lesz semmi eltérő, úgyhogy ne fussunk további felesleges köröket.

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

Kérdés az, hogy megállapítható-e pontosan a támadás időpontja... (meg hogy ez volt-e az egyetlen sikeres, a legutóbbi ismert kernel.org incidens óta ;)

Akkor most mégis oda lyukadunk ki, hogy a szerver megtörése nem elég?

"Mivel a kernel.org-on localban is történik ilyen commit, ezért akár azon is kivitelezhető ez"

"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

Hasonló már a bitkeeper szinkronizációs protokolljában is volt, azért bukott ki anno davem nevében commitolt backdoor.

Amit aztán az a fejlesztő, akinek a kernel.org-os repository-ját így módosították, az első hozzáféréskor egyből észrevesz, és telekürtüli a világot, hogy gebasz van.

vagy nem veszi észre, mert sokszor triviális bugokat se vesznek észre, nemhogy egy jól kiagyalt kiskaput...

Nem a jól kiagyalt kiskaput veszi észre, hanem azt, hogy valaki módosította az ő k.org-os repository-ját.

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?

Azt hittem, hogy arról beszélünk, hogy egy kernel.org-os repository-ba be lehet-e csempészni backdoor-t illetéktelen hozzáféréssel.

az is beleértendő, mint írtam nem egyirányú commitok vannak

Nem látom, hogy ez hogyan tenné lehetővé, hogy az illetéktelen repository módosítás észrevétlen maradhasson.

én meg azt nem látom, hogy mi akadályozná meg... látod, különbözőek vagyunk :)

pl. git push panaszkodik nem fast-forwardolható változtatások miatt, meg ilyesmik.

Látom nem nagyon megy az out-of-box gondolkodásmód... :)

Az meg van, hogy 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?

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.

"Nem mondtam, hogy könnyű kivitelezni egy ilyen backdoor bejuttatását."

Nekem ebből az jön le, hogy a Linux kernel forrása meglehetősen jól védett. Talán az átlagnál is jobban. Tévednék?

--
trey @ gépház

"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

Mivel nem vagyok képben ezzel kapcsolatban (tényleg), azért kérdezem: mennyire gyakori az, hogy minden egyes commit-ot alárírnak digitálisan? Illetve azt, hogy ki és mikor jelentette ki, hogy bármelyik gép - beleértve mondjuk Hunger-ét is - törhetetlen?

--
trey @ gépház

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#Features

(É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

> 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"...

Tegyük fel, hogy a kérdés arra vonatkozott, hogy mi az elterjedt gyakorlat?

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

A git tageket PGP-vel aláírják, de minden egyes commit-ot nyilván nem.

"nyilvan nem"? azert az nem olyan nyilvanvalo, szerintem. meddig is tartana automatizalni, es beepiteni a rendszerbe?

A "git commit" nem támogat digitális aláírást. Persze, bele lehet tenni, de jelenleg nem ez a helyzet.

Akkor plane itt az ido. Keves erv van git mellett, de a digitalis alairas az egyik legnagyobb plusz pont.

---
pontscho / fresh!mindworkz

Nincs nagy jelentősége abból a szempontból, hogy ha a fejlesztő gépét törik meg, akkor a támadók is ugyanúgy aláírhatják digitálisan (vagy a fejlesztő saját maga fogja a már módosított kódot aláírni ;)

Ez igaz, viszont sok masik ponton bezar jo par kiskaput es mar ez is sokat szamithat mar csak azzal, h eleve mas celpontot kell masmilyen modszerrel tamadni es nem egy script kiddie gyalogol vegig A Renceren. :)

---
pontscho / fresh!mindworkz

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... ;)

Ha a standard paranoid modell alapjan valoszinusitesz, akkor ismerven a trendeket en az utobbira fogadnek...

---
pontscho / fresh!mindworkz

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

Szerintem nyugodtan indulj ki abbol, hogy Mr. Manyeye nem all neki random commitokat olvasgatni, es ha valaki nagyon akar backdoorokat betolni a kernelbe, akkor szimplan jelentkezett kernel devnek.

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

szerintem azert nem ennyire tragikus a helyzet.

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

Kb. elmondtad ugyanazt, mint én, csak 3x olyan hosszan :)

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

Szerintem igen. A Linux forráskódját bárhonnan letöltheted, a Windowsét meg nem. :)
--
zsebHUP-ot használok!

Lehet, hogy csak álmodtam, de mintha lett volna olyan, hogy boldog-boldogtalan leechelte a netről a Windows forrásának egy részét? :)

--
trey @ gépház

Azt hittem, hogy arról beszélünk, hogy egy kernel.org-os repository-ba be lehet-e csempészni backdoor-t illetéktelen hozzáféréssel észrevétlenül.

éljen. ekkora igény ez, hogy a verziókezelőt manipulálhasd?

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.

Eddig csak joindulattal raktak bele lukakat... :)

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.

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

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.

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

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.

mert Linus mint tudjuk minden commitot alaposan átolvas, megrág, megemészt, mielőtt beemelné a saját fájába... (ráadásul git óta már nincs ilyen, hogy Linus gépe, mint master repo ;)

Linus git repoja egyenlőbb az egyenlők között. (Az ő repojából van a release.)

Sztem nem ömleszti be saját magának patcheket, keményen cherrypickel.

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

Igen, megnézi ki commitolta, ha haver, mehet, ha nem haver, nem...

Ez max urban legend. Valóság alap = 0.

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

Colivas fele scheduler is azert nem kerult bele nyilvan, mert urban legend, es Ingo azert irta ujra az alapjan.. oh wait. hisz ez is csak urban legend!

úgylátom neked is a bugos kérdést kellene feltenni...

Hát én már láttam backdoort. (Sőt nem vagyok büszke rá, de már én is írtam.) Jól meg lehet különböztetni a bugoktól.

Ha diffel nézel egy forrást akkor nagyon jól látszanak. Általában!

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

Ahahhahaha :)

OMG ROTFL

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.

Tessék, itt a tavaly már elsütött feladványom:

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/rnd.c.diff?r1=1.35;r2=1.36

Az fentebbi commitban egy bug/kiskapu van elrejtve. Mutass rá melyik az és miért, válaszodat indokold! ;)

Nyertel egy [fuckin' genius] plecsnit. Hasznald egeszseggel.

--
"You're NOT paranoid, we really are out to get you!"

Te meg egy [fuckin' useless comment] plecsnit. És ezt inkább ne használd...

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

winmerge már nem is mutatja? :(


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

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

Linus repója > kernel.org repo. Sőt Linus repo > all repo, ahol repo = Linux kernel repo.

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

Az a legrosszabb, hogy ez komolyan gondolja amit ír :)

Sokat fog bővülni a hupmeme az elmúlt 2 nap eseményeiből, az biztos ;p

Miért mi a gond vele? Már ott van fent Linus repója a githubon. Már lehet túrni a ha akarod...

(Nem értelek titeket tinédzsereket...)

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

szerintem Linus nem nagyon ért rá tegnap, mert valami búvár-merülőnaplós szoftvert írt :) :

https://plus.google.com/102150693225130002912/posts

:))

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

Baszki de kár!

Bunkómannek meg Gyökérnek meg lenne ezekről a cégekről a véleménye...

jah, becsöngetnének és nyomnának egy taslást..

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