Jelenleg a Linux kernel biztonsága 5 évvel a Windows mögött van

Nem én mondom ezt, hanem az IT Security egyik elismert szakértője, az Immunity Inc. vezetője, Dave Aitel.

Levele itt, az eredeti szál innen indult.

( Chain-Q v | 2009. 08. 09., v – 00:39 )

Ezzel csak az a baj, hogy a vilag min. 80%-a egy 10 eves Windows kernelt hasznal. :) Szoval a current Linux kernelnek meg mindig van 5 ev elonye a vilag 80%-val szemben! :D

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

( Huncraft v | 2009. 08. 09., v – 01:02 )

És az a baj, hogy igaza is van... Egyedül azért van kevesebb biztonsági incidens a linuxos gépeken, mert kis piacot nem érdemes támadni.. Plusz azt is rá kell számolni, hogy - tetszik, nem tetszik - az MS tanul a linuxos dolgokból..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Manapság a legjobb üzlet az internetes BOT hálózatok szerintem :)) Ezek után merd azt mondani, hogy ott nem számít melyik a kis, és a nagy piac :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Merem azt mondani, hogy ha tudom, hogy egy programot 10x annyian használnak, mint egy másikat, akkor abban a programban fogok olyan hibát keresni ( még ha nehezebb is ), amelyet fel tudok használni arra amire nekem épp szükségem van ( jelen esetben BOTnet ), nem pedig a másikra, ahol kevesebben is vannak.. ( félreértés elkerülése végett: Nem csinálok semmi hasonlót :))
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Jaja.. sokkal jobban lehet spamet kuldeni 1000000 db XP-s geprol, amik 2M/512-es ADSL-el ucsorognek napi par orat, mint 1000 db Linux serverrol, ami 24/7 2x1Gbites halon van..
(Raadasul a rajtuk levo adatok is joval kevesbe erdekesek, mert ugye a Linuxos gepeken koztudottan csak GPL-es programok forraskodja szokott lenni, uzleti titkok nemigazan.)

--
Vorbis megváltoztatta az embereket. Néha halott emberekké változtatta őket. De mindig megváltoztatta őket. Ez volt az ő diadala. - Pratchett

attól függ, melyik piacról beszélünk. Lehet velem vitatkozni, de szerintem marha jó üzlet lehet szervereket kompromittálni – ahol meg már nem olyan kicsi a hátránya a Linuxnak, már ahol előnye nincs történetesen.

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Azért ezt ne egyszerűsítsük le ennyire.. Az alap linux kernelről beszéltünk.. Cégeknél hol láttál komolyabb linuxos alap kernellel? (az nálam már nem komoly cég ). Minimum egy kernel-biztonság fokozónak lennie kell, ha be akarod magad védeni, és nem akarod, hogy az első jött-ment script kiddie szétcincálja a céged netről elérhető szerverét..
Innentől fogva viszont pont hogy jelzés értékű az egész a cégek számára is, hogy az alap linux kernel security szempontból elég gyenge.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nekem egeszen veletlenul van kinn a neten egy 'kernelbiztonsag-fokozo' nelkuli gepem, es meg nem cincaltak szet. A kernel biztonsaga onmagaban kevesse ertekelheto, egy gep, rendszer biztonsagarol mar tobb ertelme van beszelni. Btw. mi a problema pl. a legutolso stable kernel biztonsagaval?

SPAMtelenul - POP3 spamszuro szolgaltatas

Hogy az éppen mostani 2.6.30.4-es stable-el mi van azt maximum az mondja meg neked, aki az ilyenek felderítésével foglalkozik.. Azonban látom, hogy folyamatosan javítják a hibákat a kernelben, és elég nagy összeggel mernék rá fogadni, hogy a mostaniban is van nem 1 problémás rész. Ami az eddigi 1-2 verziót illeti a jelenlegi 2.6.30-ból: 1, 2
Szerk: A rendszer védelméhez hozzá tartozik a kernel védelme is szerintem.. Sajna nem 1 lehetőség van pont a kernel kódban lévő hiba miatt privilégium emelésre..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( Yorirou | 2009. 08. 09., v – 01:10 )

"I absolutely despise most security people, because they are idiots who do not understand development."
Ez mindent elmond.

