Google našel desítky chyb v linuxových ovladačích USB

Použít generátor samozřejmě není zakázané. Použití nástroje je u fuzzingu nutností jaksi z definice věci, protože jde o automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. Fuzzing se samozřejmě používá i ve světě Windows. Používají ho jak třetí strany, tak MS. MS dokonce nabízí fuzzing jako cloudovou službu :)
https://en.wikipedia.org/wiki/Fuzzing
https://msdn.microsoft.com/en-us/library/cc162782.aspx
https://www.microsoft.com/en-us/security-risk-detection/

1. Fuzzing nevyžaduje zdroják ani disassembler.
2. Nevím o žádných legálních omezeních fuzzingu na Windows.
3. Otevřený kód při hledání zranitelností moc nepomůže. Kdo chyby hledá, čte v debuggeru disassembler lépe než my oba dohromady čteme Cčko.
4. Windows nemají otevřený zdroják, protože by pak uživatelé nemuseli platit, a nebylo by z čeho platit vývoj. Ke zdrojáku mají přístup vlády, univerzity, velcí výrobci HW, a údajně i velcí zákazníci.

To ovšem znamená poskytnout zdrojáky i konkurenci. Jako uživateli je mi to celkem jedno, ale jako autor SW bych zdrojáky nedal. Výjimkou bych byl ochoten udělat pro finančně velmi zajímavého zákazníka, pod striktní NDA. Ale zeptejte se sám, proč třeba IBM neuvolní zdrojáky DB2 a Lotus Domino/Notes, Oracle neuvolní zdrojáky RDBMS, Google neuvolní zdrojáky většiny svého SW atd. Odpověď je zjevná: nechtějí se střelit do nohy, nechtějí přijít o příjmy.

Otevřený kód při hledání zranitelností moc nepomůže. Kdo chyby hledá, čte v debuggeru disassembler lépe než my oba dohromady čteme Cčko.
Už jsem nějaké zranitelnosti opravil, a nikdy to nebylo tak, že bych si v debuggeru četl disassemblovaný kód. Buď jsem na tu chybu přišel při běžném používání aplikace a pak jsem jí dohledal ve zdrojáku, nebo jsem z nějakého důvodu četl zdroják a všiml jsem si, že je tam chyba. Takže otevřený kód pro hledání zranitelností sice není potřeba, ale na druhou stranu se tím výrazně zvyšuje šance, že tu chybu někdo najde. Samozřejmě ale nestačí to, že je zdroják k dispozici, je potřeba, aby ho také někdo reálně četl.

Navíc to, co popisujete, je jen jeden druh chyb, které jsou specifické pro nízkoúrovňové programovací jazyky. Spousta bezpečnostních chyb je na vyšších úrovních a nenajdete je zkoumání disassemblovaného kódu, ale tím, když budete zkoumat architekturu aplikace nebo jejích komponent.

Pokud někdo najde chybu při používání aplikace, je daleko logičtější ji nahlásit na podporu výrobce, než se hrabat ve zdrojáku. A těch chyb nalezených při náhodném pročítání kódu bude, obávám se, povážlivě málo.

Ad to, co popisujete, je jen jeden druh chyb - ano, protože je řeč technice o fuzzingu. Samozřejmě pokud chcete najít chyby, je dobré mít unit testy, provést statickou analýzu kódu, code review, a mimo jiné fuzzing. Dost pomáhá také telemetrie, díky které můžete například zjistit, že vám aplikace u některých zákazníků 5x za den padá.

Pokud někdo najde chybu při používání aplikace, je daleko logičtější ji nahlásit na podporu výrobce, než se hrabat ve zdrojáku.
Ano, pokud chci, aby bylo řešení chyby odloženo, je to nejlogičtější postup. Naopak pokud chci, aby byla opravena, bývá nejlepší varianta poslat popis chyby rovnou i s opravou.

