Tohle bude nejspíš jen špička ledovce, kde se náhodou povedlo na problém přijít. Přitom když jsem ve zdejší diskusi před časem poukazoval poukazoval na rizika anonymních a/nebo neprověřených přispěvatelů do kódu, tak jsem byl téměř ukamenován, s tím že kód přece vidí mnoho očí, takže se něco takového vlastně nemůže stát.
Celkem by mě zajímalo, jak konkrétně plánuje komunita takovým incidentům zabránit. Můj názor je ten, že pokud a dokud může do kódu přispívat někdo koho nikdo nikdy neviděl a není nijak prověřený, tak se tomu prostě zabránit nedá. Code review to totiž neodchytí, nebo ne vždy. Zvlášť když se píše v jazyce C, u kterého se pořádají soutěže o co nejlepší ukrytí zlovolné funkcionality.
https://www.ioccc.org/
Tedy mají "klasické" vývojové týmy výraznou výhodu. Mají zaměstnance nebo kontraktory, ti jsou jasně identifikovaní (doklady, social security number nebo u nás rodné číslo), mají smlouvu a jasně danou občansko-právní i trestní odpovědnost, a u minimálně u větších firem jsou také prověřeni bezpečnostním oddělením (včetně ověření historie jejich zaměstnání a vzdělání).
Tak mi povězte:
1. Kdo a jak byl ztrestán za propašování DUAL_EC do knihovny bcryptu?
2. Heartbleed, už uběhlo spousta vody, takže dvě zvědavé otázky:
2.1 Jednalo se o chybu, nebo o úmyslný backdoor?
2.2 Kdo a jak byl za to potrestán?
3. Kdo a kdy byl potrestán za jakýkoli jiný remote executable flaw?
4. Chyba ssh-keygen v Debianu, kde private key byl z 64k možných. To samé, omyl či úmysl?
5. Nevšiml jsem si, že digitální podpis pro instalaci ve Windows něco znamená. Prostě se ukradne číkoli identita
BTW všechny příklady výše mají známého autora, a vůbec to nepomohlo.
1. 4. 2024, 02:03 editováno autorem komentáře
K bodu 5: Ve Windows kernel mode i user mode drivery musí podepsat Microsoft, na základě žádosti autora a toho že driver projde procesem WHQL. Samotná žádost o podpis musí být podepsaná pomocí Extended Validation Certificate, a tam jsou poměrně striktní podmínky na jeho vydání. Ukradnout "číkoliv identitu" nepomůže. Svého času například autorům Stuxnetu stačilo "jen" ukrást certifikát výrobce HW. Dnes je je pokud vím i pro podpis "obyčejného" SW potřeba EV certifikát (se všemi s tím spojenými požadavky), a klíč musí být uložený na zařízení certifikovaném podle FIPS 140-2 level 2, Common Criteria EAL 4+ nebo ekvivalentu. Přece jen už není rok 2005 :)
ukrást certifikát výrobce HW stačilo i před půl rokem :) https://msrc.microsoft.com/update-guide/vulnerability/ADV230001, něco se prostě nemění.
Microsoft poměrně nově nedovoluje cross-signing driverů. Developer musí mít EV certifikát, který (pro certifikáty vydané od 1.6.2023) musí být uložen na HW tokenu. S ním driver package podepíše, a s MS partner accountem ho pošle MS, který ho následně podepíše WHQL certifikátem. Je samozřejmě možné, že například někomu leaknul EV certificate a MS partner account, s tím že EV certificate byl vydán před vynucením toho pravidla, že musí být uložen na HW tokenu. Nebo je možné, že MS špatně ověřil driver "dvojího použití", který může používat malware. Nic není stoprocentní, ale cesta k platnému digitálnímu podpisu malwaru je dnes výrazně těžší.
https://techcommunity.microsoft.com/t5/windows-hardware-certification/driver-signing-changes-in-windows-10-version-1607/ba-p/364894