( zamboriz v | 2009. 08. 09., v – 01:26 )

> Nem én mondom ezt, hanem

Kár, neked elhittem volna.

( Hiena v | 2009. 08. 09., v – 11:28 )

Ezt hívják "milking the dead cow"-nak.
Könnyű okosnak lenni egy olyan fejlesztési modellnél ahol nincs dedikált security testing és Linus egyetlen érintéssel képes 35 patcht beolvasztani a kernel fába, viszont van helyette egy elég gyors ütemű fejlesztési menet ami miatt aztán, be-be csúsznak hibák.
A security üzlet egy olyan piac, ahol nagyon kemény a verseny, és egy jól definiált pozícióval évekig lehet fejni a különféle cégeket. Az IT biztonsággal foglalkozó oldalakat olvasva egyértelműen látszik, hogy a legtöbb szakember egy-egy 15 percnyi hírnévből próbál profitálni. Az ilyen közösségben, egy új piac találása és abban stabil pozíció szerzése aranybánya, a "Linux Security Specialist" cím pedig jól hangzik. Mivel egyre nagyobb a linux térnyerése, ezért ha másképp nem is de social engineering szinten megmozdult a biztonságtechnikai piac.
Linus válasza elég jól összefoglalta ezt.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Bocsi, de van par nulla kulonbseg "a ceg vagyunk es ezer mas elfoglaltsag mellett 20-asaval keressuk es javitjuk a kernelbugokat", es a "security cegnek hivnak minket mert 10 evvel ezelott talaltunk egy hibat, agyonhypeoltuk es azota irgalmatlan nagy penzeket akasztunk le a tanacsadasert" uzletmenet kozott. Amit fenn leirtam az a nagyjabol 20% a 80%-os megoszlasu a piacon, es igy is lesz mindaddig amig a IT security es a hacker kifejezesre a hideg remeges fut at a cegek managereinek a hatan, es amig ugyanezen kifejezesek merevedest okoznak par szerencsetlennek.

Igen, aranybanya, mert eddig meg senki nem aknazta ki, meg senki nem fujt lufit kore. Nagy kulonbseg, amikor bejelentik, hogy talaltak egy local root lyukat amit max. akkor tudnak kihasznalni ha egy ugynok bejut a ceghez, majd megtamadja a netrol levalasztott halozatot, vagy ha ezt ugy jelentik be, hogy "uristen vilagvege, mind meghalunk". Ez esetben a security ceg szent lovagkent lephet fel, amikor finom tanacsadoi dijert kellemes bariton hangon odasugja, hogy nem is vagy szarban...

Ami felettebb csipheti a biztonsagtechnikai cegeknek a szemet az a linux kernel fejlodesenek az uteme. Amennyiben a kernel fejlesztok mellett letre tudnanak hozni egy "security advisory boardot" es csak un. secure keneleket engednenek ki, ezzel hatasosan lassithanak a javitasok kiadasanak a menetet. Jelen pillanatban egy security bugra egy-ket heten belul kinn van a patch, emiatt a linux security business eleg doglott, mert egy epeszu rendszergazda kepes biztonsagossa tenni a rendszeret. Ha ezt a fejlesztesi utemet hat-nyolc hetre lehetne novelni, maris zsiros szerzodesek hullananak a parazo IT cegektol.

A masik dolog, hogy a releasek magas szama es gyors uteme miatt nehez jelen pillanatban megfelelo toolokat kihozni a toresekhez. Amikor betamadnak egy szervert elbol kell vagni, hogy az adott kernel/alkalmazas verzional milyen hibak vannak arrol nem beszelve, hogy nincs piros betukkel kiirva, hogy mit hackkelt/patchelt a rendszergizda. A szubverziok szamanak lecsokkentesevel (kozpontilag authentikalt "secure" kernel), lecsokkennnek az alverziok, emiatt egy-egy bug hosszabb ideig marad a rendszerben, arrol nem beszelve, hogy a rendszergizda meg bekesen fogja hinni, hogy biztonsagban van a rendszer. Ka'thcing, maris lehet sorokba rendezni a script-kiddieket a fizeteshez.

Mi, hogy ugyanezen dolog megy windows vonalon? Egen, nincs uj a nap alatt...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Amit fenn leirtam az a nagyjabol 20% a 80%-os megoszlasu a piacon