A těch chyb nalezených při náhodném pročítání kódu bude, obávám se, povážlivě málo.
Nepsal jsme o náhodném pročítání kódu. On se kód také průběžně opravuje, upravuje a vylepšuje – a to je podle mne nejčastější způsob nalezení chyby. Což je také důvod, proč je podle mne nereálná představa nevývojářů, že budou dostávat opravy bezpečnostních chyb jako samostatné záplaty. Jenže ve skutečnosti se chyby opravují průběžně tak, jak na ně někdo narazí a zjistí, že je to chyba. Že to byla bezpečnostní chyba si často ani neuvědomí.

Ad pokud chci, aby byla opravena, bývá nejlepší varianta poslat popis chyby rovnou i s opravou - za předpokladu že tu chybu jste schopen najít, což vyžaduje spoustu znalostí a investici poměrně velkého úsilí. Takže zdroják může přinést jistý přínos, ale zcela marginální.

Ad On se kód také průběžně opravuje, upravuje a vylepšuje - jistě, to dělají autoři aplikace, kteří bývají i ve světě open source většinou placení. Komunitních příspěvků bývá pomálu. To že by SW psala nebo vylepšovala neplacené komunita je v naprosté většině případů iluze. Oni lidé neradi pracují zadarmo.

za předpokladu že tu chybu jste schopen najít, což vyžaduje spoustu znalostí a investici poměrně velkého úsilí
Moje zkušenost je taková, že to vyžaduje mnohem méně úsilí, než snažit se dokopat nějakou firmu, aby opravila chybu ve svém uzavřeném produktu.

Takže zdroják může přinést jistý přínos, ale zcela marginální.
Oprava bezpečnostní chyby mi nepřipadá jako marginální přínos.

autoři aplikace, kteří bývají i ve světě open source většinou placení
Máte nějaký zdroj pro tohle své tvrzení? Mně to tak nepřipadá.

To že by SW psala nebo vylepšovala neplacené komunita je v naprosté většině případů iluze. Oni lidé neradi pracují zadarmo.
O tom, jestli lidé neradi pracují zadarmo, by se dalo dlouze polemizovat. Každopádně když udělám nějakou úpravu, málokdy by mělo nějaký přínos, pokud bych si tu úpravu syslil jenom pro sebe. Naopak, když jí vložím zpátky do projektu, nemusím si jí pak pracně udržovat u sebe, postarají se o ní ostatní. Takže neplacené vylepšení od komunity je naopak způsob, jak z práce, kterou už jsme udělal, zadarmo získat ještě něco navíc.

Otevřené zdrojové kódy mají zdaleka největší přínos pro programátory, v tom nejsme ve sporu. Jenže autory všech aplikací jsou – alespoň zatím – právě programátoři.

Ad Moje zkušenost je taková, že to vyžaduje mnohem méně úsilí, než snažit se dokopat nějakou firmu, aby opravila chybu ve svém uzavřeném produktu - Moje zkušenost je naopak taková, že je v každém případě potřeba mít support contract, nejlépe se SLA, a případné bugy ať řeší dodavatel. Neumím si představit držet hromadu programátorů, kteří budou mít nastudovaný kód desítek nebo stovek aplikací, a v případě potřeby mi opraví bug, s tím že garantují zahrnutí opravy do upstreamu.

Ad Oprava bezpečnostní chyby mi nepřipadá jako marginální přínos - pokud k nějaké opravě dojde :). Máte nějaká čísla o počtech bugů, které byly objeveny díky dostupnosti zdrojáků, a které by jinak objevit nešlo?

Ad O tom, jestli lidé neradi pracují zadarmo, by se dalo dlouze polemizovat. - No to by se jistě dalo. Máte na sobě nějaké oblečení? A vyrobili ho lidé placení za práci, nebo pracovali zdarma? Co stůl u kterého sedíte, klávesnice na které píšete? Co dům ve kterém jste? Co vozidlo kterým jste naposledy jel? Kolik z toho vyrobili lidé zdarma, bez osobního zájmu, pro blaho celku? Asi se to bude blížit nule. Akorát u SW by to podle některých lidí mělo fungovat jinak. Jako sorry, ale komunismus nefunguje ani ve světě SW.

