Feltörték a GNU Savannah projektet

FSF/GNU/GPL

2010. november 23-án feltörték a Savannah adatbázisát. A saját fejlesztésű website motor hibája miatt "SQL injection segítségével kódolt felhasználói jelszavak szivárogtak ki, bizonyos jelszavakat brute-force-szal törtek fel, ez projekttagsági eléréshez vezetett" illetve "A Savane2 kódbázis SQL injekciós hibáinak javítására tett erőfeszítések a jelek szerint nem voltak megfelelőek" írja a jelenlegi információs lap. A javítást már elkezdték, egyelőre befejezési határidő nincs; a viccesnek szánt kommenteket megtekinthetjük a projekt főoldalán.

( Hunger | 2010. 12. 01., sze – 00:25 )

Mmm, ez a vihar előtti csend illata? ;)

Azért Ken Thompson véleményét kicsit megalapozottabbnak tartom RMS "négy láb jó két láb rossz nyílt kód biztonságos zárt kód nem biztonságos" dogmájánál.

És hiába a sírás a commentekben hogy "miért nem a MS-t törtétek fel szemetek!!!44", a feltöréshez vezető lyukas kód a FSF műve volt, és ezzel önmaguk meg is döntötték az egyik fő hittételüket.

RMS-től:
http://streamer.carnation.hu/mtvod/este/20090313/este_internet_090313.w…

7 perc körültől arról beszél, hogy OSX és MS Windows == backdoor, tele van biztonsági hibával illetve a MS trójaiakat telepít a gépekre; ezért használj nyílt kódot, ahol ez biztos nem történhet meg, védelmet nyújt a programozó által betett rosszindulatú kód ellen.

A sokkal kevésbé elszállt Ken Thompson pont ezt a hülyeséget cáfolja meg a fent linkelt cikkben.

Igen, vannak extrem esetek, amit Thompson demonstralt. Altalanossagban veve azert (amikor az ember eloadast tart, nem fog kiterni minden egyes elvadult esetre) igaza van RMS-nek: nyilt forraskodban egy trojai ill backdoor sokkalta kevesebb esellyel fordul elo.

Az ember szar szoftvert ir. Ez van, ez licensz es filozofia fuggetlen. Es hiaba van N szem, az is csak N ember, aki hibazik.

Mondjuk hangom nincs melohelyen, igy a videot nem tudom megnezni, de ketlem, hogy RMS azt mondta volna, legalabbis a biztonsagi hibakkal kapcsolatban, hogy nem tortenhet meg :P

Azért erre nem tenném le a nagyesküt.
Egy backdoor vagy trójai telepítése nélkül is jelenthet nagyobb kockázatot egy open-source kód, mivel a szabadon hozzáférhető kód miatt kevesebb időráfordítással található sérülékenység. Ugyebár a "many eyeballs" nem differálja, hogy milyen kalap is van az szemekhez tartozó fejen.
Open-source további problémája a project fragmentálódás. Minél több résztvevő küld be kódot és minél gyengébb a kód teszteltsége, annál nagyobb az esélye, hogy átcsúszik egy olyan hiba ami később kihasználható lesz.(Klasszikus példa erre a 2.6-os kernel wait-jébe implementált backdoor.) Egy kellően tehetséges rosszarcnak pár hónap elég, hogy egy open-source projectben lelkes contributorként kezeljék, mert hát, szép kódot ír és kijavított egy csomó hibát, ergó simán el lehet fogadni az általa commitelteket teszt nélkül is.

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

Valoban, ez is elofordulhat, de ez megint elegge extrem eset. Hirtelenjeben nem emlekszem, hogy tortent-e volna valaha is ilyen (ertve itt az utolso mondatodban foglaltakat).

Az is valo igaz, hogy a nyilt forraskod a csunya gonosz emberek munkajat is megkonnyiti: viszont pont azert, mert nyilt a forras, zaros hataridon belul meg lehet talalni hol jutottak be, ki lehet javitani, es nagyon hamar el tud keszulni a javitas. Ellenben zart forraskodnal a vendorra kell hagyatkoznod, mert nem tudod magad megpatchelni. Ha szerencsed van, akkor hamar javitja (altalaban azert nem szokott olyan hosszu lenni, bar volt olyanra is pelda, hogy kozoltek a vendor: igen, tudjuk, leszarjuk, majd valamikor kijavitjuk, addig igyjartal).

A magam reszerol en a biztonsagomat nem a szerencsere biznam.

