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