Ad autoři aplikace, kteří bývají i ve světě open source většinou placení; Máte nějaký zdroj pro tohle své tvrzení? Mně to tak nepřipadá - ...well over 80 percent of all kernel development is demonstrably done by developers who are being paid for their work
https://www.linux.com/publications/linux-kernel-development-how-fast-it-going-who-doing-it-what-they-are-doing-and-who-5

Ad Otevřené zdrojové kódy mají zdaleka největší přínos pro programátory, v tom nejsme ve sporu. Jenže autory všech aplikací jsou – alespoň zatím – právě programátoři - Jistě, autory aplikací jsou povětšinou programátoři, typicky placení zaměstnavatelem. Jenže těch se zpravidla open source netýká, protože ke svojí aplikaci mají přístup z definice: zaměstnavatel je platí, aby ji psali.

Mimochodem komunitní commity jsou bezpečnostní katastrofa. Koukněte se, jak dlouho zůstávají v open source SW zranitelnost, než je někdo objeví. A ještě je často objeví technikou, které zdroják nevyžaduje: fuzzing těch USB driverů, Shellshock a dva další bugy v bashi objevené fuzzingem atd. Přitom když akceptujete komunitní commity, tak jste nikdy neviděl člověka který je poslal, nevíte jestli vůbec existuje, a nemá žádnou bezpečnostní prověrku. Pánům z NSA, CIA, FSB a SSF stačí několikrát přispět zajímavý kus kódu, aby si udělali trochu jméno, a až budou jejich commity méně kontrolované, tak mohou zanést nenápadnou "chybu". C je tak záludný jazyk, že se dokonce pořádají soutěže v ukrývání skrytého chování v nevinně vypadajícím kódu. Například u vadného random number generátoru v Debianu (CVE-2008-0166) vývojář odstranil jednu nevinně vypadající řádku kódu (na dvou místech), a v důsledku toho byly po dva roky všechny SSL klíče generované na Debianu triviálně cracknutelné. Takovou věc může udělat kdokoliv, s minimálními náklady. Může se na to koukat tisíc očí, ale nejspíš nic neuvidí. Až když to praskne, tak to byla prostě chybka.
http://www.underhanded-c.org/_page_id_2.html
https://www.schneier.com/blog/archives/2008/05/random_number_b.html

Lael Ophit, 1:27: Vidím, že jste se rozhodl důsledně překrucovat to, co píšu. Když programátor opraví chybu, na kterou sám přišel, nepotřebuje na to support, SLA a hromadu programátorů. Když je nějaká taková chyba opravena, neznamená to, že by to bez zdrojáků objevit nešlo. To, že používám věci, ta jejichž výrobu lidé dostali zaplaceno, neznamená, že lidé neradí pracují zadarmo. Linuxové jádro není jediný opensource program.

Pro vaši informaci, dnes se při programování používá spousta knihoven a nástrojů, takže opensource se programátorů týká velice.

Mimochodem komunitní commity jsou bezpečnostní katastrofa. – To je jen vaše ničím nepodložené tvrzení.

Koukněte se, jak dlouho zůstávají v open source SW zranitelnost, než je někdo objeví. – Přibližně stejně dlouho, jako v software s uzavřenými kódy, někdy méně.

Přitom když akceptujete komunitní commity, tak jste nikdy neviděl člověka který je poslal, nevíte jestli vůbec existuje, a nemá žádnou bezpečnostní prověrku. – Někdy jsem ho viděl, ale hlavně ho vidět nepotřebuju. Jestli existuje je mi jedno, důležitý je patch. Bezpečnostní prověrku mít nemusí, stejně jako nemají bezpečnostní prověrku všichni programátoři v softwarových firmách.

Pánům z NSA, CIA, FSB a SSF stačí několikrát přispět zajímavý kus kódu, aby si udělali trochu jméno, a až budou jejich commity méně kontrolované, tak mohou zanést nenápadnou "chybu". – Aha, a tohle vlastně ve firmě vůbec nastat nemůže. No jo, protože tam vlastně toho přispěvatele vidíte, zejména když je z týmu z jiného konce světa, takže špióna z NSA snadno odhalíte, protože má napsáno na čele „Jsem s NSA“.