Roviden: nyiltsagnak is vannak hatulutoi. Szerintem, es tapasztalatom szerint, az elonyei ezeket ellensulyozzak. Mint mondottam volt, tokeletes megoldas nincs, es nem is lesz soha, csak ha megtanul mindenki hibatlanul programozni.

Van valami statisztikád arról, hogy nagyvállalatok - beleértve a Google, Microsoft, IBM és a többi - szervereit milyen gyakran törik rommá? Csak azért kérdezem, mert lehet, hogy fals következtetést levonsz le annak fényében, hogy vannak, akik a teljes közlés utat választják egy-egy ilyen szerverfeltörés esetén és vannak akik a nem beszélünk róla utat.

--
trey @ gépház

Ennek mi köze van a commentemhez?

Az FSF dogmái közt ott van, hogy a nyílt kód mennyire biztonságos (és sokkal biztonságosabb a zártnál), mert a hibákat gyorsan észreveszik, és bárki kijavíthatja.
Látjuk, hogy mennyire igaz ez, nem is először. Csak ennyit mondtam.

szerk: a dolog 1 hete történt, azóta teljes leállás van. Google, MS, IBM, stb nem csinált ilyet soha.
Ez már nem a "közlés" kategória, arra elég lett volna egy blogbejegyzés meg hogy "javítottuk, és bocs"...

Igen. Volna. De N ember is csak N ember, aki ugyanugy hibazhat, mint barki mas.

Tokeletes megoldas nincs, csak jobb, meg rosszabb. Az, hogy egyatalan eselyed van megnezni, es megtalalni, sokkal jobb allapot, mint ha erre eselyed nincs.

Errol van szo, nem arrol, hogy free = hibatlan.

Innen:
"Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone."

Mégsem volt elég a nyílt forrás a megfelelő mennyiségű eyeball kitermeléséhez... Illetve ahhoz elég volt hogy valaki észrevegye, hogyan lehet SQL injectiont csinálni és ki is próbálta.

Ok, egy par dolgot megjegyeznek:

> Given a large enough beta-tester and co-developer base

Hany beta tesztere es devloperje van a savannah codebasenek? Tippre egy kezen megszamlalhato. Ez pedig nem felel meg a large enough base-nek az en ertelmezesem szerint.

> almost every problem

Almost. Majdnem. Fontos szo.

> and the fix will be obvious to someone

Ez igy is tortent: valaki megtalalta, kihasznalta. Valaki eszrevette, megkereste, es kijavitotta.

EZ az open source elonye: hogy ha proaktivan esetleg elsiklasz valami folott, ha beut a baj, meg tudod keresni, es ki tudod javitani.

David A. Wheeler: Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers

"An Air Force evaluation of Multics, and Ken Thompson’s Turing award lecture (“Reflections on Trusting Trust”), showed that compilers can be subverted to insert malicious Trojan horses into critical software, including themselves. If this “trusting trust” attack goes undetected, even complete analysis of a system’s source code will not find the malicious code that is running. Previously-known countermeasures have been grossly inadequate. If this attack cannot be countered, attackers can quietly subvert entire classes of computer systems, gaining complete control over financial, infrastructure, military, and/or business system infrastructures worldwide. This dissertation’s thesis is that the trusting trust attack can be detected and effectively countered using the “Diverse Double-Compiling” (DDC) technique, as demonstrated by (1) a formal proof that DDC can determine if source code and generated executable code correspond, (2) a demonstration of DDC with four compilers (a small C compiler, a small Lisp compiler, a small maliciously corrupted Lisp compiler, and a large industrial-strength C compiler, GCC), and (3) a description of approaches for applying DDC in various real-world scenarios. In the DDC technique, source code is compiled twice: once with a second (trusted) compiler (using the source code of the compiler’s parent), and then the compiler source code is compiled using the result of the first compilation. If the result is bit-for-bit identical with the untrusted executable, then the source code accurately represents the executable."

http://www.dwheeler.com/trusting-trust/

( uid_228 | 2010. 12. 01., sze – 09:13 )

Hogy is kommentált egy hasonló hírt valaki régebben? "Újabb manyeyeballs-sikertörténet"? :DD

--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.

( Hiena v | 2010. 12. 01., sze – 09:18 )

ROFL...
Ide vezetett a nagy Che Gueveraság...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( tiger | 2010. 12. 01., sze – 13:35 )

Én azon sírok, h komolyan fontolóra veszik, h MD5 hasht használjanak.
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

Erre mar megszuletett a valasz fentebb: mert a "many" jelen esetben egy eleg kicsi szam, masreszt meg az ember hibazik. Add ossze a kettot, es maris van egy exploitalhato lyukad.