és az Immunity szerinted melyikbe tartozik?

Igen, aranybanya, mert eddig meg senki nem aknazta ki, meg senki nem fujt lufit kore.

Eddig még senki sem foglalkozott IT Securityvel, csak most kezdték el nézegetni, hogy mi is ez a dolog?

Nagy kulonbseg, amikor bejelentik, hogy talaltak egy local root lyukat amit max. akkor tudnak kihasznalni ha egy ugynok bejut a ceghez, majd megtamadja a netrol levalasztott halozatot

Sok ilyen céget ismersz, ahol airgap van az internet és a belső hálózat között?

Ami felettebb csipheti a biztonsagtechnikai cegeknek a szemet az a linux kernel fejlodesenek az uteme

Mert a gyorsabb fejlődés, több új kódot jelent, ami még több bugot? Ez tényleg nagyon csípheti a szemüket, hogy egyre több a bug.

Amennyiben a kernel fejlesztok mellett letre tudnanak hozni egy "security advisory boardot" es csak un. secure keneleket engednenek ki, ezzel hatasosan lassithanak a javitasok kiadasanak a menetet.

Miért is? Hol az összefüggés?

Jelen pillanatban egy security bugra egy-ket heten belul kinn van a patch, emiatt a linux security business eleg doglott

Ezek a biztonsági cégek nem (csak) halott bugokkal foglalkoznak ám, hallottál már a zero-day kifejezésről? Vagy ez is valami olyan dolog, ami a Linuxot nem érinti?

A masik dolog, hogy a releasek magas szama es gyors uteme miatt nehez jelen pillanatban megfelelo toolokat kihozni a toresekhez

Szerinted ezek a cégek külön exploit.c kódokat irogatnak?

Amikor betamadnak egy szervert elbol kell vagni, hogy az adott kernel/alkalmazas verzional milyen hibak vannak

És nem tudják? Olyan 0day hibájuk meg nem is lehet, amelyik az összes jelenleg használt verziót érinti?

nincs piros betukkel kiirva, hogy mit hackkelt/patchelt a rendszergizda

Gyakori, hogy a rendszergazdák 0day hibákat javítgatnak?

"Eddig még senki sem foglalkozott IT Securityvel, csak most kezdték el nézegetni, hogy mi is ez a dolog?"
Nem. Ugy ertettem, hogy ez egy kiaknazatlan terulet.

"Sok ilyen céget ismersz, ahol airgap van az internet és a belső hálózat között?"
Rengeteget. Majdnem minden olyan komoly ceg ahol kenyes adatokat kezelnek a belso halo masszivan le van valasztva. Szamos olyan ceg van amelyik kulonallo berelt vonali halozatot tart fenn csak azert, hogy a 4-5 telephelye ossze legyen kotve.

"Mert a gyorsabb fejlődés, több új kódot jelent, ami még több bugot? Ez tényleg nagyon csípheti a szemüket, hogy egyre több a bug."
Meg a letezo bugok gyors javitasat it. Egy biztonsagtechnikai alkalmazott nem ugy fogja a hibat, hogy megnyitja a forrast, megrazza es mar potyognak is ki. Egy hiba erteke nagymertekben fugg, hogy mennyire friss es mennyire gyorsan javitjak. pl. Egy Windows sokkal jobb terep ilyen tekintetben mert egyseges kornyezet, viszonylag lassu frissitessel.

"Miért is? Hol az összefüggés?"
A patchnek is at kell mennie a security teszteken. Plusz, csak a boardon mulik mikor kerul az adott hiba javitasa publikalasra hivatalosan. Mivel a linux kernel non-profit kezelesu, valamibol a board membereknek is meg kell elnie.

"Ezek a biztonsági cégek nem (csak) halott bugokkal foglalkoznak ám, hallottál már a zero-day kifejezésről? Vagy ez is valami olyan dolog, ami a Linuxot nem érinti?"
Valoban. Es szerinted mit csinalnak ezek a cegek a 0day bugokkal? Eladjak. Van akinek a hibat, van akinek a patchet.
Hogy is fugg a patchnek az erteke? Hogy milyen sulyos a hiba, es van-e hozza javitas. Mi, hogy ketnaponta valtozik a kod? Mi, ertektelenne valik a kodod seperc alatt?

