Názory k článku
Vážná zranitelnost v nástroji Ghostscript dovoluje vzdáleně spustit cizí kód
-
1. Nemůžete vůbec vědět, jestli o chybě někdo dlouho neví (nezmapoval si ji ze zdrojáků), a jen o tom nemlčel. (U closed source je daleko těžší na chybu přijít, většinou se to podaří jen náhodou).
2. U closed source je spousta chyb opravená interními postupy a nikdy se nezveřejní ani že byla, ani jaká byla, ani jak byla opravena. Tj. chyba, byť existentní, je ve skutečnosti prakticky neexploitovatelná.Výhoda open source coby lepší alternativy pro odhalování chyb je mnohokrát vyvrácená chiméra. Můžeme se bavit o tom, že open vs. closed source má každý jiná rizika a mohou každému jinou měrou hrozit. Tvrdit ale, že open source vede k lepšímu kódu, rychleji nalezeným chybám apod. je dost odvážné.
-
Radovan (neregistrovaný)
No jistě, a navíc chyby v closed source jsou dělané záměrně a ve velkém množství, aby se hackerům bránilo v hledání těch skutečných: https://vtm.zive.cz/clanky/nova-zbran-proti-hackerum-obrovske-mnozstvi-chyb-v-softwaru/sc-870-a-194556/default.aspx :-DDD
-
v bode 2 jak jste se dostal z prvni vety k zaveru v druhe vete, tedy ze chybe "je ve skutečnosti prakticky neexploitovatelná."? tam chybi logika nebo navaznost.
Pokud chyba je, ale neví o ní nikdo než interní zaměstnanci, pak se ve skutečnosti nedá exploitovat. Takových chyb je v komerčním sw většina.
-
Karel (neregistrovaný)
Ono je to celé mnohem složitější a čím více se člověk snaží zaujmout univerzální postoj, tím více zjišťuje, že je to kus od kusu jiné. Má osobní zkušenost je:
1. Open source dává větší prostor pro odhalení chyb, ale oproti closed source je to možnost prakticky neužívaná. Čím složitejší daný program je, tím menší je to výhoda. Audity jsou spíše výjimkou a zvědavých pátračů není dost na to, aby pokryli nějaké významnější procento dostupného SW. Koukněte se třebas ne zdejší středeční seriál "Softwareová sklizeň" a zamyslete se nad tím, kolik z uvedených programů asi někdo třetí zkoumal, zda tam nejsou chyby?
2. Open source a možnost hledat chyby ve zdrojovém kódu je pro koncového uživatele zcela marginální. Pro drtivou většinu z nich je totiž closed source oboje - jedno proto, že k tomu zdrojáky nemají, druhé proto, že ani neví, jak "to" číst.
3. Security by obscurity je důležitý koncept. Má ale své limity a sám o sobě nepředstavuje dostatečnou ochranu. Všechny ty obscurity poučky typu "nevypisuj příliš podrobné chybové hlášky" jsou sice fajn a komplikují práci útočníkovi, ale není radno je přeceňovat. Fakt, že mi webová aplikace sama chybovou hláškou nenabonzuje, že je v ní prostor pro SQL injection, ještě neznamená, že to nezkusím. Obscurity closed source je stejný level - sice nevidím chyby rovnou, ale pořád se k nim můžu testováním dostat. -
Fakt, že mi webová aplikace sama chybovou hláškou nenabonzuje, že je v ní prostor pro SQL injection, ještě neznamená, že to nezkusím. Obscurity closed source je stejný level - sice nevidím chyby rovnou, ale pořád se k nim můžu testováním dostat.
V té úvaze podle mě chybí jedno zamyšlení. To, co popisujete v citovaném textu znamená, že se jedná o cílenou práci nějakého útočníka, který chybu cíleně hledá. Dobře, mějme našeho imaginárního zloducha Karla Hekra, který se rozhodl, že chce provést neplechu.
V případě closed source musí provádět zpětné inženýrství, hledat víceméně náhodně a nemůže si pomoci nahlédnutím do zdroje, aby ověřil některé své teze, které si předsevzal.
V případě open source je postup z počátku podobný. Karel Hekr si vytipuje oblasti, které otestuje. Ale namísto toho, aby se musel zabývat otravným zpětným inženýrstvím, tak svoji myšlenku ověří ve zdrojácích.
Tedy: stejná osoba, stejná motivace, ale u open source je o jednu bariéru méně. Naprosto s Vámi ale souhlasím, že to nemůže být jediná bariéra.
-
. (neregistrovaný)
A teď si představme uživatele Miroslava Líného. Není sice tak schopný jako Karel Hekr, ale na netu se dočetl o nejnovější chybě v procesorech Pintel s odkazem na ukázku jak ukrást hesla z browseru. A tak to zkusí a vloží ten kód do své webové stránky. A zatímco uživatelé Ohnivé liky nebyli kompromitování, protože chyba byla opravena už sedmý den po nahlášení, uživatel prohlížeče Fedž musí čekát ještě 14 dní, než to opraveno bude. A tak mu byly ukradeny všechny hesla.
-
Filip JirsákStříbrný podporovatelPodle mne je chyba v tom, že počítáte jen záměrné hledání chyb, navíc jen bezpečnostních. Já jsem drtivou většinu chyb v softwaru našel tak, že jsem ho prostě používal (ať už aplikaci jako uživatel, nebo knihovnu jako programátor), a narazil jsem na nějakou chybu. Pak to chvíli zkoumám, hledám u sebe, nemůžu chybu najít, až mne napadne, zda nemůže být chyba na druhé straně, tedy v tom softwaru. Ten taky můžu chvilku zkoumat z pozice uživatele. pokud je to closed-source, nezbývá mi, než metodou pokusu a omylu odhalit, kdy se ten blackbox chová jinak, než bych čekal, a takovému použití se vyhnout. Když je to opensource, zkoušení z pozice uživatele mne brzy přestane bavit a podívám se do zdrojáků, co to tam sakra dělá. Někdy zjistím, že jsem nepochopil, jak to mám používat, a po prostudování kódu se naučím to používat správně. A někdy zjistím, že v tom kódu je prostě chyba. Někdy mi také později dojde, že by se dala i zneužít. Když je to navíc takový opensource, do kterého je snadné přispět, tak třeba i rovnou pošlu opravu.
Myslím, že možnost hledat chyby je tedy u open-source i closed-source prakticky stejná. Rozdíl je v možnosti opravy – u opensource můžu chybu opravit a často i opravu zpřístupnit ostatním, u closed-source jí maximálně můžu někam nahlásit, a i to bývá často dost úmorné.