A "manyeyeballs" nem azt jelenti hogy biztosan megetalalnak mindent (szep is lenne, nem lenne munkam), hanem azt, hogy van ra eselyuk.

Igy is meg lehet kozeliteni, valoban. De az ervelesemmel foleg arra probaltam volna - a magam suta modjan - utalni, hogy nyilt eseteben van eselyed kijavitani is.

Elobb-utobb valaki ugyis megtalalja a hibat, akar nyilt, akar zart. Ha nyilt, akkor nagyobb esellyel lehet megtalalni ezt, ami jo is, rossz is, viszont az, hogy ha megvan, gyorsan, rogton lehet javitani, az mindenkepp nagy elony.

De ezt nalam okosabbak sokkal jobban megfogalmaztak mar biztos :P

nyilt eseteben van eselyed kijavitani is

A zárt esetében is van esélyed... Ez egy téves nézet, amely főleg a nyílt forrást favorizálók körében terjed.

Tekints a zárt forrású szoftverek esetén előforduló másolásvédelmekre úgy, mint hibákra és a rájuk születő patchekre/crackekre, mint javításokra és máris rájössz, hogy mekkora butaságot írsz azzal kapcsolatban, hogy csak nyílt szoftver esetén van esély a hibák javítására.

Drága jó snq- bajtársam is erre próbált már több, mint 2 éve célozni, de hiába...

Elobb-utobb valaki ugyis megtalalja a hibat, akar nyilt, akar zart. Ha nyilt, akkor nagyobb esellyel lehet megtalalni ezt

Nem.

Ez az ami egy hatalmas dogma, vagy sztereotípia, vagy nevezhetjük bárminek... Erre próbált Csigaa is rávilágítani és a jelenlegi hír is jól mutatja, hogy nem ezen múlik.

viszont az, hogy ha megvan, gyorsan, rogton lehet javitani, az mindenkepp nagy elony

Ez sem feltétlenül igaz. Nem a javítás maga viszi el a sok időt, hanem egyrészről előtte annak kiderítése, hogy hogyan lehet vagy érdemes javítani magát a hibát, utána pedig annak alapos tesztelése, hogy megfelelő-e és nem okoz más problémát. (Ha pedig bukik a teszten a javítás, akkor lehet keresni tovább a megfelelő fix után)

Persze, kilehet hozni azonnal egy patchet, de ez megint nem a nyílt forráskód kiváltsága. A Windows WMF hibára is marha gyorsan kihozott egy MS-független ember javítást (az IDA Pro fejlesztője volt mellesleg), de a Microsoft csak több napos teszt után mert előállni hivatalos patchel a problémára és végül arról is kiderült, hogy nem tökéletes, mert kompatibilitási gondokat okozhat bizonyos esetekben... Szóval nem ennyire triviális ez.

Amikor reflektorfénybe került, hogy a Linux kernel null pointer dereference hibáit is jónéhány esetben kilehet használni DoS mellett privilégium emelésre, akkor arra is viszonylag gyorsan kihozott egy fejlesztő megoldást (ne lehessen mmap()elni a 0x0 offsetre), csak kiderült róla, hogy megkerülhető (nem volt elégséges az ellenőrzés és a 0x1 offsetre való mmap() a page "kerekítés" miatt végül ugyanúgy működött 0x0 címre). Aztán pár nappal rá hoztak ki egy további megoldást is, majd arra is találtak módszert, hogy meg lehessen kerülni (expand_stack kihasználása és a stack területének "lefelé" növekedésével ismét elérhetővé vált a 0x0 offset)... Ha jól emlékszem, akkor legalább négy alkalommal jött ki félmegoldás a problémára és ez több hónapon keresztül húzódott. Ezt aligha nevezném gyors és "rögtön javítás"-nak. Ráadásul nem kizárt, hogy néhányan kényelmesen hátradőltek, hogy milyen gyorsan érkezett megoldás a problémára és nem figyeltek a továbbiakban arra, hogy mennyire triviális azt kijátszani.

A biztonsági hibák száma, előfordulásuk gyakorisága, megtalálásuk nehézsége nem függ a szoftver fejlesztési modelltől. Mindegy, hogy egy szoftver nyílt vagy zárt forráskódú. Egy igazi hackert egyébként sem érdekelnek mindenféle jól hangzó elméletek, vallási kérdések, meg hasonlók és nem filózik szoftver minőségi kérdéseken sem, csak keres egy hibát, ír rá egy exploitot és kihasználja a megfelelő helyen... ;)