"Szerinted ezek a cégek külön exploit.c kódokat irogatnak?"
Kerlek felejtsd mar el ezt a kalapszines baromsagot. Az IT securityben penz van, piszkosul nagy penz van. Szerinted egy programozo ha meglebbentenek elotte 8-9 havi fizeteset, majd gerincesen kihuzza magat es azt mondja:"Nem, en nem adom el az 0d exploitomat, mert en egy feherkalapos hos vagyok, inkabb ingyen publikalom!" Egy osmagyarokterepfutokepesseggelrendelkezonegylabuhatasallatahimegyedenekszaporitoszervet.
Ha mar felhoztad az Immunity-t. Szerinted ok mit is gyartanak? Penetrating testing, exploit test module mind szep kifejezes az exploit.c-re. Ahogy egy pisztolyt hasznalhat egy katona es egy bankrablo is, egy ilyen eszkozt is hasznalhat egy jo es egy rosszfiu is.

"És nem tudják? Olyan 0day hibájuk meg nem is lehet, amelyik az összes jelenleg használt verziót érinti?"
Igen. Csak ez epp az adott rendszer diverzitast noveli, es csokkenti a platform vonzerejet a tamadasokhoz. Minnel nagyobb tudast es felkeszultseget igenyel egy rendszer torese, annal kisebb az esely, hogy wannabe crackerek es scriptkiddiek probalkozzanak be.

"Gyakori, hogy a rendszergazdák 0day hibákat javítgatnak?"
Igen. Sok esetben ontudatlanul is megteszik egy rendszer/kenelfrissiteskor.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Rengeteget. Majdnem minden olyan komoly ceg ahol kenyes adatokat kezelnek a belso halo masszivan le van valasztva.

És a levelezést hogy oldják meg?
A böngészést?

Szamos olyan ceg van amelyik kulonallo berelt vonali halozatot tart fenn csak azert, hogy a 4-5 telephelye ossze legyen kotve.

Ez nem újdonság, rengeteg ilyen helyre dolgozok be, de ettől még a telephelyek valamilyen szinten kapcsolatba kerülnek az internettel attól még, hogy a központtal dedikált kapcsolatuk van. Vagy telephelyenként külön internet eléréssel vagy a béreltvonalon keresztül a központi internet-kapcsolaton át.

Meg a letezo bugok gyors javitasat it.

Ez nincs feltétlen összefüggésben. Lehet, hogy az állandó változások, kódújraírások miatt sok bug kikerül a forrásból vagy átírásra kerül (esetleg az adott hiba kihasználhatatlanná válik), de kevesebb nem lesz ettől még belőle. Arról már nem is beszélve, hogy rengeteg olyan része van a Linux kernelnek is, amelyhez évek óta nem nyúltak és hibákat tartalmaznak (lásd. PaXTeam által felfedezett hiba, amely 0.1 óta benne volt a kernelben).

Egy hiba erteke nagymertekben fugg, hogy mennyire friss es mennyire gyorsan javitjak.

Ne ilyen hibákban gondolkozz, publikus bugokat komolyabb helyeken fel se használnak. Egy 0day hiba meg pont annál értékesebb, minél több rendszert érint. Azaz pont, hogy inkább minél régebbi, annál jobb. A 20 éves NetBSD/OpenBSD copyin* kernel bugokat szerinted nem tudták egyesek a javítása előtt már egy évtizeddel? Dehogynem, aktívan ki is használták.

Egy Windows sokkal jobb terep ilyen tekintetben mert egyseges kornyezet, viszonylag lassu frissitessel.

A Windows jó terep mass-ownage tekintetében és ott pont azért kell friss hiba mindig, mert ezek a hibák a kihasználásuk miatt egyszer használatosak. Egy széleskörű támadás után 100%, hogy valamelyik ITSec cégnek fennakad a honeypotján a 0day exploit és már megy is az értesítő az érintett vendorhoz.

A patchnek is at kell mennie a security teszteken.

A patchnek mindenhol át kell mennie valamilyen QA-n, különben vaktában lövöldözés lesz az egészből csupán, amire nem lehet alapozni. Ha Linuxnál teljesen security tesztek nélkül mennének ki a patchek, akkor arra nem nagyon kellene büszkének lenni. :)