Může se na to koukat tisíc očí, ale nejspíš nic neuvidí. – Ale uvidí, teda samozřejmě pokud se na to dívá člověk, který té problematice rozumí. To je další výhoda opensource, že ten kód může vzít kdokoli, kdo s ním nemá vůbec nic společného, a nechat udělat audit.

Pokud programátor najde chybu ve svém kódu, tak se jaksi rozumí samo sebou, že má zdroják a že mu rozumí. Pokud má zdroják od nějakého frameworku nebo app serveru, tak je situace daleko horší. Představte si, že máte programátora který vyvíjí řekněme mzdovou agendu nebo registr vozidel. Používá Oracle RDBMS, a má k dispozici i zdrojáky. Pokud se aplikace chová divně, tak tenhle vývojář používající ASP.NET, C#, Javu nebo jiný high level jazyk může samozřejmě začít hrabat do těch pár milionů řádek Cčkového zdrojáku Oracle, a doufat, že se mu podaří problém najít a opravit. Už tohle je dost sci-fi, protože řekněme Java developer, nemluvě o webovém vývojáři, vám toho v Cčku moc neopraví, zvlášť pokud ten kód ani náznakem nezná, a DB používá jen jako klient bez znalosti jejích internals. Pokud nad tím ale stráví tu spoustu času (který samozřejmě platíte) a problém opraví, tak je potřeba výsledek důkladně otestovat a zdokumentovat (tj. platit další čas), protože dost dobře mohlo dojít k nějaké regresi. Pak to můžete použít v produkci - ovšem bez supportu od autorů původního kódu (super nápad, jet v produkci DB bez podpory). Můžete samozřejmě opravu zaslat autorům původního kódu, a ti ji mohou nebo nemusí zahrnout do upstreamu. Dokud ji ale nezahrnou, tak váš kód poběží jen na vaší vlastní verzi Oraclu, která je bez podpory, a nejspíš si ji nebudou instalovat ostatní zákazníci (v případě té mzdové agendy to znamená, že ji bude fungovat jen vývojáři na jeho systému). A pokud ji nakonec nezahrnou, tak vám každá nová verze Oracle vaše změny přebuší, a proto musíte svůj fork udržovat, testovat, a sám si ho podporovat, což je finančně už úplně mimo. Už je jasnější, proč je přínos zdrojáku velmi diskutabilní?

Ad Mimochodem komunitní commity jsou bezpečnostní katastrofa. – To je jen vaše ničím nepodložené tvrzení. - Opravdu to riziko nevidíte? I když máte zaměstnance v týmu na druhém konci světa, tak víte že ten člověk existuje, protože ho někdo přijal, někdo ho řídí, sedí v nějaké kanceláři, někdo ověřoval jeho identitu, to do které chodil školy a kde pracoval, někdo provádí revizi kódu, a ve větších firmách bezpečáci udělají background check. Když zaměstnanec záměrně poškodí firmu, je možné vyvodit trestní odpovědnost. Naopak u open source projektu nevíte jestli ten člověk vůbec existuje, žádná bezpečnostní prověrka neexistuje, trestní ani jiná odpovědnost autora kódu není fakticky vymahatelná, a revize kódu je v lepším případě laxní, zvlášť pokud ten člověk na projektu už nějakou dobu působí. Takže z celého řetězce věcí, které mají zabránit bezpečnostnímu incidentu, vám zbývá pouze laxní revize kódu. To že Cčko je záludné, a spousta věcí se dá v kódu ukrýt, asi ani vy zpochybňovat nebudete. Na místě třípísmenkových agentur bych vytvořil minimálně stovky takových virtuálních vývojářů. Nakonec rozpočet na to mají:
http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html?_r=0