A zárt esetében is van esélyed... Ez egy téves nézet, amely főleg a nyílt forrást favorizálók körében terjed.

Van, ketsegtelen, de klasszisokkal nehezebb.

Tekints a zárt forrású szoftverek esetén előforduló másolásvédelmekre úgy, mint hibákra és a rájuk születő patchekre/crackekre, mint javításokra és máris rájössz, hogy mekkora butaságot írsz azzal kapcsolatban, hogy csak nyílt szoftver esetén van esély a hibák javítására

Ez igy eleg vicces. Persze, hogy a hibakat ki lehet javitani. De eg es fold a kulonbseg akozott, hogy egy betores utan en magam utana tudok menni, hogy mi tortent, hol jott be, hogyan, es mikent lehet kijavitani, es akozott, hogy a hogyan utan bamban nezek ki a fejembol, mert egy fia forrasom nincs. Igen, meg lehet csinalni, hogy anelkul javit az ember, erre is van rengeteg pelda, de lassuk be, az klasszisokkal nehezebb, mint ugy, ha van forras.

A forras jelenlete nagyban megkonnyiti a javitast. A nemlete nem teszi lehetetlenne, viszont sokkal nehezebbe, es lassabba valik a feladat. Valamint a teszteles is komoly akadalyokba utkozik.

Elobb-utobb valaki ugyis megtalalja a hibat, akar nyilt, akar zart. Ha nyilt, akkor nagyobb esellyel lehet megtalalni ezt

A jelenlegi hir jol mutatja, hogy valaki megtalalta. Tokeletesen jol igazolja az elmeletem: sehol sem mondtam, hogy a jofiuk talaljak meg. Egy rosszfiu megtalalta, es kihasznalta. Mivel nyilt forraskodu, igy a savannahsok is megtalaltak az eset utan, es ki tudtak javitani. Ha zart kodu lenne, akkor varhatnanak a vendorra. Ami jelen esetben igensok problemat vetne fel, mert a vendor kb mar nem letezik.

Ez sem feltétlenül igaz. Nem a javítás maga viszi el a sok időt, hanem egyrészről előtte annak kiderítése, hogy hogyan lehet vagy érdemes javítani magát a hibát, utána pedig annak alapos tesztelése, hogy megfelelő-e és nem okoz más problémát. (Ha pedig bukik a teszten a javítás, akkor lehet keresni tovább a megfelelő fix után)

Nem erdekel melyik resze visz el sok idot. Az eredmeny erdekel, miszerint ha nincs hozzaferesem a forrashoz, akkor ket lehetosegem van:

1) Varok a vendorra, kozben malmozok.
2) Nekiallok forras nelkul megoldast keresni.

Egyiket sem tartom hatekony megoldasnak.

Nyilt forras eseten magam utana tudok jarni, van ra eselyem, hogy workaroundolom vagy megjavitom a hibat, meg a vendor fix elott (nekem nem kell advisoryt irnom, N architekturan tesztelnem, stb - igy csomo idot sporolok).

Nekem, mint usernek, az a celom, hogy ASAP befoltozzam. Ha all a szolgaltatas, az nekem nem jo, amig nincs javitas (akar hotfix, akar workaround, akar a vegleges, korrektul tesztelt patch) addig nekem nagyon nem jo. Ertem en, hogy tesztelni kell, es a tobbi, egyet is ertek vele, nyilt forras eseten is, ha megszuletik a hivatalos javitas, azt hasznalom. De addig is, ha van ra lehetosegem - es nyilt forrasnal sokkal tobb lehetosegem van -, megjavitom magam, es addig is tovabb megy a szolgaltatas.

Persze, kilehet hozni azonnal egy patchet, de ez megint nem a nyílt forráskód kiváltsága. A Windows WMF hibára is marha gyorsan kihozott egy MS-független ember javítást (az IDA Pro fejlesztője volt mellesleg), de a Microsoft csak több napos teszt után mert előállni hivatalos patchel a problémára és végül arról is kiderült, hogy nem tökéletes, mert kompatibilitási gondokat okozhat bizonyos esetekben... Szóval nem ennyire triviális ez.

Nem azt mondtam, hogy a nyilt forras kivaltsaga. Persze hogy ki lehet hozni patchet barmire: de open source eseten ezt en is meg tudom csinalni, barki, aki erti a kodot, es meg tudja talalni a hibas reszt (ami post-mortem azert menni szokott).