Plusz, csak a boardon mulik mikor kerul az adott hiba javitasa publikalasra hivatalosan

Itt szerintem összemosol dolgokat. A javítás publikálása több mindentől függ. Egyrészről attól, hogy maga a hiba publikus-e vagy sem, másrészről attól, hogy mennyire kritikus. Egyébként e tekintetben nincs különbség, a nem publikus hibáknak a javítását ugyanúgy halogatják Linux (és más szabad szoftveres) berkekben is. Lásd az 1 év után javított Firefox hibákat és néhány mai napig sem javított bugot. De Linuxnál is tudok pár ilyenről, amin már régóta ülnek.

Valoban. Es szerinted mit csinalnak ezek a cegek a 0day bugokkal? Eladjak. Van akinek a hibat, van akinek a patchet.

Vannak cégek, akik csak a hibát, ezért nincs pl. semmiképp se egyensúlyban az a képzeletbeli mérleg...

Ráadásul a patch helyett jópár cég HIPS/NIPS eszközöket ad inkább és azokra frissítéseket, amikkel megpróbálják elcsípni az általuk ismert 0day hibák kihasználását kisebb-nagyobb (de többnyire kisebb ;) sikerrel.

Mi, hogy ketnaponta valtozik a kod? Mi, ertektelenne valik a kodod seperc alatt?

Szép álom, kár, hogy a világ nem így működik. Attól, mert a Linux mainline bizonyos szempontból gyorsan változik, meg néhány FLOSS alkalmazásé is, attól még a komolyabb rendszerekben nem frissítgetnek kétnaponta mindig a legújabb verzióra... És máris nem változik annyira az a kód. Hányas kernelre is épül az a RHEL4? 2.6.9? Az RHEL5 is csak 2.6.18. Mennyit változtak az évek alatt? Csak amennyit feltétlenül kellett, ergo a publikussá vált hibákat javították. Tehát mégse változik annyira az a kód...

Kerlek felejtsd mar el ezt a kalapszines baromsagot.

Nem írtam semmiféle kalapszínről.

Szerinted egy programozo ha meglebbentenek elotte 8-9 havi fizeteset, majd gerincesen kihuzza magat es azt mondja:"Nem, en nem adom el az 0d exploitomat, mert en egy feherkalapos hos vagyok, inkabb ingyen publikalom!"

Igen vannak ilyenek. Még mindig. Az viszont igaz, hogy régebben több volt.

Ha mar felhoztad az Immunity-t. Szerinted ok mit is gyartanak? Penetrating testing, exploit test module mind szep kifejezes az exploit.c-re.

Ők többekközt egy komplett keretrendszert adnak behatolásra, amely nem csak a hiba kihasználását teszi automatizálhatóvá, hanem sok minden mást is. Ezért is írtam, hogy nem exploit.c-ket irogatnak, annál már jóval előrébb tartanak.

Igen. Sok esetben ontudatlanul is megteszik egy rendszer/kenelfrissiteskor.

Az előbb még azt írtad, hogy maguktól patchelnek/hekkelnek bele javítást.

"És a levelezést hogy oldják meg?A böngészést?"
Rengeteg olyan munkakor letezik, ami nem igenyel bongeszest vagy a belso halozaton kivuli levelezeset. Pl. egy banki ugyintezonek nem kell youtubeot nezni munkakozben. Sot a legelborzasztobb, hogy vannak olyan galad helyek ahol kulon azert fizetnek embereket, hogy kezzel(!) emeljek at adatokat/leveleket a ket halozati szegmens kozott. Sot, van ahol a kintrol jott emaileket a T. Dolgozo iktatva, nyomtatva kapja meg! Szar dolog lehet egy kockanak ilyen helyen dolgozni...