Ad uvidí, teda samozřejmě pokud se na to dívá člověk, který té problematice rozumí; výhoda opensource, že ten kód může vzít kdokoli, kdo s ním nemá vůbec nic společného, a nechat udělat audit - Pokud se na ty milionu řádek zdrojáku opravdu cíleně zaměří odborník, který dělá bezpečnostní audity. Ale ten to asi nebude dělat zdarma. A když máte dostatek peněz, tak se dá provést audit čehokoliv, včetně MS aplikací.

Už je jasnější, proč je přínos zdrojáku velmi diskutabilní?
Nenapsal jste nic, co by ukazovalo, že přínos zdrojáku je velmi diskutabilní. Zatím jste dokázal akorát to, že zdrojáky nemusí být přínosné vždy, což ale nikdo netvrdil.

Ad bezpečnostní katastrofa komunitních commitů – není důležité, kdo commit poslal, ale co je v tom commitu. Moje zkušenost je taková, že kvalitnější kód je spíš v opensource – ta motivace, že ten kód může vidět každý, funguje. Když se nějaký kód zveřejňoval (Interbase, OpenJDK), upravoval se, aby se mohl zveřejnit.

Ad audit zdrojáků – audit opensource můžete udělat, i když nemáte tolik prachů. Takže jaký kód asi bude auditovanější?

Ad Nenapsal jste nic, co by ukazovalo, že přínos zdrojáku je velmi diskutabilní - Přínos zdrojáků je velmi diskutabilní. Většinou z popsaných důvodů nic nepřinese. Určitě může někdy i něco málo přinést. Největší problém je ovšem v businessu. Když dá autor z ruky zdroják, s vysokou pravděpodobností to dramaticky sníží jeho tržby. Proto Google nedává k dispozici zdrojáky ze kterých má business, proto Oracle nedá zdrojáky RDBMS, proto IBM nedá zdrojáky DB2, IBM Domino a Notes.

Ad není důležité, kdo commit poslal, ale co je v tom commitu - Jak jsem psal, Cčko je záludný jazyk, ve kterém se dá spousta věcí ukrýt, a důsledná kontrola commitů je velmi obtížná. Důkazem budiž to, že kontrolou commitů zcela prokazatelně procházejí velké spousty bugů a zranitelností. Když se nezabýváte důvěryhodností ani dohledatelností osob, které za kódem stojí, tak se celkem zjevně řítíte do problému.

Ad Když se nějaký kód zveřejňoval (Interbase, OpenJDK), upravoval se, aby se mohl zveřejnit. - To asi ano. Je potřeba minimálně odstranit komentáře obsahující nadávky :), jména zákazníků a konkurentů, přidat header comments atd.

Ad audit opensource můžete udělat, i když nemáte tolik prachů. Takže jaký kód asi bude auditovanější? - Ve světě open source je peněz výrazně méně, takže se asi moc neaudituje. Naopak velké SW firmy mají code review a interní audity jako běžnou součást vývojového procesu. Ale to jsou všechno dohady a ne tvrdá čísla. Pokud máte nějaká kvalitní data, rád se na ně podívám.

Pokud je v té komerci tolik prachů a tak se tam všechno kontroluje, je zvláštní, že tomu neodpovídají výsledky – místo toho je komerční software úplně stejně zabugovaný, jako opensource, jednou je kvalitnější ten, podruhé ten druhý. A taky je trochu záhadou, že komerční firmy klidně používají ten neauditovaný opensource software a staví na něm svá řešení.

Ad je zvláštní, že tomu neodpovídají výsledky - Namátkou: IIS celkově 21 vulnerabilities, Apache Http Server 205. ASP.NET 10 vulnerabilities, PHP 560. MS SQL Server 84 vulnerabilities, MySQL (což je proti MS SQL hračka pro děti) 244. Adobe Photoshop 10 vulnerabilities, Gimp (což je proti Photoshopu hračka pro batolata) 16.
Pokud jde o kvalitu, tak tam je otázka jak ji chcete měřit. Open source je zřídka na špičce ohledně funkcionality a UI, což je vidět třeba na Gimpu a Photoshopu, MS Office a LibreOffice apod.