Zart kod eseten is van erre lehetoseg, szamtalan pelda van ra, de az... hogy is mondjam... kolosszalis szivas forras nelkul javitani. Csinaltam mar olyat is, tobbet nem fogok.

Nyilvan nem mindig trivialis a fix, de nyilt forraskod eseten megvan az esely, hogy ha megis az (es sok esetben az), akkor ki tudom javitani nagyon hamar. Zart eseten ez nem all fenn.

Ezt aligha nevezném gyors és "rögtön javítás"-nak. Ráadásul nem kizárt, hogy néhányan kényelmesen hátradőltek, hogy milyen gyorsan érkezett megoldás a problémára és nem figyeltek a továbbiakban arra, hogy mennyire triviális azt kijátszani.

Igen, hibak vannak open source oldalon is (mint emlitettem, az emberek szar kodot irnak, akar nyilt, akar zart :P). Ugyanilyen peldat lehet talalni zart oldalon is, amikor honapokat, eveket kell varni egy-egy javitasra.

A biztonsági hibák száma, előfordulásuk gyakorisága, megtalálásuk nehézsége nem függ a szoftver fejlesztési modelltől. Mindegy, hogy egy szoftver nyílt vagy zárt forráskódú.

Igen. Ezt mar en is mondtam: akar zart, akar nyilt, a kod szar lesz es bugos. Nem errol van szo, hanem hogy a javitast melyik modell segiti jobban. Ha van forras, az pedig sokat segit. Ez nyilt forraskodu szoftver eseten adott, zartnal varhatunk a vendorra, vagy szivathatjuk magunkat, ha gyorsabban akarunk megoldast. Nem tudom hogy vagy vele, en nem szeretem magam szivatni.

De eg es fold a kulonbseg akozott, hogy egy betores utan en magam utana tudok menni, hogy mi tortent, hol jott be, hogyan, es mikent lehet kijavitani, es akozott, hogy a hogyan utan bamban nezek ki a fejembol, mert egy fia forrasom nincs.

A legtöbb Computer Hacking Forensic Investigator igen szomorú lenne, ha ez igaz lenne... :)

A valóság ellenben pont az, hogy a nyílt forrású szoftverek ezernyi forkja, fregmentálódása és mégtöbb különböző lefordított binárisa miatt sokszor jóval nehezebb egy betörést rekonstruálni, a kihasznált biztonsági hibát felderíteni és a hátrahagyott kiskaput leleplezni. Ilyen szinten a nyílt forrás egyébként se ér sokat, mert az embernek könyékig kell túrnia a memória dumpokban, a diszk imagekben és bitre pontosan tudni a binárisokban, hogy mi mit jelent és miért van ott. Windows rendszerek esetében ez viszonylag egyszerűbb, mert egy kézen megszámolhatók a verziók és azokra jól kialakított vizsgálati módszerek és eszközök léteznek. A tízcsillió számra létező Linux disztribúciónál, stable-api-nonsense kernelnél és userlandnél legény legyen a talpán aki memóriadump alapján rekonstruálni tudja, hogy milyen kernel struktúrák lettek felülírva, milyen rendszerhívásokat hookolt meg a támadó és melyik processzeket rejtette el a listából.

Nyilvan nem PHPisti fog utanamenni. Egy komolyabb hibat en sem fogok tudni megtalalni es kijavitani, de egy teljesen atlagosat, amibol a legtobbet elkovetik, siman.

Egy kernel exploittal valoszinuleg meggyulne a bajom, egy SQL injectionnel nem - nyilvan vannak fokozatok. De mindket esetben ott van a lehetosegem, hogy legalabb megprobalhatom. Zartnal ez nincs meg.

Szakembernek, akinek az a munkaja, hogy az ilyeneket felderitse, es befoltozza, annak nyilvan nagyobb szivas a nyilt forraskod az ezernyi forkkal. Nekem, mint teljesen atlagos hackernek viszont tobb lehetoseget nyujt. Nekem nem kell kismillio forkot ismernem, csak azt az egyet, ami nekem van.

Nekem nem kell kismillio forkot ismernem, csak azt az egyet, ami nekem van.

Ez jól hangzik és valószínűleg szívesen is habzsolják szavaidat a mindenre elszánt hű szabad szoftver követők, de van egy olyan érzésem, hogy ha kapnál egy memória mentést a saját rendszereden futó kerneleddel, akkor nem tudnád megmondani a nyílt forrás ellenére sem, hogy melyik rendszerhívásokat módosították és milyen kiskaput hagytak a rendszeredben az elkövetők... ;)