"Arról már nem is beszélve, hogy rengeteg olyan része van a Linux kernelnek is, amelyhez évek óta nem nyúltak és hibákat tartalmaznak (lásd. PaXTeam által felfedezett hiba, amely 0.1 óta benne volt a kernelben)."
Bug es bug kozott is van kulonbseg. Egy csak tisztan helyi kihasznalhatosagu hiba ami nem triggerelheto tavolrol eleg ertektelen. Fugg a bug felfedezhetosegetol is. Egy tulcsordulas vagy cimzesi hibat sokkal egyszerubb kiszurni es kitriggerelni, mint egy olyant ami csak a pi 324535-ik tizedesenek teliholdkor torteno, google pingeles kozbeni szamoltatasanal jon elo.
Letezik a "security through the obscurity", ebbe siman belefer az, hogy a valtozatlan/nem erdekes reszek nincsenek a biztonsagi szemszogbol a fokuszban, ezert joval kisebb esellyel fedeznek fel benne hibat es alapoznak explitot erre a hibara.

"Hányas kernelre is épül az a RHEL4? 2.6.9? Az RHEL5 is csak 2.6.18. Mennyit változtak az évek alatt? Csak amennyit feltétlenül kellett, ergo a publikussá vált hibákat javították. Tehát mégse változik annyira az a kód..."
Bocsi, de egy vanilla rendszert eles kornyezetben uzemeltetni kb. olyan felelotlenseg mint ahogy en szolgaltatast uzemeltetek egy honeypot-on.

"Ezért is írtam, hogy nem exploit.c-ket irogatnak, annál már jóval előrébb tartanak."
Az, hogy egy keretrendszert keszitenek, csak annyi tobblet az exploit.c-hez kepest, hogy tobb szolgaltatast nyujtanak. Ettol meg ugyanugy felhasznalhato az eszkozuk barmilyen celra. Fegyveres hasonlattal elve, ergonomikusra faragjak a pisztoly markolatat.

"Az előbb még azt írtad, hogy maguktól patchelnek/hekkelnek bele javítást."
Nagyon sok rendszergazda maganak forgat kernelt es vannak hulye heppjeik. Ilyen hepp lehet a kernel "kikonnyitese", sajat loader vagy modul beforgatasa. Ezek nagyon sokszor nem egy hiba patchelésének a céljával kerülnek bele, mégis sokszor emiatt válik pont biztonságossá a kernel.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Rengeteg olyan munkakor letezik, ami nem igenyel bongeszest vagy a belso halozaton kivuli levelezeset. Pl. egy banki ugyintezonek nem kell youtubeot nezni munkakozben.

És ahol banki ügyintézők dolgoznak ott akkor már minden dolgozó banki ügyintéző? ;)

vannak olyan galad helyek, ahol kulon azert fizetnek embereket, hogy kezzel(!) emeljek at adatokat/leveleket

Most már azt írod, hogy vannak ilyen galád helyek, eddig azt írtad, hogy rengeteg ilyen hely van, sőt minden komolyabb cégnél így csinálják.

Egy csak tisztan helyi kihasznalhatosagu hiba ami nem triggerelheto tavolrol eleg ertektelen.

Maximum neked. :))

Ilyen semmirekellő senkiházi ITSec cég, mint akiről szó is van azért megadnak érte jópárezer dollárt... Nyilván azért, mert értéktelen. :P

Letezik a "security through the obscurity", ebbe siman belefer az, hogy a valtozatlan/nem erdekes reszek nincsenek a biztonsagi szemszogbol a fokuszban, ezert joval kisebb esellyel fedeznek fel benne hibat es alapoznak explitot erre a hibara.

Huh? Ez pont fordítottan arányos... Amire kevésbé fordítanak figyelmet és mégis sokan használják, abban érdemesebb hibát keresni, mert valószínűbb, hogy sokáig megmarad majd a tarsolyban.

Felkapott területekkel max. azok foglalkoznak, akik a hírnévre utaznak.

Bocsi, de egy vanilla rendszert eles kornyezetben uzemeltetni kb. olyan felelotlenseg mint ahogy en szolgaltatast uzemeltetek egy honeypot-on.

Akkor miről beszélünk? Te eddig azt hangsúlyoztad, hogy olyan gyorsan fejlődik a kernel, hogy "kétnaponta változik a kód" és "értéktelenné válik seperc alatt" a felfedezett 0day. Most akkor hogy is van ez?

Az, hogy egy keretrendszert keszitenek, csak annyi tobblet az exploit.c-hez kepest, hogy tobb szolgaltatast nyujtanak. Ettol meg ugyanugy felhasznalhato az eszkozuk barmilyen celra.

