Hlavní navigace

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

Sdílet

Petr Krčmář 8. 11. 2017

Vývojář společnosti Google, Andrej Konovalov, našel v USB ovladačích linuxového jádra 79 bezpečnostních chyb. Použil při tom techniku zvanou targeted fuzzing, tedy jakési cílené zahlcování ovladačů náhodnými daty pomocí nástroje syzkaller. Celkem 22 chyb už bylo opraveno v jádře 4.13.8, ale většina z nich ještě na svůj patch čeká. Mnoho je toho opraveno v připravovaném jádře 4.14, které vyjde pravděpodobně příští neděli.

Sám Linus Torvalds vyzval lidi, aby touto technikou testovali linuxové jádro a pomohli tak odhalit bezpečnostní chyby v ovladačích. Ty doposud odhalené problémy mohou obvykle způsobit nedostupnost (DoS) rozhraní, ale upravené USB zařízení by mohlo shodit celý systém nebo mít „blíže neurčené dopady“. 

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 8. 11. 2017 15:27

    Boo (neregistrovaný) 85.248.108.---

    Podobne hackli PS3 ne? Posilal se bordel na USB az to prdlo. Pak se z logu vycetla kombinace bajtu co to udelala a to byl uz pocatek hacku.

  • 8. 11. 2017 17:52

    Starous (neregistrovaný) ---.cust.vodafone.cz

    a kde sou vsichni ti chytraci co furt krici ze bezpečnostní chyby jsou jen na windows ?

  • 8. 11. 2017 18:06

    Přezdívka (neregistrovaný) ---.static.grapesc.cz

    Takhle to přece nikdo při smyslech říct nemůže. Zato argumenty v tomto duchu se vyvrací jen stěží.

  • 8. 11. 2017 18:21

    Kate (neregistrovaný) 89.24.51.---

    Podívej se do zrcadla. Jediní koho s tím tvrzením vidím "argumentovat" jsou Windows trollové.

  • 8. 11. 2017 18:31

    Starous (neregistrovaný) ---.cust.vodafone.cz

    jako lehký trolling to bylo myšleno, nicméně mě spíš děsí že všichni hurá používají různé opensource věci a už se nikdo nedivá dovnitř protože přeci opensource je bezpečný.

  • 8. 11. 2017 19:10

    Filip Jirsák

    Nikdo rozumný netvrdí, že opensource je bezpečný, bez jakýchkoli dalších podmínek. Důkazem toho, že se dovnitř někdo dívá, je např. to, o čem je tahle zprávička.

  • 8. 11. 2017 19:31

    Lael Ophir

    Opravdu je to důkazem toho že se někdo dívá dovnitř? Technika fuzzinu pochází doslova z doby děrných štítků a používá se celkem běžně. Její krása je právě v tom, že nemusíte vůbec rozumět kódu. Je to obdoba toho když zkusíte do něčeho bušit kladivem ze všech stran, a koukáte se, jestli něco neupadne :). Představte si že například provádíte syscalls s náhodnými parametry, dokud se kernel nesloží. Pak kouknete co ten kernel položilo, a hledáte důvod. Tam už samozřejmě musíte kód analyzovat, ale stačí projít jenom konkrétní code path.

  • 8. 11. 2017 20:17

    null null (neregistrovaný) ---.freepoint.cz

    Použít k tomu nástroj není zakázané a není to ani podmínka. Tak pro srovnání, kolik lidí to legálně může udělat na Windows?

  • 8. 11. 2017 21:17

    Lael Ophir

    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/

  • 8. 11. 2017 22:43

    null null (neregistrovaný) ---.freepoint.cz

    Souhlas. Ve světě Windows, jak OS, tak doprovodného SW, je zcela běžný otevřený kód a možná legální kontrola kýmkkoliv ... :-D

  • 9. 11. 2017 1:09

    Lael Ophir

    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.

  • 9. 11. 2017 6:53

    L. (neregistrovaný) 91.219.246.---

    > 4. Windows nemají otevřený zdroják, protože by pak uživatelé nemuseli platit...

    Co to je za blbost? Uživatelé by dostali zdroják samozřejmě až po zaplacení.

  • 9. 11. 2017 15:19

    Lael Ophir

    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.

  • 9. 11. 2017 10:59

    Filip Jirsák

    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.

  • 9. 11. 2017 15:23

    Lael Ophir

    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á.

  • 9. 11. 2017 15:33

    Filip Jirsák

    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í.

  • 9. 11. 2017 16:47

    Lael Ophir

    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.

  • 9. 11. 2017 18:18

    Filip Jirsák

    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.

  • 10. 11. 2017 1:27

    Lael Ophir

    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

  • 10. 11. 2017 7:15

    Filip Jirsák

    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.

  • 11. 11. 2017 17:53

    Lael Ophir

    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í.

  • 11. 11. 2017 20:18

    Filip Jirsák

    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ší?

  • 13. 11. 2017 15:12

    Lael Ophir

    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.

  • 13. 11. 2017 17:27

    Filip Jirsák

    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í.

  • 13. 11. 2017 18:14

    Lael Ophir

    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

  • 14. 11. 2017 7:04

    Filip Jirsák

    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.

  • 14. 11. 2017 14:19

    Lael Ophir

    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.

  • 14. 11. 2017 17:44

    Filip Jirsák

    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?

  • 24. 11. 2017 1:08

    Lael Ophir

    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.

  • 26. 11. 2017 10:34

    Filip Jirsák

    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ě.

  • 29. 11. 2017 23:13

    Lael Ophir

    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.

  • 9. 11. 2017 12:39

    null null (neregistrovaný) ---.freepoint.cz

    @Lael Ophir

    MICROSOFT SOFTWARE LICENSE TERMS

    WINDOWS OPERATING SYSTEM

    .... For example, this license does not give you any right to, and you may not:
    ....
    (iv) work around any technical restrictions or limitations in the software;
    ....
    (vi) reverse engineer, decompile, or disassemble the software, or attempt to do so, except and only to the extent that the foregoing restriction is (a) permitted by applicable law; (b) permitted by licensing terms governing the use of open-source components that may be included with the software; or (c) required to debug changes to any libraries licensed under the GNU Lesser General Public License which are included with and linked to by the software; and

  • 9. 11. 2017 14:20

    Martin Dráb

    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.

  • 9. 11. 2017 15:15

    Sten (neregistrovaný) ---.ipv4.broadband.iol.cz

    Podle AZ můžete vnitřnosti zkoumat (pokud to potřebujete pro své použití), ale nesmíte výsledky výzkumu publikovat.

  • 9. 11. 2017 16:26

    null null (neregistrovaný) ---.freepoint.cz

    @Sten

    V poho, může být, ale Lael tu tvrdí že ne, že tam restrikce nejsou, víš ... prolhanec jeden ...

  • 9. 11. 2017 16:43

    Lael Ophir

    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.

  • 9. 11. 2017 19:27

    null null (neregistrovaný) ---.freepoint.cz

    @Lael Ophir

    Nemyslím si, že Windows je autorské dílo a myslím si že nepodléhá autorskému zákonu i když jsi schopný to na to naroubovat. A i kdyby, tak si myslím, že v případě o kterém je řeč, tedy zkoumání a disassemblování .... taky ne, už jenom protože může jít o legální kopii .... Reverse I., Disassemblováním a pod. porušuješ spotřebitelskou smlouvu a ne žádné autorské právo ....

  • 9. 11. 2017 20:23

    Filip Jirsák

    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í.

  • 9. 11. 2017 15:14

    Lael Ophir

    § 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

  • 9. 11. 2017 12:47

    Mlocik97

    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.

  • 9. 11. 2017 15:32

    Lael Ophir

    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.

  • 10. 11. 2017 8:51

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    ". Windows nemají otevřený zdroják, protože by pak uživatelé nemuseli platit, a nebylo by z čeho platit vývoj."

    Hele lulan, a proc M$ dodava Axaptu (o pardon .... Microsoft Dynamics AX) vcetne zdrojaku? Chapu to teda tak, ze prave prohlasujes ze se za to nemusi platit a pokuzivat to muze kdokoli gratis? OK, vyridim zakaznikovi. Beru to jako oficielni vyjadreni zastupce M$.

  • 9. 11. 2017 7:00

    Filip Jirsák

    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.

  • 9. 11. 2017 11:03

    Karel (neregistrovaný) ---.cust.nbox.cz

    To je úhel pohledu. Z jiného úhlu to vypadá, že se do toho celé roky nikdo nepodíval. V managementu platí jednoduché pravidlo: buďte adresní, protože pokud to může udělat kdokoliv, pak to neudělá nikdo. Open source smysl má a je to lepší než closed source. Jediné, co mi vždycky vadilo, je tvrzení stylu "je to bezpečné, protože je to open source a ty zdrojáky čtou stovky lidí". Protože tam není pravda, že by je někdo někdy četl.

    A pokud se podíváte, tak ani tady je nikdo nečetl. Chyby byly nalezeny díky specifickým testům, nikoliv studiem zdrojových kódů. Teprve pak se začalo hledat, proč se to takhle blbě chová a kde je chyba.

  • 9. 11. 2017 12:35

    Mlocik97

    Starous fakt toto je už najretardovanejšia otázka. Protože Linuxáci argumentujú otázkou "a kde sou vsichni ti chytraci co furt krici ze bezpečnostní chyby jsou jen na Linuxu ?" a Windowsáci "a kde sou vsichni ti chytraci co furt krici ze bezpečnostní chyby jsou jen na windows ?" úplná klasika, takže ako teraz kto vyhráva? furt je to iba šarvátka bez logiky, kedže sa odpovede na dané otázky odporujú... v podstate windowsáci sa snažia si zastať windows len "subjektívnymi názormi" a podobne aj Linuxáci to isté... Nijak inak neviete obhájiť svoj OS než útočením "oponentský OS"? Nikto si asi zrejme neuvedomuje že každý SW má chyby, každý OS.. tu neexistuje reálny pojem "bezpečnejší a nebezpečnejší" v subjektívnom pohlade... skuste využiť riadne argumenty, nie len sa snažiť zastáť si "svoj favoritný OS" tým že poviete v článku o chybe "oponentského OS" "a kde sou vsichni ti chytraci co furt krici ze bezpečnostní chyby jsou jen na windows ?" toto isté totiž kecá aj oponent v článku o Vašom favorit OS... fakt, nikam tohle nevede.... Argumenty k hovnu.

  • 8. 11. 2017 19:58

    Vít Šesták

    Je super mít USB stack oddělený do separátního virtuálního stroje, který nemá persistentní stav (po restartu si žádné změny nepamatuje). Aneb QubesOS s troškou tuningu.

  • 9. 11. 2017 19:14

    . . (neregistrovaný) ---.aoj.io

    je to super jen v případě, kdy není možné přes usb napadnout jiný HW, který již máš připojený v jiném qube. Ještě vtipnější je, když se najde zranitelnost v xenu, nedej bože v qemu (ikdyž se snaží ho odstínit ve vlastním stubu), kde jich jsou ještě spousty a poměrně se toho bojím.

    QubesOS je dobrá cesta, ale cíl je podle mě ve výrazném zjednodušení celéhé systému.