Csak egy memoria dumpbol valoban nem. Par egyeb tool, meg egy masik rendszer, ahol elemezhetem, azert kene. :P

(Mondjuk nem is lennek meg vele hamar: mint emlitettem, vannak fokozatok. Egy teljesen atlagos PHPisti alatal bennahgyott bugon keresztuli betorest pl pillanatokon belul meg tudok talani, es javitani. Hogy mit hagytak benne raadaskent, az pedig nem erdekel, mert backupbol teszem vissza a rendszert, amit tudok ellenorizni. Ahogy komolyodik a bug, annal nehezebb felderiteni - egy kernelre nem biztos hogy valalkoznek, mert erzesem szerint, mire azt megtalalnam, okosabb emberek mar reg megeloznek, igy nem erdemes szivatnom vele magam. De, azert annyira bizom magamban, hogy ha nagyon kell, meg tudnam csinalni. Legfeljebb lassu lenne.)

Egyszer összefutottam egy taknyolt-tákolt blogmotorral. Néztem a kódot, annyira kesze-kusza volt, hogyha az alapján kellett volna megtalálni valami bugot, akkor az összes hajam kihullott volna.

Ellenben szimpla blackbox teszteléssel kb. 5 perc alatt találtam benne egy súlyos bugot, amellyel nagyon jól hozzá lehetett férni olyan tartalmakhoz, amihez egyébként NAGYON nem kellett volna... Konkrétan az admin felület szerkesztő oldalán sima látogatóként ;)

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

"May refer" -> "utalhat".

Utalhat a cracker a fekete kalapos hackerekre is, mert néhány dezinformátor (akiket te is felszopsz és ezáltal tovább terjed ez a hülyeség) elterjesztett egy hamis definíciót a saját kis önös érdekük miatt: csak ők legyenek a jedi lovagok^W^Whackerek, mindenki mást hívjanak crackernek... Hát persze. Kár hogy ez nem egy mesevilág, hanem a valóság. Te meg nem munkanélküli vagy, hanem szabadfoglalkozású. Terjeszd ezt is így. Jobban hangzik, még ha továbbra is szerencsétlen balfasz maradsz ugyanúgy, aki sose az igazságot keresi, hanem az ellentétet.

A "bakelit" kifejezés is utalhat - tévesen - a vinyl hanglemezre, ettől még nem az a helyes...

Mindenesetre javaslom a politikai pályát. Képviselőként is elég lesz ez a néhány tranzisztorból megépíthető XOR művelet, amelyre képes vagy agyilag: ha a vezér mondja hogy 1, akkor egyetértesz, ha az ellenzék, akkor nem és kész.

Neked lehet hogy megfelel, mások viszont foglalkoztak a hacking és cracking témákkal már jóval a '90-es évek előtt is, amikor a te drága ESR-edet még sehol se jegyezték.

Azért mert ez a nyomorék '96-ban a popclient-et átnevezte fetchmail-re és elkezdte még jobban szétgányolni a már előtte se túl szép kódot, meg telerakni biztonsági hibákkal, attól még nem lesz nemhogy hacker, de még programozó se.

és mit bizonyít ez azon kívül hogy hackernek hiszi magát és a sok bullshit mellett elterjesztett egy emblémát is?

esetleg feltűnhetne, hogy semelyik komoly hacker csoport vagy hacker rendezvény sem használja ezt az emblémát a ccc-től a defconon át a shmooconig... oh, és ők mind hacker csoportok és konferenciák, nem cracker, nahát.

Semmi. Emlekeim szerint meg is tettek parszor, legalabbis halvanyan dereng ilyesmi (de linket elokeresni per pill nincs se idom, se kedvem, google biztos segit, ha nagyon erdekel).

Nem tudom, nezted-e a kodjat a savannahnak, en ahhoz nem nyulnek, csak ha fizetnek (es akkor sem szivesen), pedig szeretem magam abban a hitben ringatni, hogy jofej szabad-szoftver hivo figura volnek. Igy nem csodalom, hogy nem sok segitseget kaptak :P

Elmélet vs gyakorlat.
http://git.savannah.gnu.org/cgit/savane-cleanup.git/log/ :

Meg lehat nézni hogy van egy fő kommitoló (Sylvain Beucler) meg páran akik néha beletúrnak a kódba. A kód minősége gyakorlatilag egy embertől függ. A többiek meg meg max beleteszik azokat a funkciókat amikre nekik pluszban szükségük van a projekthez - ha rendesek.