Én nem is erről beszéltem, hanem arról, hogy kész megoldásaik vannak bizonyos problémák kiküszöbölésére, amikre te hivatkoztál, mint "nehéz jelen pillanatban megfelelő toolokat kihozni a törésekhez". Teljesen más irányba terelted el a dolgot.

Nagyon sok rendszergazda maganak forgat kernelt es vannak hulye heppjeik. Ilyen hepp lehet a kernel "kikonnyitese", sajat loader vagy modul beforgatasa.

Kispista Bt. esetén előfordulhat, de egy nagyobb cégnél lehet jól seggbe rúgják ilyen magánakcióért.

Arról már nem is beszélve, hogy egy "saját loader vagy modul beforgatása" nem fogja kijavítani a do_mremap()-ban lévő hibát...

"Akkor miről beszélünk? Te eddig azt hangsúlyoztad, hogy olyan gyorsan fejlődik a kernel, hogy "kétnaponta változik a kód" és "értéktelenné válik seperc alatt" a felfedezett 0day. Most akkor hogy is van ez?"

Az altalad felsorolt rendszerekben a kernel frissitese nagysagrenddel lassabbb, mint a mainline kernel fejlesztesi uteme. A disztribucio!=a kernellel.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( pomm v | 2009. 08. 09., v – 15:58 )

Ezek a felmérések nagyrésze fizetett m$ reklám.
Lefordítom. (maradok a gyűlölt autós példánál)
A mi motorunk fele annyi üzemanyaggal megy el mint a tiétek. Tegyük fel, hogy igaz. Csak önmagában kevesen ülnek fel a csupasz motorra. Ja, ehhez a motorhoz csak vacak nyomaték, nehéz kaszni, ócska futómű van. Amire összerakod, kapsz egy háromszor akkor fogyasztásút, mint amivel összehasonlítottam. Ettől még nem hazudtam, csak rohadtul ferdítettem...Na kb, így van ez a fentivel is, leszámítva, hogy a windows kernel és a linux kernel tök más (tehát mintha belsőégésű motort hasonlítanék elektromotorral), zárt forrású, magyarul ők azt hazudnak amit akarnak, nem igazán bizonyítható, akár csak a patch-özön, ami egy win updattel lecsorog...De ezt szerintem itt mindenki tudja.
Szóval nem a win kernellel van a bajom, csak ezek a kijelentések körülbelül az omo vs ariel szinten vannak. Intelligensen mossák - jelenesetben - az átlag júzer agyát.
üdv: pomm

Ezek a felmérések nagyrésze fizetett m$ reklám

Valamit félrenézhettél. Ez nem felmérés, hanem egy vélemény, egy email egy levelezőlistán, egy olyan szakértőtől, aki az IT Security iparban dolgozik nagyon sok éve.

zárt forrású, magyarul ők azt hazudnak amit akarnak, nem igazán bizonyítható, akár csak a patch-özön, ami egy win updattel lecsorog

Attól, mert neked meghaladja a képességeidet, még nem jelenti azt, hogy másnak is.

A hangsúly a fizetetten volt! :)
Ja, nem tudtam, hogy kiadták a forráskódot, sőt az értelmi szintem lehet, hogy meghaladja - ó nagy guru :) - de az sp-k tartalma máig nem teljesen publikus. Így aztán könnyű.
Maradjunk az egyszerű példáknál (a képességeim miatt :) )
Kártyázzunk, én láthatom a lapod, te nem az enyém - izgalmas lesz...
üdv: pomm

Szerintem is tök nagy hülyeség, de tény...
A microsoft-ot nem véletlen rövidítik m$-nek. (Bár ez a legtöbb nagy vállalatra is igaz.)
Persze lehet játszani fejed, de az elmúlt évek alatt a fizetett microsoft tesztekkel és nem "hivatalosan" fizetett tesztekkel van tele a zindex, meg a hasonló "szakmai" portálok. Erre te is bevágod ide ezt a flame keltő ostobaságot.
Mielőtt azzal jönnél, hogy mennyivel képzettebbek nálam az adott témában, akik a fenti cikket/e-mailt/blogot/tesztet csinálták, hidd el, hogy tudom. Nem a szakmai hozzáértésüket vitatom, hanem azt amit ettől függetlenül állítanak, illetve a pénztől való függetlenségüket.
Egyáltalán az értelmét az egésznek. Mert a gyakorlat tök mást mutat...
üdv: pomm

