25 éves hibát találtak a BSD-ben
 |
A nyílt forrású szoftverek megszállott támogatói gyakran érvelnek azzal a vélelmezéssel preferenciájuk mellett, ami szerint a szabadon hozzáférhető kódú programok zárt társaiknál kevesebb hibát tartalmaznak, és azok gyorsabban kerülnek javításra, pusztán azon oknál fogva, hogy azokat több szem láthatja, mint a titkos vállalati szervereken szunn.. »tovább... |
Egy kibic a pálya széléről bekiabál. Ismered?    |
Két kecske meg egy híd a szakadék felett.
Ismeritek? |
Ó, ezek szerint az "abszolút" az csak egy töltelékszó, hogy hosszabb legyen a hozzászólásod. 
|
| Ezeket a kérdéseket talán annak az embernek kellene feltenned, akitől hallottál bármiféle relatív korról beszélni. Tőlem nem halhattál, tehát tőlem ne kérdezd! |
én nem a szoftver abszolút kora, hanem
Ezt a "szoftver abszolút kora" dolgot elmagyarázhatnád.
Mi a különbség egy "szoftver abszolút kora" és a "szoftver relatív kora" között?
Ha szerinted a "a szoftver abszolút kora önmagában SEMMILYEN relevanciával nem bír a biztonságosságot illetően", akkor milyen relevanciával bír a szoftver relatív kora a biztonságosságot illetően?
Milyen más "kora"-i vannak a szoftvereknek amiket érdemes lenne figyelembe venni a biztonság témakörében?
|
Látom kevés vagy felismerni, hogy én nem a szoftver abszolút kora, hanem az elkészítéséhez használt eszközök minősége, kiforrottsága, átfogósága és a biztonság közötti összefüggést vázoltam fel. Nem azt mondtam, hogy az újabb szoftver azért biztonságosabb, mert kevesebb éves, hanem akkor és azért biztonságosabb ha és mert egy biztonságosabb eszközzel készítik, tesztelik. Ha az új szoftvert egy régi platformon, régi eszközökkel készítik (ami nyilván lehetséges), akkor nyilvánvalóan pusztán attól, hogy fiatalabb, nem lesz biztonságosabb. Ez tökéletesen egybecseng az általad is idézett korábbi állításommal, ami szerint a szoftver abszolút kora önmagában SEMMILYEN relevanciával nem bír a biztonságosságot illetően. 
Az meg külön mókás, hogy az állításom általad a semlegessel szemben igaznak beállítani próbált félreértelmezése is pont ellentétes előjelű korrelációt vázol fel a szoftver kora és biztonságossága között, mint ami mellett te próbáltál korábban érvelni. Tehát még akkor is öngólt lőnél vele, ha a te félreértelmezésedben igaznak fogadnánk el. |
Tehát a szoftver abszolút kora SEMMILYEN relevanciával nem bír önmagában a biztonságosságot illetően.
Nem kellek én ide, hiszen idővel magad is rájössz, hogyha valamiben nincs igazad:
Tehát az újabb, fiatalabb szoftvereket -egyértelműen több és jobb eszközzel és több támadási vektorra vizsgálnak meg, mint a régieket (legalábbis statiszikai méretekben és értelemben).
egy viszonylag fiatal szoftver statisztikai értelemben általában biztonságosabb lesz, mint egy viszonylag öreg.
|
Eltekintve pld attól, hogy a szoftver fejlesztésének idejében mi számított biztonságosnak, és emiatt mi az, amit biztosan nem ellenőriztek sem a szoftver tervezésekor, sem az elkészült kód ellenőrzésekor.
Természetesen ez sem igaz, hiszen az, hogy egy adott kódot egy adott szempont szerint nem ellenőriztek, nem jelenti azt, hogy a kód ettől az adott szempontból biztosan hibásan fog működni. Ugyanígy az, hogy úgymond ellenőrizték sem feltétlenül jelenti azt, hogy hibátlanul fog működni minden körülmények között - hiszen az adott ellenőrzés is lehetett hibás, hiányos.
Arról már nem is beszélve, hogy ez az állítás, ha igaz lenne (mint ahogy nem az), akkor is pont az általad korábban megfogalmazott állítás ellen - és nem mellett szólna. Hiszen a fenyegetések sokrétűsége csak nő, nem csökken, és a biztonság ill. egyéb kódtesztelő metodikák és eszközök is csak előre fejlődnek, nem vissza. Tehát az újabb, fiatalabb szoftvereket -egyértelműen több és jobb eszközzel és több támadási vektorra vizsgálnak meg, mint a régieket (legalábbis statiszikai méretekben és értelemben).
Ráadásul a fiatalabb szoftverek jellemzően olyan fejlesztőeszközökkel és -platformokon készülnek, amelyek eleve jobban rezisztensek a tipikus programozási hibákkal szemben (lásd pl. egy C vagy C++ program egy Java vagy .NET programhoz képesti rezilitása pl. puffertúlcsordulási hibákra biztonsági szempontból), ami megint csak azt jelenti, hogy egy viszonylag fiatal szoftver statisztikai értelemben általában biztonságosabb lesz, mint egy viszonylag öreg. |
Tehát a szoftver abszolút kora SEMMILYEN relevanciával nem bír önmagában a biztonságosságot illetően.
Eltekintve pld attól, hogy a szoftver fejlesztésének idejében mi számított biztonságosnak, és emiatt mi az, amit biztosan nem ellenőriztek sem a szoftver tervezésekor, sem az elkészült kód ellenőrzésekor.
Egy vitában pedig az, hogy tudod -e bizonyítani az elméletileg objektív módon ellenőrizhető állításaid dönt afelől, hogy [...]
Egy vitában pedig az, hogy tudsz-e érvekkel/tényekkel cáfolni elméletileg objektív módon cáfolható állításokat dönt afelől, hogy dilettáns nagyszájúnak vagy komolyan vehető vitapartnernek tartanak -e a többiek.
|
Eltekintve attól, hogy múltbeli tényadatok* ismeretében saccoljuk meg a jelen- és (közel)jövőbeli kockázatokat, nem számít.
Igen, de tekintve, hogy a szoftverek nem egyetlen pillanatban, egy ősrobbanásban keletkeztek, hanem folyamatosan készülnek újabb és újabbak belőlük (beleértve az új verziókat is), ezért komparatív módon összevetni őket csakis egy önkényesen kiválasztott, de releváns időtartam adatainak összevetésén keresztül lehetséges. Tehát a kockázatszámítás alapja csakis az lehet, hogy X idő alatt (átlagosan) hány biztonsági rés volt nyitva szoftverben ill. hogy eddig összesen hány biztonsági rést találtak bennük időarányosan. Ha egyáltalán lehet, akkor ezek alapján lehet "saccolni", hogy a jövőben milyen gyakorisággal sikerül újabb biztonsági rést azonosítani ill. hogy azok átlagosan mennyi ideig lesznek nyitva lezárás előtt. Ezen jellemzőknek viszont egyike sem függ szorosan a szofver abszolút korától. Ergo, utóbbi önmagában teljesen irreleváns a biztonság vonatkozásában.
Azt, amelyik 10 perce készült el, és még senki sem talál(hatot)t benne hibát; vagy azt amelyiknek a hibáit már 10 éve javítgatják?
A kérdésfelvetés eleve abszolút rossz, mert tíz perces időszak vizsgálata teljesen értelmetlen (túl rövid) ebben az összefüggésben. Ennél is fontosabb azonban, hogy a hibák felfedezésének és javításának üteme a rendelkezésre álló idő mellett sok minden más faktortól függ - sőt, azoktól sokkal jobban függ, mint az időtől -, így utóbbi önmagában nem lehet elegendő bármilyen összehasonlításhoz.
Hogy mást nem mondjak pl. nyilvánvalóan bármikor tudok mutatni neked egy 10 perce készült programot, ami formális logikával bizonyítható módon mentes biztonsági hibáktól (pl. Hello world). Tehát a szoftver abszolút kora SEMMILYEN relevanciával nem bír önmagában a biztonságosságot illetően.
Ez nem matematika, hogy bizonyítani kelljen.
Valóban nem matematika, hanem egy vita. Egy vitában pedig az, hogy tudod -e bizonyítani az elméletileg objektív módon ellenőrizhető állításaid dönt afelől, hogy dilletáns nagyszájúnak vagy komolyan vehető vitapartnernek tartanak -e a többiek.
Bőven elég hogy nincs.
Az valóban bőven elég lenne ha nem lenne - csak sajnos utóbbi állítás igazságát még mindig nem igazoltad. Ami nélkül a fenti két eset közül az, hogy komoly vitapartnernek tekintsenek, kizárt. |
Nincs?
Fogalmazz ebből egy "teljes" kérdést, és akkor majd magad is meglátod.
|
| Nincs? |
Szoftvereknél mióta számít a biztonság vonatkozásában az, hogy egy szoftver milyen öreg,
Eltekintve attól, hogy múltbeli tényadatok* ismeretében saccoljuk meg a jelen- és (közel)jövőbeli kockázatokat, nem számít.
*beleértve a múltbeli fejlesztési, tesztelési metódusokat, stb.
Melyik szoftvert biztonságosabb használatba venni? Azt, amelyik 10 perce készült el, és még senki sem talál(hatot)t benne hibát; vagy azt amelyiknek a hibáit már 10 éve javítgatják?
Akkor már csak azt kell bizonyítanod, hogy nincs egyetlen ellenpélda sem.
Ez nem matematika, hogy bizonyítani kelljen. Bőven elég hogy nincs. |
Mennyi ez élethosszra vetítve, százalékban?
Szoftvereknél mióta számít a biztonság vonatkozásában az, hogy egy szoftver milyen öreg, és nem csak az, hogy hány biztonsági rés és meddig van benne? Kopnak benne a bitek idővel, vagy patinásabbá válnak?
Egyébként meg egy másik, az előző "szemes" példához hasonlóan megalapozott mítosz szerint a nyílt forrású szoftvereket gyakrabban frissítik és gyakrabban adnak ki új változatokat belőlük ("release early, release often"), tehát azok újabb és újabb verzió - statisztikai értelemben és átlagban - mindig fiatalabbak, mint zárt forrású társaiké. Nem?
Ellenpélda hiányában az állítás igaz.
Akkor már csak azt kell bizonyítanod, hogy nincs egytlen ellenpélda sem. Ami pl. a konkrét eset mellett elég nehéz lesz. |
Akkor ez most egy axióma?
Nem bizonyítható, de cáfolni sem lehet ezért fogadjuk el igaznak?
Egyébként meg akár (kicsit extrém) 100 éves hibát is fel fedhetnek egy rendszerben az effektív veszélyességi szintje konvergál a nullához. Mivel senki nem tud róla ezért olyan sincs aki kihasználja.
Ha meg valaki kihasználja akkor a nagy számok törvénye alapján rövid időn belül fény derül a biztonsági résre... |
Ettől függetlenül 25 még mindig másfélszer annyi, mint a 17,
Mennyi ez élethosszra vetítve, százalékban?
egyetlen hiba sem maradhat benne rejtve...
Ellenpélda hiányában az állítás igaz.
|
Alig 3 hetes hír: 17 éves súlyos hibát találtak a Windows-ban.
Ettől függetlenül 25 még mindig másfélszer annyi, mint a 17, ráadásul a Windows zárt forrású, a BSD meg nyílt forrású ami állítólag azért jó, mert így millió szem vizslathatja és egyetlen hiba sem maradhat benne rejtve...  |
Roviden. Ami teny, hogy az adott cikk semmikeppen sem minosul HIR kategoriaba. A komoly lapok megkovetelik, hogy egy-egy hirben semmikepp sem hangozhat, szurodhet bele szemelyes velemeny meg sugalat formalyabn sem. A hir csak a nyers tenyeket kozolheti. A hir velemenyezesere van a szerkesztoi kommentar rovat (angolul Opinion), mely pontosan azert jott letre, hogy rakenyszeritse az ujsagirokat, hogy a hirben csupan a kesz tenyeket kozoljuk. Azutan egy kulon rovatban kifejthetik a velemenyunk, de ez meg is van jelolve, hogy egy szemelyes velemeny vagy egy csoport (pl. a szerkesztoseg) velemenye - lasd a legminosegesebb lapokat, hirszolgaltatasokat (bovites: hozok peldat is, pl. New York Times, ahol a hirrovatot nem vadolhatot valamely oldal partolasaval, ugynakkor a velemenyeket olvasod ahogy akarod).
Sajnos ez a fajta hozzaallas magyar ujsagirasban nem igazan akar elterjedni, ez miatt szinte lehetetlen partatlan hirt olvasni (es itt nem csak az informatikai hirekre gondolok).  A magyar szemlelet meg mindeg ott tart, hogy az en partoloim es az ellenfeleim, rendszeresen ket fele kell szakitani a picurka magyr tarsadalmat. 
(bovites: ez utobbi bekezdes mar semmikepen sem teny, hanem velemeny!) |
Megjegyzem szerintem ennél sokkal durvább hiba az openssl-elben felfedezett bug, ami már két éve benne van és ami miatt a kulcskészlet igencsak le lett redundálva.
Szóval... |
| Bocsi, de egykicsit férre érthető volt. |
| Átolvastam. Valahol biztos elvesztettem a fonalat, de nem jövök rá, hogy mire reagáltam rosszul. |
Ööööö...
Nem pont ugyan ezt írtam én is?
|
4. A BSD-t 25 éve "fejlesztgetik" a MS OS palettája ez alatt minimum 3x cserélődött le - szinte - teljesen. Bár valószínűleg cipelnek kódokat, azért azt nem hinném, hogy lenne olyan rész a Vista-ban, ami MS-DOS-ból származik és nem kellett szinte teljesen újraírni (hacsak nem egy nagyon eldugott és alap FAT16 vagy FAT8 kezelő routin).
Mondjuk ez nem nagyon valószínű, max valami FAT-os alap rutin esetleg az amúgy már elég érdektelen NTVDM ntio.sys, ntdos.sys vagy command.com komponensében, az NT magjának nics semmi köze a DOS-hoz, sőt magának a Win32 API-nak sem. |
| Na, most akkor olvasd el még egyszer, hogy én mit írtam, meg azt, hogy te mit írtál! |
Ez így ebben a formában nem igaz, hiszen amikor ismertté válik egy hiba, sebezhetőség, akkor azt bárki visszanézheti, sőt, profik jellemzően vissza is szokták nézni, hogy a szoftver mely verzióit érinti
MS03-026:
Az Affected és Not Affected listában nem szerepel sem a Win 9x, sem az NT 3.51. 2003-ban már egyiket sem supportálták.
Most azért nem volt a listában az NT 3.51, mert nem volt már rá support, vagy azért, mert valóban nem érintette?
Ez jobb:
MS03-031:
Az Affected Software listában a legelső verzió a 7.0. Csak azért, mert a 6 és 6.5-ös már nem supportált, vagy azért mert a 6.0-ban még nem működött pl. a "Named Pipe Hijacking" vulnerability?
Sose fogod megtudni, hacsak ki nem próbálod. |
3. Ha egy hibát foltoznak egy zárt termékben, akkor azt te soha nem fogod megtudni, hogy mióta van benne. Valaki felfedezte, megint más foltozta és kész.
Ez így ebben a formában nem igaz, hiszen amikor ismertté válik egy hiba, sebezhetőség, akkor azt bárki visszanézheti, sőt, profik jellemzően vissza is szokták nézni, hogy a szoftver mely verzióit érinti, sőt, a gyártó maga is publikálja ezt az információt jellemzően a biztonsági értesítőjében.
Persze az elképzelhető, hogy ha a hibát a fejlesztő előbb fedezi fel, mint a nyilvánosság, akkor úgymond szó nélkül javítja - bár tapasztalataim szerint nagyon sok zárt kódú programok esetében is ott szokott lenni a changelog, amelyben ha nem is kimerítően, de legalább tőmondatban ott szokott lenni a javított hibák felsorolása. Nincs is ebben semmi, senki sem vár(hat)ja el, hogy helyből tökéletes legyen egy a maiakra jellemző komplexitású és méretű program, és a csiszolási, fejlesztési folyamat természetes.
Ugyanakkor ez ugyanígy nyílt forrás esetében is elképzelhető, sőt, nyilván meg is valósul, hogy ti. nem feltétlenül vernek nagydobra minden egyes javított bugot, pláne, ha az nyilvánosan nem is volt ismert. És itt megint mondhatjuk, hogy persze, de vissza lehet ellenőrizni a forrásból - de azt már ne képzelje senki, hogy komolyan tömegek foglalkoznak azzal, hogy vizslatják az egy-egy komolyabb program komolyan release-e esetében akár több megásra vagy tízmegásra is rúgó diffeket, az után vadászva, hogy nincs -e benne valami sunyiban javított hiba, amiről a fejlesztők nagyban hallgatnak. Szóval szerintem ez megint egy olyan úgymond elméleti előny, ami a gyakorlatban abszolút nem - vagy ha igen, csak jelentéktelen mértékben - realizálódik.
Azzal viszont már erősen vitatkoznék, amire ezzel a mondatoddal próbálsz utalni, ti. hogy a zárt kódban kevesebb eldugott bug lenne. (Avagy nem ezt akartad sugallni a "..."-el? Akkor bocs.)
Hát, őszintén szólva gőzöm sincs, hogy három pontból hogyan tudtad a fenti "sugallatomat" kiolvasni, de biztosíthatlak róla, hogy én azt nem szándékoztam jelezni velük... |
Anno hallottam valami Iraq (vagy Irán - nem emléxem) államigazgatási területre szánt német tűzfal progiról, amibe belekerült egy kis turpisság: jelentgetett a készítőjének. Utóbb kiderült, hogy CIA megbízásra. A cég eltűnt a süllyesztőben. (Lehet, hogy urban legend, de ezért hoztam ezt a példát.)
Miközben ráadásul 25 éves hibákról és megbújó kémprogramokról szóló hírek a hasonló, de zárt forrású szoftverek esetében elmaradoznak...
Azért tegyünk tisztába valamit:
1. Ez nem jelenti azt, hogy nincs is (csak azt, hogy egyenlőre nem derült ki)
2. A BSD elterjedése (vagy inkább el nem terjedtsége) okán nehezebb felfedezni a hibát, mint a Linuxban vagy a Windowsban.
3. Ha egy hibát foltoznak egy zárt termékben, akkor azt te soha nem fogod megtudni, hogy mióta van benne. Valaki felfedezte, megint más foltozta és kész. Szinte lehetettlen egy korábbi verzióval ugyan azokat a körülményeket reprodukálni.
4. A BSD-t 25 éve "fejlesztgetik" a MS OS palettája ez alatt minimum 3x cserélődött le - szinte - teljesen. Bár valószínűleg cipelnek kódokat, azért azt nem hinném, hogy lenne olyan rész a Vista-ban, ami MS-DOS-ból származik és nem kellett szinte teljesen újraírni (hacsak nem egy nagyon eldugott és alap FAT16 vagy FAT8 kezelő routin).
Tehát: azzal egyetértek amiről a cikked szól: semmi nem biztosítja azt, hogy egy nyílt forrású progi kódja szebb / jobb / kevésbé bugos, mint a zárt kód. Azzal is egyetértek, hogy semmivel sem valószínűbb (vagy legalább is nem sokkal) hogy egy nyílt szoftverben csak azért fedezzenek fel bugot, mert annak a forráskódja hozzáférhető.
Azzal viszont már erősen vitatkoznék, amire ezzel a mondatoddal próbálsz utalni, ti. hogy a zárt kódban kevesebb eldugott bug lenne. (Avagy nem ezt akartad sugallni a "..."-el? Akkor bocs.) |
Tény: nehéz pl. egy olyan nyílt forrású tűzfalat (vagy akármi mást) írni, ami mellesleg kémkedik az FBI-nak vagy a CIA-nak. Ez gyorsan kibukna.
Ebben én nem lennék biztos ez az eset után. Utóbbi ugyanis pont azt bizonyítja, hogy gyakorlatilag bármit bele lehet csempészni egy még olyan a figyelem középpontjából álló és rendkívül széles körben elterjedt nyílt forrású szoftverbe is, mint a Firefox. Ráadásul amit még érdemes az adott eset kapcsán észrevenni az az, hogy a trójai meglétét nem úgy fedezték fel, hogy vizslatták a kódot és észrevették, hogy hoppá itt van ám egy trójai is, hanem nemes egyszerűséggel az egyik víruskergető felismerte az adott - egyébként máshol is előforduló - trójai szignatúráját, kiabált rá, és ez hívta fel a figyelmet rá. Ha a Firefox nem egy a vadonban is előforduló trójait, hanem egy tök egyedi kémkódot tartalmazott volna (amit a víruskergető ennél fogva nem ismer fel), az jó eséllyel még most is ott szunnyadna benne - pontosabban dolgozna - észrevétlenül.
Persze tudom, most megint jön majd valaki kimagyarázni, hogy az egyedi eset és ebből nem lehet általános következtetéseket levonni - csak az a baj, hogy most már majdnem minden másnapra jut egy ilyen egyedi, elszigetelt eset, amelyből nem lehet általános következtetéseket levonni.... Miközben ráadásul 25 éves hibákról és megbújó kémprogramokról szóló hírek a hasonló, de zárt forrású szoftverek esetében elmaradoznak... |
A szervereket jó esetben magasan képzett szakemberek működtetik. Sok esetben olyanok akik képesek megtalálni egy hibának az okát, amit aztán vagy a tüneti kezeléssel orvosolnak, csinálnak hozzá valamilyen workarundot, vagy javítják a hibát.
A szervereket rendszergazdák üzemeltetik, nem pedig programozók - utóbbiak a programok írásával vannak elfoglalva. Na, most persze a két feladatkör nem különül el egymástól tökéletesen, de ugyanúgy ahogy egy alapvetően szoftverfejlesztéssel foglakozó emberre sem bíznám egy éles szerver bekonfigurálását, éppen úgy a szervereket üzemeltető rendszergazdák 99%-ából nem nézném ki, hogy az egyszerű shellscripteknél többet meg tudnának írni. De ha igen, még akkor is ott van, hogy neki az a dolga, hogy a rendszert életben tartsa, és nem az, hogy bugok után vadásszon - így életszerűtlen azt képzelni, hogy a rendszergazdák tömegesen nyomoznak a nyílt forrású programok hibáinak forrásai után és készítenek javításokat hozzájuk, hanem max. workaroundöket keresnek azokra, vagy a főnökségnek javasolják a rendszer kidobását úgy ahogy van ha nem megy, és vásárolnak helyette egy ugyan zárt forrású, de működő megoldást...
Zárt forrás esetén az utóbbira elég kevés az esély ez sztem elég könnyen belátható, közlik a problémát, a szoftver gyártójával aki jó esetben, valamikor javítja - lényegében nem tudni mikor, ezt ugye lentebb kifejtették, hogy az pl az M$ is rangsorolja a hibákat. Ha a forrás elérhető, akkor viszont ezen szakemberek hozzáláthatnak a hibajavításának, amellett persze, hogy jó esetben küldenek hibajelentést a szoftver elkészítőinek, akik ugyancsak rangsorolva a hibát neki látnak a foltot elkészíteni.
Erre azt tudom mondani, hogy én már pl. készítettem bináris patchet (kb. még egy évtizeddel ezelőtt) a Win9X-ek WinSock2 VXD-jének egy elég durva bugjára úgy, hogy szépen visszafejtettem az egész WinSock architektúrát (kb. 5-6 DLL/réteg), lekövettem a hibát, és elkészítettem a bináris javítást hozzá, ami tökéletesen működött is. Nem állítom, hogy egyszerű volt, még azt sem, hogy fordítható forrás birtokában ne lett volna mondjuk feleannyi vagy mégkevesebb idő - de ettől még alapvetően lehetséges.
Innentől kezdve meg csak az a kérdés, hogy hány és milyen ember mennyi energiát feccel ebbe, és ha elegendően sok és jó szakember sokat, akkor lehet, hogy összességében még mindig gyorsabban fedezik fel a hibákat és készítenek akár javításokat is hozzájuk, mint ahogyan a nyílt forrású programokhoz gyártják ugyanezeket az azokat vizsgáló fejlesztők.
Szóval azt hiszem megint oda jutottunk el, hogy egyáltalán nem biztos, hogy a nyílt forrás bármilyen tényleges előnyben van ezen a téren, bár a kérdés megválaszolásához (akár prop, akár kontra) mindenképpen olyan adatokra lenne szükségünk, amelyeket becsülni nem tudunk, mérni meg iszonyat nehéz lenne, ha egyáltalán lehetséges. Általános kijelentéseknek mindenesetre utóbbiak hiányában biztosan nincs helye. |
|