Ellenben vannak jól működő nyílt forráskódú projektek is nem kis számban. De hogy biztonságosabbak lennének mint jól fizetett programozók által írt auditált zárt forrású kód? Szerintem ez az állítás már régen megdőlt.

> hogy biztonságosabbak lennének mint jól fizetett programozók által írt auditált zárt forrású kód? Szerintem ez az állítás már régen megdőlt.

Ha jól látom, akkor elképzeltél magadnak egy állítást, majd azt is elképzelted hogy megdőlt. Önkiszolgáló vita. :-)))

> Ellenben vannak jól működő nyílt forráskódú projektek is nem kis számban. De hogy biztonságosabbak lennének mint jól fizetett programozók által írt auditált zárt forrású kód? Szerintem ez az állítás már régen megdőlt.

Mikor? Es egy zart korben auditalt forras miert lenne biztosan jobb, mint egy nyilt korben auditalt forras? (nem vagyok nagy openbsd rajongo, de ok azert egesz jol csinaljak ezt a biztonsag meg auditalas dolgot, azt el kell ismerjem)

Jelzem, ott van pl a Chrome, amin szerintem eleg jol fizetett, es nem is hulye programozok dolgoznak, aztan megis az egyik legtobb sebezhetoseget tudhatta maganak ezevben.

Van pelda mindket oldalon jora is, rosszra is. Egyik sem tokeletes megoldas. (A tokeletes megoldas az lenne, ha az emberek tudnanak hibatlan kodot irni, de az nem lehetseges)

Nem is a manyeyeballs reszere reagaltam a kommentednek, hanem ama kinyilatkoztatasodra, hogy "De hogy biztonságosabbak lennének mint jól fizetett programozók által írt auditált zárt forrású kód? Szerintem ez az állítás már régen megdőlt."

Ami finoman szolva is bullshit: a zart forrasu ugyanolyan szar, csak nem latod :P

Oh, hogyne. Már látom, ahogy a BMW lecseréli a zárt forrású kódokat a kormányművekben, és a Siemens engedélyezi, hogy szabadon committelhessenek az atomerőmű vezérlő szoftvereikhez. Sőt, a műtőasztalon fekvő hacker akár majd meg is patchelheti a GE röntgengépek FOSS vezérlőszoftverét, csak mert a zárt kód szar...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Egy zárt forráskódú szoftvernél, mindig csak az a kérdés, hogy a szoftver fejlesztője akar-e magas biztonságú kódot, és hajlandó-e megfizetni ennek az árát. Ehhez minden eszköze megvan, lévén a zárt kódok fejlesztőit rá lehet kényszeríteni a megfelelő szankciókkal a megfelelő tesztelés és biztonsági auditálásra.
Ugyanezt egy open-source projectnél nem tudod elérni, mert pillanatok alatt eltűnne a "many eyeballs".

Hogy mennyire szar egy adott alkalmazás, az attól függ mik a követelmények a piac felől.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Ezen jot nevettem, koszonom.

Ha ez igy lenne, azt magyarazd el nekem, hogy miert van annyi hiba - akar biztonsagi, akar mas - kulonbozo zart kodu szoftverekben? Gondolok itt olyan szoftverekre, amit nem kis sufni ceg fejleszt, hanem megfelelo tokevel, es megfeleloen kepzett es hozzaerto csapattal dolgozo cegek alkotnak, es kritikus helyeken is hasznaljak.

Vajon a Windowsban, amit igen kritikus helyeken is hasznalnak, miert lehet biztonsagi hiba, nem is keves, ahogy azt az evek soran lattuk? Van meg rengeteg pelda, de talan a Microsoftrol elhiheto, hogy van penze, es embere, hogy komoly auditot folytasson, es megkovetelje a korrekt kodot (aztan valahogy megsem teszi).

Megjegyeznem, hogy egy igen meretes kodbazis auditalasa nem kis feladat, es meg az auditorok is tudnak hibazni, ilyenre is volt mar jopar pelda.

Nos, talán azért, mert a kód auditálása, tesztelése pénzbe kerül. Egy biztonságkritikus rendszernél több teszter masszírozza a kódot, mint ahányan fejlesztik.
A Windows NEM biztonságkritikus rendszer, soha nem is állították róla (lásd. EULA). Mindaddig a Microsoft sem öl erőforrást bele, míg ezt nem igénylik a vásárlói. Ugyanez vonatkozik más zárt szoftverekre is. Amíg a piac nem kéri tőlük addig, nem fognak törekedni a magas biztonsági szintekre.