Nem kell mesélni! Hány linuxos gépet törnek meg és hány winest? Pont. Ahogy fentebb írták, ha lehetne biztos nem adsl-es spamgépek lennének előnyben...Nem beszélve arról, hogy a mekkora egyéb károkat lehetne okozni, ha olyan rohadt könnyű lenne törni a linux kernelt. A wines meg patchekkel együtt sem egy életbiztosítás.
üdv: pomm

Hány linuxos gépet törnek meg és hány winest?

Azzal arányban, hogy melyik mekkora elterjedtséggel bír? :)

Ahogy fentebb írták, ha lehetne biztos nem adsl-es spamgépek lennének előnyben...

Hanem?

Nem beszélve arról, hogy a mekkora egyéb károkat lehetne okozni, ha olyan rohadt könnyű lenne törni a linux kernelt.

Mekkorákat?

A wines meg patchekkel együtt sem egy életbiztosítás

Ez a szakértői véleményed vagy a tapasztalatod akkor most? ;)

Azzal arányban - nem feltétlen desktopról beszélünk, ugye?!
Azért kicsit nagyobb sávszéllel rendelkeznek a szerverek, csak ott kevés a windows...
Hát nagyobbakat, mint pistike gépére telepített jelszólopó tc-vel... :)
Nem szakértői véleményem és nem is tapasztalatom, inkább szakértők véleménye és tapasztalata
üdv: pomm

Bocs, elnéztem, most látom csak, hogy az internet gerincét adó gépeket, routereket, szervereket migrálták windows serverre... Ezer bocs, végülis biztosan igazad van, tekintve, hogy egy komoly security cég állítja amit bőszen védesz. :)
Mellesleg mivel is tudod alátámasztani, hogy ami fent áll igaz? Mert jött valaki, mondott valamit, winhuszároknak tetszik, tehát igaz?

üdv: pomm

Bocs, elnéztem, most látom csak, hogy az internet gerincét adó gépeket, routereket, szervereket migrálták windows serverre...

és az "internet gerincét" alkotó routerek teszik ki az internetre kötött gépek jórészét? :)

Mellesleg az is csak a te nedves álmodnak létezik, hogy ezeken a routereken Linux van, de irogass nyugodtan még ostobaságokat, én jól szórakozom... :))

Most azon gondolkodom, hogy én többször is pozitívan nyilatkoztam a Windows 7-ről, annak dacára, hogy Ubuntu van most fenn a laptopomon (sőt, "Ubuntero" vagyok). Az is köztudott, hogy MS Magyarország alkalmazottak / vezető pozícióban lévők is olvassák a HUP-ot.

Ha az elméleted igaz, akkor hamarosan kapni fogok egy mailt, amiben a bankszámlaszámom iránt érdeklődnek. Legyen így! :)

( gyrgyvrs | 2009. 08. 09., v – 18:26 )

Meg tudná valaki mondani, hogy a csávó hogy számolta ki ezt az 5 évet? Sehogy. Mondott valamit.

> Meg tudná valaki mondani, hogy a csávó hogy számolta ki ezt az 5 évet?

Ez egy olyan szakértő, aki az IT Security iparban dolgozik nagyon sok éve. Nagyon alaposan ismeri a problémakört, és nagyon alaposan ismeri a programozókat is. Csak véletlenül évet írt, emberév helyett.

:-)

Például úgy, hogy nézi mindkettő kernelnél, hogy hogyan történik a tervezés, a fejlesztés és a biztonsági auditálás és azt látja, hogy a Linux e téren jelenleg ott tart, ahol a Windows kernel fejlesztése 5 éve. Primitív statikus kódellenőrzésekkel és "majd csak szól valaki, ha hiba van benne" hozzáállással.

( wladek1 | 2009. 08. 09., v – 21:38 )

Teljesen nyilvánvaló; a tények magukért beszélnek.

"-Pedig vegetariánus vagyok; csak növényevő állatokat fogyasztok!"
azenoldalamponthu