Ad taky je trochu záhadou, že komerční firmy klidně používají ten neauditovaný opensource software a staví na něm svá řešení - berou to jako freeware

Nějak jste se v tom srovnávání kvality zasekl. Vždyť jste předtím jmenoval dvojice IIS – httpd, ASP.NET × PHP, MS SQL × MySQL. A když tak rád porovnáváte počty něčeho, porovnejte to třeba počtem instalací. A pokud by se vám náhodou nechtělo porovnávat MS SQL s MySQL, vzpomeňte si, že porovnáváte software podle počtu chyb zaznamenaných v nějaké databázi třetí strany.

Ad berou to jako freeware – to jako znamená, že když něco budu brát jako freeware, samy se v tom opraví chyby a provede se audit? Nebo jak tohle vaše tvrzení mám chápat? Pokud někdo ve svém projektu použije opensource software, přebírá tím veškeré jeho bezpečnostní díry a chyby.

Jde o seznam nahlášených zranitelností, který by měl být vyčerpávající. Počet instalací je u všech těch produktů velmi vysoký. Ta čísla prostě nesedí s tím, že by open source byl nějak kvalitnější nebo bezpečnější. Až na pár výjimek jde o druhořadé produkty, které toho umí méně než špičkové komerční produkty, ale mají větší počet odhalených zranitelností.

Ad Pokud někdo ve svém projektu použije opensource software, přebírá tím veškeré jeho bezpečnostní díry a chyby - Souhlas. Není každá společnost jako Google se svým silným vývojovým týmen, který opečovává ta open source tamagochi. Nehledě na rizika nákazy GPL licencí, nedostatečnou dokumentaci atd.

Jde o seznam nahlášených zranitelností, který by měl být vyčerpávající.
Když je ten seznam vyčerpávající, a kód komerčních produktů prochází interním code review a externími audity, jistě nebude problém v tom seznamu odkázat ty zranitelnosti nalezené při interním review a při auditech. Zároveň tím získáme představu o podílu jednotlivých způsobů odhalení chyb – na kolik chyb přijdou externisté náhodou nebo zkoumáním na vlastní pěst, jaký podíl dělají ty odhalené interními mechanismy a kolik je těch nalezených pomocí externích placených auditů.

Ta čísla prostě nesedí s tím, že by open source byl nějak kvalitnější nebo bezpečnější.
Ona ta čísla nesedí s ničím jiným, než s počtem do seznamu nahlášených zranitelností.

Až na pár výjimek jde o druhořadé produkty, které toho umí méně než špičkové komerční produkty
Myslíte třeba ISS a Apache nebo nginx?

mají větší počet odhalených zranitelností
Mají větší počet nahlášených zranitelností. Přičemž nás zajímá počet neopravených zranitelností.

Není každá společnost jako Google se svým silným vývojovým týmen, který opečovává ta open source tamagochi.
Nebo Microsoft… Akorát jste pořád nevysvětlil ten zázrak, jak je možné, že se ten děravý a nedokumentovaný OSS okamžikem, kdy se ho rozhodne použít nějaká komerční firma, aniž by se změnila jediná řádka kódu, stane kvalitním zdokumentovaným software s minimem bezpečnostních chyb. Taky je otázka, proč ty firmy ten software vůbec používání, proč si podle svých vysokých standardů nenapíší vlastní.

nedostatečnou dokumentaci
V případě OSS, když nemáte dostatečnou dokumentaci, pořád máte alespoň ten zdroják. A že by komerční software implikoval dostatečnou dokumentaci… Nebyla tu náhodou řeč o produktech Microsoftu?

Ad jistě nebude problém v tom seznamu odkázat ty zranitelnosti nalezené při interním review a při auditech - U zranitelností je trochu problém systematicky vyhodnotit jejich objevitele. Dá se snadno zjistit že CVE-2017-8654 objevil Microsoft Office Security Team a CVE-2017-8589 Microsoft, ale nevidím tuhle informaci nikde agregovanou, natož aby se agregovalo jakým způsobem firma na zranitelnost svého produktu přišla.