Hogy miért használják mégis kritikus helyeken?
a, Mert nem értenek hozzá.
b, Mert nincs jobb alternatíva.
c, Mert megfelelő infrastruktúrával, vagy biztonsági megoldással képesek áthidalni a hibáit.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Oke, ezesetben ajanlom figyelmedbe ezt az oldalt, amit kb fel perc kereses utan talaltam.

Szerintem van a listan nehany erosen kritikus rendszer, ahol a hiba ember eletekbe kerult, aztan megis maradt bennuk hiba (lehet, hogy nem biztonsagi hiba, de az jelen esetben lenyegtelen; nem csak a biztonsagi hibak kritikusak, es nem csak azokat kell keresni es megtalalni, ugye). Erosen ketlem, hogy nem volt meg az igeny, penz es ido a tesztelesre es auditalasra. De megis maradt hiba.

Az emberek hibaznak, akarmennyi penzt dobsz oda nekik, es akarhany embert is alkalmazol.

Az általad linkelt hibák java része pont a klasszikus, nem tesztelünk rendszerkritikus alkalmazásokat.
Pl. Mars Climate Orbiter esete jól példázza a hiányos/rosszul definiált specifikációk alapján, tesztelés nélkül használt kódra. Ugyanis ez a hiba egy szimulált mars utazásnál kihullott volna. Amúgy a NASA igencsak hirhedt a különféle alvállalkozóktól összeszedett, teszteletlen kódok használata miatt.
A felsorolásból talán a legsúlyosabb a Therac-25 balesetek, ahol szintén klasszikus szoftverfejlesztési hibák sorozata volt.

Biztos vagyok benne, hogy nem ülnél egy modern autóba, ha csak a felét ismernéd azoknak a bugoknak amiket a teszteléskor a kollégáim kiszórnak a kódból. És ez utóbbi nem kivitelezhető az open-source-os "many eyeballs" metódussal.

Az emberek hibáznak, de ez kikerülhető megfelelően tervezett, specifikált, implementált és tesztelt rendszerrel.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Nem kivitelezheto? Akkor hajra!

De, hogy mondjak meg par ellenpeldat arra, hogy a teszteles sem ved minden ellen: itten, vagy ott van a hires-hirhedt pentium floating point divide bug (bar erre is biztos lesz erved, hogy az Intel mennyire nem teszteli a processzorait, vagy kinabol importalja), ez is erdekes olvasmany, bar rafoghato, hogy biztosan nem volt elegge tesztelve (dehat az szerencsere univerzalisan mindenre rafoghato, amiben bug van, szoval hurra!), esatobbi.

Javasolnam, hogy olvasd el, mit irtam korabban, a valasz az aggalyodra mar reges reg el lett mondva.

De segitek: nem, nem hiszem, hogy a linux (vagy akarmelyik mas OS) jobb lenne ilyen tekintetben. Mind ugyanolyan bugos, mint a masik. Linux (meg a nyilt forraskudu szoftverek) eseteben viszont ha mar megtortent a baj, akkor meg tudom keresni, es ki tudom javitani, mig zart kod eseteben a vendorra vagyok utalva, aki vagy javitja idoben, vagy nem. En meg rettento bizalmatlan tudok lenni rossz napjaimon.

>>Ha ez igy lenne, azt magyarazd el nekem,
>>hogy miert van annyi hiba - akar biztonsagi,
>>akar mas - kulonbozo zart kodu szoftverekben?

>>Van meg rengeteg pelda, de talan a Microsoftrol elhiheto,
>>hogy van penze, es embere, hogy komoly auditot folytasson,
>>es megkovetelje a korrekt kodot (aztan valahogy megsem teszi).

Valójában a kereskedelmi (zárt és nyílt) szoftvereken senki nem folytat valódi komoly auditot, csak gazdaságos auditot. Az eredményt ismerjük. Nem értelmetlen a 'gazdaságos audit' sem sok hibára fényt derít, de nem garantálja a hibátlan kódot. Valójában teljes, formális módszerekkel igazolt ellenőrzésre lenne szükség, de az nagyon sokáig tartana még magasan képzett programozókkal is. a sel5 7500 soros C kódjánál ez 4 év volt.
Mennyi ember, hány évi munkájára lenne ehhez szükség egy alap szolgáltatásokat nyújtó Windows vagy Linux rendszeren? Hiába gépi az ellenőrzés ma még nem lehetne úgy felgyorsítani, hogy alkalmazható legyen a kereskedelmi vagy nyíltnak mondott (de egyre inkább kereskedelmi) szoftverfejlesztés világában.