Ad Myslíte třeba ISS a Apache nebo nginx - Nejsem přesvědčený, že by Apache nebo nginx byl lepší než IIS. Zato LibreOffice je horší než MS Office. Vždyť je to neúspěšný komerční produkt, který komunita spíš udržuje než rozvíjí. Gimp mnohem horší než Adobe Photoshop, a to zřejmě protože jde o "čistokrevný" open source bez komerčního (byť třeba zkrachovalého) základu.

Ad Mají větší počet nahlášených zranitelností. Přičemž nás zajímá počet neopravených zranitelností. - Za mě celkem jasně: horší kvalita vede k většímu množství defektů, ceteris paribus. V téhle metrice Linux a open source obecně dost propadá. Důležitá je spousta věcí, včetně počtu neopravených zranitelností, doby po kterou jsou zranitelnosti neopravené, typu zranitelností, počtu zranitelností které budou objeveny příští rok atd. Každopádně nemá smysl měnit téma. Kdyby byl open source nějak v principu kvalitnější, tak by neměl kernel Linuxu coby malý kus open source kódu více zranitelností než celé closed source Windows 10.

Ad jak je možné, že se ten děravý a nedokumentovaný OSS okamžikem, kdy se ho rozhodne použít nějaká komerční firma, aniž by se změnila jediná řádka kódu, stane kvalitním zdokumentovaným software s minimem bezpečnostních chyb - Jednoduše: nestane se jím.

Ad proč ty firmy ten software vůbec používání, proč si podle svých vysokých standardů nenapíší vlastní - Firmy hodnotí cenu SW, další náklady na něj, jeho přínos, a rizika spojená s jeho používáním. Na mém počítači se také najde pár kusů open source SW, který prostě považuji za freeware, a hodnotím to tak, že užívání daného SW nepředstavuje riziko.

Problém je v tom, že jste stále nepochopil, že počet přiřazených CVE nevypovídá vůbec nic o zranitelnosti daného softwaru. CVE je prostě číslo, o které někdo požádal a někdo ho přiřadil – nevypovídá nic ani o závažnosti problému, ani o době, kdy je zranitelnost známá a neopravená, ani o době, kdy zranitelnost existovala, ani o počtu instalací, které jsou zranitelností postižené. Navíc porovnáváte dvě nesouměřitelné věci – Windows na rozdíl od Linuxového jádra obsahují i GUI, na druhou stranu Linuxové jádro obsahuje i ovladače hardware, pro Windows je ale dodávají výrobci samostatně.

CVE vypovídá o tom, že byla objevena zranitelnost.

Windows na rozdíl od linuxového jádra, které implementuje jen pár set syscalls, obsahují velmi rozsáhlé API, GUI, dialogy, lokalizaci atd. Dodávají i se spoustou driverů, i když některé drivery nejsou součástí dodávky. Jádro Linuxu sice obsahuje drivery (mimochodem to je na prvním místě špatná volba autorů), ale zdaleka ne všechny, a další dodávají opět výrobci HW.

Ještě se mrkněte do našeho AZ, zda toto ustanovení je vůbec (v našich končinách) platné. Něco o zkoumání vnitřností tam řečeno je, jen teď nevím, zda to lze licencí/dohodou zakázat (některé věci nejdou). Teď bohužel nemám čas to hledat.

To se týká §66 odst. 1 písm. b). Podle písm. a) až d) můžete zjišťovat podle libosti, a publikovat co uznáte za vhodné, pokud nepublikujete samotný kód zkoumaného programu v rozsahu větším než je citace.

Nemyslím si, že Windows je autorské dílo a myslím si že nepodléhá autorskému zákonu
Teda fakt jsem si nemyslel, že někdo překoná Jéčko. Ale tohle je teda fakt majstrštyk.

Software samozřejmě je autorské dílo. Autorské dílo definuje § 2 autorského zákona, jehož druhý odstavec začíná větou: „Za dílo se považuje též počítačový program, fotografie a výtvor vyjádřený postupem podobným fotografii, které jsou původní v tom smyslu, že jsou autorovým vlastním duševním výtvorem.“

Jinak pro to debugování a disassemblování je z § 66 odst. 1 důležité především písmeno d) a případně e):

(1) Do práva autorského nezasahuje oprávněný uživatel rozmnoženiny počítačového programu, jestliže
[…]
d) zkoumá, studuje nebo zkouší sám nebo jím pověřená osoba funkčnost počítačového programu za účelem zjištění myšlenek a principů, na nichž je založen kterýkoli prvek počítačového programu, činí-li tak při takovém zavedení, uložení počítačového programu do paměti počítače nebo při jeho zobrazení, provozu či přenosu, k němuž je oprávněn,
e) rozmnožuje kód nebo překládá jeho formu při rozmnožování počítačového programu nebo při jeho překladu či jiném zpracování, úpravě či jiné změně, je-li k ní oprávněn, a to samostatně nebo prostřednictvím jím pověřené osoby, jsou-li takové rozmnožování nebo překlad nezbytné k získání informací potřebných k dosažení vzájemného funkčního propojení nezávisle vytvořeného počítačového programu s jinými počítačovými programy, jestliže informace potřebné k dosažení vzájemného funkčního propojení nejsou pro takové osoby dříve jinak snadno a rychle dostupné a tato činnost se omezuje na ty části počítačového programu, které jsou potřebné k dosažení vzájemného funkčního propojení.

§ 66 AZ: (1) Do práva autorského nezasahuje oprávněný uživatel rozmnoženiny počítačového programu, jestliže a) rozmnožuje, překládá, zpracovává, upravuje či jinak mění počítačový program, je-li to nezbytné k využití oprávněně nabyté rozmnoženiny počítačového programu, činí-li tak při zavedení a provozu počítačového programu nebo opravuje-li chyby počítačového programu
A dále zbytek §66

Lael k tvojmu "3." bych povedal iba tolik že ti to môže pomôcť nájsť určitý typ chýb, ale nie chybu ako "chcel som uvariť zeleninovú polievku, ale nechcene som uvaril paradajkovú polievku" ehm, a teraz mi povedz, ochutnávač kde spozná chybu (ak polievka bude chutná, jedlá, akoby normálna), a nemal informáciu že čo chcel kuchár uvariť, dá tomu hodnotenie "0"? nie, dá "10" ak mu kuchár sám nezdelí že chcel urobiť inú polievku "ochutnávač" to neoznačí za "chybu"....

resp. ak máš napr. v JS kód že po ak si na stránke preskrolloval viac ako "100px" aby sobrazil na lavo tlačítko "scrollUP", a ty spravíš chybu a napíšeš menej ako 100px. Tak ti debugger ti nezjistí chybu. Aj keď výsledkom bude že tlačítko sa bude zobrazovať ak je stránka naskrolovaná hore, a nie dole.

Sú chyby ktoré nespôsobia nefunkčnosť, ale spôsobia "inú funkčnosť", a aj "iná funkčnosť" môže byť bezpečnostnou chybou. Pak ti debugger môže byť k hovnu.

To co popisujete je úloha na model checking. Máte nějaké specifikované vlastnosti, a chcete ověřit, jestli je výsledný kus kódu splňuje. Pokud to nejste schopný ověřit automatizovaně, tak to holt musíte otestovat ručně. K nalezení defektu pak zdroják nepotřebujete (s bug reportem klidně může přijít uživatel), potřebujete ho jen k opravě.

Jak jsem už psal, osobně jako uživatel nemám problém, když k SW dostanu zdroják. K ničemu mi není, protože nebudu studovat MB textu a hledat v něm chyby, ale také mi nevadí, když ho dostanu :). Komu to vadí jsou autoři aplikací, kteří uvolněním zdrojáku přicházejí o peníze.

Opravdu je to důkazem toho že se někdo dívá dovnitř?
Ano, je. Ono totiž nejde jenom o target fuzzing, ale také o to, že některé chyby jsou už opravené a další budou v příští verzi. K opravě té chyby už kódu rozumět musíte.