Kontrolní seznam zabezpečení ovladačů
Tento článek poskytuje kontrolní seznam zabezpečení ovladačů pro vývojáře ovladačů, který pomáhá snížit riziko ohrožení ovladačů.
Přehled zabezpečení ovladačů
Chyba zabezpečení je jakákoli chyba, která útočníkovi umožňuje způsobit selhání ovladače takovým způsobem, že způsobí chybové ukončení systému nebo se stane nepoužitelným. Kromě toho chyby zabezpečení v kódu ovladače můžou útočníkovi umožnit získat přístup k jádru, což může ohrozit celý operační systém. Když většina vývojářů pracuje na ovladači, zaměřuje se na to, aby ovladač fungoval správně, a ne na tom, jestli se útočník se zlými úmysly pokusí zneužít chyby zabezpečení v kódu.
Po uvolnění ovladače se ale útočníci mohou pokusit testovat a identifikovat chyby zabezpečení. Vývojáři musí tyto problémy zvážit během fáze návrhu a implementace, aby se minimalizovala pravděpodobnost takových ohrožení zabezpečení. Cílem je eliminovat všechny známé chyby zabezpečení před vydáním ovladače.
Vytváření bezpečnějších ovladačů vyžaduje spolupráci systémového architekta (vědomě uvažujícího o potenciálních hrozbách pro ovladače), vývojáře implementujícího kód (defenzivním způsobem programujícího běžné operace, které mohou být zdrojem zneužití) a testovacího týmu (proaktivně se snažícího nalézt slabiny a zranitelnosti). Díky řádné koordinaci všech těchto činností je zabezpečení řidiče výrazně posíleno.
Kromě toho, aby nedocházelo k problémům spojeným s útokem ovladače, mnoho kroků popsaných, například přesnější použití paměti jádra, zvýší spolehlivost ovladače. Tím se sníží náklady na podporu a zvýší se spokojenost zákazníků s vaším produktem. Dokončení úkolů v následujícím kontrolním seznamu vám pomůže dosáhnout všech těchto cílů.
kontrolní seznam zabezpečení :Dokončení úlohy zabezpečení popsané v každém z těchto témat.
Potvrďte, že je vyžadován ovladač jádra
Přístup lze řídit pouze k softwarovým ovladačům
Nepodepisovat kód testovacího ovladače pro produkční účely
Postupujte podle pokynů pro bezpečné kódování ovladačů
Implementujte kompatibilní kód HVCI
Dodržovat osvědčené postupy pro technologické kódy
provedení kontroly partnerského kódu
Správa řízení přístupu k ovladačům
Zlepšit zabezpečení instalace zařízení
Provést správné podepisování ovladačů pro vydání
Použijte CodeQL ke kontrole kódu ovladače
přidejte poznámky SAL do kódu ovladače
Pomocí nástroje Driver Verifier zkontrolujte zranitelnosti
Zkontroluj kód binárním analyzátorem BinSkim
Ověření kódu pomocí testů programu kompatibility hardwaru
Jak se ovladače hlásí pomocí Centra pro generování sestav ohrožených a škodlivých ovladačů Microsoft
Projděte si zabezpečené prostředky kódování
Recenze: Přehled klíčových poznatků
Ověřte, že je vyžadován ovladač jádra.
položku kontrolního seznamu zabezpečení č. 1:Ověřte, že je požadován ovladač jádra a že přístup s nižším rizikem, například služba nebo aplikace pro Windows, není lepší volbou.
Ovladače běží v jádru Windows a pokud dojde k problému při jejich spuštění, ohrozí bezpečnost celého operačního systému. Pokud je k dispozici nějaká jiná možnost, bude pravděpodobně nižší náklady a bude mít menší riziko než vytvoření nového ovladače jádra. Další informace o používání integrovaných ovladačů systému Windows najdete v tématu Potřebujete napsat ovladač?.
Informace o používání úloh na pozadí najdete v tématu Podpora aplikace pomocí úloh na pozadí.
Informace o používání služeb systému Windows naleznete v tématu Services.
Použijte frameworky ovladačů
položku kontrolního seznamu zabezpečení č. 2:Pomocí architektur ovladačů zmenšete velikost kódu a zvyšte jeho spolehlivost a zabezpečení.
Pomocí rozhraní Windows Driver Frameworks snižte velikost kódu a zvyšte jeho spolehlivost a zabezpečení. Pokud chcete začít, projděte si „Použití WDF k vývoji ovladače“ . Informace o použití ovladače uživatelského režimu s nižším rizikem (UMDF) najdete v tématu Volba modelu ovladače.
Psaní staré módy Modelu ovladačů systému Windows (WDM) ovladač je časově náročné, nákladné a téměř vždy zahrnuje opětovné vytvoření kódu, který je k dispozici v architekturách ovladačů.
Zdrojový kód rozhraní Windows Driver Framework je opensourcový a dostupný na GitHubu. Jedná se o stejný zdrojový kód, ze kterého se sestavuje knihovna modulu runtime WDF, která se dodává ve Windows 10. Ovladač můžete ladit efektivněji, když můžete sledovat interakce mezi ovladačem a WDF. Stáhněte to z https://github.com/Microsoft/Windows-Driver-Frameworks.
Řízení přístupu k pouze softwarovým ovladačům
položku kontrolního seznamu zabezpečení č. 3:Pokud bude vytvořen ovladač pouze pro software, musí být implementováno další řízení přístupu.
Pouze softwarové ovladače jádra nepoužívají plug-and-play (PnP) k přidružení ke konkrétním hardwarovým ID, a proto mohou běžet na jakémkoli počítači. Takový ovladač by mohl být použit pro jiné účely, než k jakým byl původně zamýšlen, což by mohlo vytvořit vektor útoku.
Vzhledem k tomu, že softwarové ovladače jádra obsahují další riziko, musí být omezené na spuštění na konkrétním hardwaru (například pomocí jedinečného ID PnP, aby bylo možné povolit vytvoření ovladače PnP, nebo kontrolou přítomnosti konkrétního hardwaru v tabulce SMBIOS).
Představte si například, že OEM Fabrikam chce distribuovat ovladač, který umožňuje přetaktovací nástroj pro své systémy. Pokud by tento softwarový ovladač byl spuštěn v systému z jiného OEM, může dojít k nestabilitě systému nebo poškození. Systémy společnosti Fabrikam by měly obsahovat jedinečné ID PnP, aby bylo možné vytvořit ovladač PnP, který je také aktualizovatelný prostřednictvím služby Windows Update. Pokud to není možné a společnost Fabrikam vytvoří starší verzi ovladače, měl by tento ovladač najít jinou metodu pro ověření, že se provádí v systému Fabrikam (například prozkoumáním tabulky SMBIOS před povolením jakýchkoli funkcí).
Nepodepisujte testovací kód jako produkční
Položka kontrolního seznamu zabezpečení č. 4:Nepodepisujte vývojový, testovací a výrobní kód ovladače jádra jako produkční.
Kód ovladače jádra, který se používá pro vývoj, testování nebo výrobu, může zahrnovat nebezpečné funkce, které představují bezpečnostní riziko. Tento nebezpečný kód by nikdy neměl být podepsaný certifikátem, který je důvěryhodný systémem Windows. Správným mechanismem pro spuštění nebezpečného kódu ovladače je zakázání zabezpečeného spouštění UEFI, povolení BCD TESTSIGNING a podepsání vývojového, testovacího a výrobního kódu pomocí nedůvěryhodného certifikátu (například jednoho vygenerovaného makecert.exe).
Kód podepsaný důvěryhodným certifikátem vydavatelů softwaru (SPC) nebo podpisem WHQL (Hardware Quality Labs) systému Windows nesmí usnadnit obejití integrity kódu a technologií zabezpečení systému Windows. Než bude kód podepsán důvěryhodným podpisem SPC nebo certifikátem WHQL, nejprve se ujistěte, že splňuje pokyny z Vytváření spolehlivých ovladačů Kernel-Mode. Kromě toho nesmí kód obsahovat žádné nebezpečné chování, které je popsáno níže. Další informace o podepisování ovladačů najdete v tématu Vydání podepisování ovladačů dále v tomto článku.
Mezi příklady nebezpečného chování patří:
- Poskytuje možnost mapování libovolného jádra, fyzické paměti nebo paměti zařízení na uživatelský režim.
- Poskytuje možnost čtení nebo zápisu libovolného jádra, fyzické paměti nebo paměti zařízení, včetně vstupu a výstupu portu (vstupně-výstupní operace).
- Poskytnutí přístupu k úložišti, které obchází řízení přístupu systému Windows.
- Poskytuje možnost upravovat hardware nebo firmware, který ovladač nebyl navržen pro správu.
Provedení analýzy hrozeb
položku kontrolního seznamu zabezpečení č. 5:buď upravit existující model hrozeb ovladače, nebo vytvořit vlastní model hrozeb pro váš ovladač.
Při zvažování zabezpečení je běžnou metodikou vytvoření konkrétních modelů hrozeb, které se pokoušejí popsat typy útoků, které jsou možné. Tato technika je užitečná při návrhu ovladače, protože vynutí vývojáře, aby zvážil potenciální vektory útoku proti ovladači předem. Po identifikaci potenciálních hrozeb může vývojář ovladače zvážit způsoby, jak se proti těmto hrozbám bránit, aby podpořil celkové zabezpečení komponentu ovladače.
Tento článek obsahuje pokyny specifické pro ovladače pro vytvoření jednoduchého modelu hrozeb: modelování hrozeb pro ovladače. Tento článek obsahuje příklad diagramu modelu hrozeb ovladače, který lze použít jako výchozí bod pro váš ovladač.
Osvědčené postupy a související nástroje pro životní cyklus vývoje zabezpečení (SDL) můžou využívat IHV a OEM ke zlepšení zabezpečení svých produktů. Další informace viz doporučení SDL pro OEM.
Postupujte podle pokynů pro zabezpečené kódování ovladačů.
položku kontrolního seznamu zabezpečení č. 6:Zkontrolujte kód a odeberte všechna známá ohrožení zabezpečení kódu.
Základní aktivitou vytváření zabezpečených ovladačů je identifikace oblastí v kódu, které je potřeba změnit, aby se zabránilo známým ohrožením zabezpečení softwaru. Mnohé z těchto známých zranitelností softwaru se zabývají přísným sledováním využití paměti, aby nedocházelo k problémům s přepisem nebo jiným narušením umístění paměti, které váš ovladač používá.
Nástroje pro kontrolu kódu, jako jsou CodeQL a testy specifické pro ovladače, se dají použít k vyhledání některých, ale ne všech těchto ohrožení zabezpečení. Tyto nástroje a testy jsou popsány dále v tomto tématu.
Vyrovnávací paměti
Vždy zkontrolujte velikosti vstupních a výstupních vyrovnávacích pamětí a ujistěte se, že vyrovnávací paměti mohou obsahovat všechna požadovaná data. Další informace naleznete v tématu Selhání kontroly velikosti vyrovnávacích pamětí.
Před vrácením volajícímu správně inicializovat všechny výstupní vyrovnávací paměti nulami. Další informace naleznete v tématu Selhání inicializace výstupních vyrovnávacích pamětí.
Ověřte vyrovnávací paměti s proměnlivou délkou. Další informace naleznete v tématu Selhání ověření vyrovnávací paměti Variable-Length. Další informace o práci s vyrovnávacími paměťmi a použití ProbeForRead a ProbeForWrite k ověření adresy vyrovnávací paměti naleznete v tématu zpracování vyrovnávací paměti.
Použijte odpovídající metodu pro přístup k vyrovnávacím pamětem dat IOCTL.
Jednou z hlavních zodpovědností ovladače systému Windows je přenos dat mezi aplikacemi v uživatelském režimu a zařízeními systému. Tři metody přístupu k vyrovnávacím pamětím dat jsou uvedeny v následující tabulce.
| Typ vyrovnávací paměti IOCTL | Shrnutí | Další informace |
|---|---|---|
| METHOD_BUFFERED | Doporučeno pro většinu situtací | Použití vyrovnávacího I/O |
| METHOD_IN_DIRECT nebo METHOD_OUT_DIRECT | Používá se v některých vysokorychlostních hardwarových vstupně-výstupních operacích | Používání přímých vstupů a výstupů |
| METHOD_NEITHER | Pokud je to možné, vyhněte se | použití žádné vyrovnávací paměti ani přímé vstupně-výstupní |
Obecně se doporučují procesy pufrovaného I/O, protože poskytují nejspolehlivější metody pufrování. I když ale používáte vstupně-výstupní operace ve vyrovnávací paměti, existují rizika, jako jsou vložené ukazatele, které je potřeba zmírnit.
Další informace o práci s vyrovnávacími paměťmi v sítích IOCTLs naleznete v tématu Metody pro přístup k vyrovnávacím pamětím dat.
Chyby při použití vyrovnávaných vstupně-výstupních operací IOCTL
Zkontrolujte velikost vyrovnávacích pamětí souvisejících s protokolem IOCTL. Další informace naleznete v tématu Selhání kontroly velikosti vyrovnávacích pamětí.
Správně inicializovat výstupní vyrovnávací paměti. Další informace naleznete v tématu Selhání inicializace výstupních vyrovnávacích pamětí.
Správně ověřte proměnlivě dlouhé paměťové bloky. Další informace naleznete v tématu Neúspěšné ověření bufferů Variable-Length a.
Při použití vstupně-výstupních operací s vyrovnávací pamětí nezapomeňte v poli Informace ve struktuře IO_STATUS_BLOCK vrátit správnou délku pro výstupní vyrovnávací paměť. Nevrácejte přímo délku přímo z požadavku READ. Představte si například situaci, kdy vrácená data z uživatelského prostoru značí, že je k dispozici vyrovnávací paměť 4K. Pokud by ovladač skutečně měl vrátit pouze 200 bajtů, ale místo toho pouze vrátí hodnotu 4K v poli Informace, došlo k ohrožení zabezpečení spočívající ve zpřístupnění informací. K tomuto problému dochází, protože v dřívějších verzích systému Windows vyrovnávací paměť, kterou V/V manažer používá pro Buffered I/O, není vynulována. Aplikace uživatele tak získá zpět původní 200 bajtů dat plus 4K-200 bajtů jakéhokoliv obsahu ve vyrovnávací paměti (obsah fondu bez stránkování). K tomuto scénáři může dojít u všech použití vyrovnávací paměti a nejen u IOCTLs.
Chyby v přímých vstupně-výstupních operacích IOCTL
Správně zpracujte vyrovnávací paměť nulové délky. Další informace naleznete v tématu
Chyby při odkazování na adresy uživatelského prostoru
Ověřte ukazatele zabudované ve vyrovnávací paměti vstupně-výstupních požadavků. Další informace naleznete v tématu Chyby v odkazování na User-Space adresy.
Před pokusem o jeho použití ověřte libovolnou adresu v uživatelském prostoru pomocí rozhraní API, jako jsou ProbeForRead a ProbeForWrite, pokud je to vhodné.
Registr specifický pro model MSR pro čtení a zápisy
Vnitřní objekty kompilátoru, jako jsou __readmsr a __writemsr, lze použít pro přístup k registrům specifickým pro model. Pokud je tento přístup povinný, musí ovladač vždy zkontrolovat, jestli je registr pro čtení nebo zápis omezený na očekávaný index nebo rozsah.
Další informace a příklady kódu najdete v dokumentu Poskytování možnosti čtení a zápisu MSRs v Nejlepší bezpečnostní postupy vývoje pro vývojáře ovladačů systému Windows.
Ohrožení zabezpečení TOCTOU
Při použití přímých operací I/O (pro IOCTLs nebo pro čtení a zápis) existuje potenciální zranitelnost typu kontrola-čas-použití (TOCTOU). Mějte na paměti, že ovladač přistupuje k vyrovnávací paměti dat uživatele a uživatel k ní může současně přistupovat.
Pokud chcete toto riziko spravovat, zkopírujte všechny parametry, které je potřeba ověřit z vyrovnávací paměti uživatelských dat, do paměti, která je přístupná výhradně z režimu jádra (například zásobníku nebo fondu). Pak, jakmile uživatelská aplikace nebude mít přístup k datům, ověřte je a pak dále zpracovávejte data, která byla předána.
Kód ovladače musí správně používat paměť.
Všechny přidělení fondu ovladačů musí být ve fondu nespustitelných souborů (NX). Použití fondů paměti NX je ze své podstaty bezpečnější než použití spustitelných nestránkovaných fondů (NP) a poskytuje lepší ochranu před útoky přetečením.
Ovladače zařízení musí správně zpracovávat různé uživatelské režimy a také požadavky jádra na vstupně-výstupní operace jádra.
Aby ovladače podporovaly virtualizaci HVCI, existují další požadavky na paměť. Další informace najdete v tématu Implementace kompatibilního kódu HVCI dále v tomto článku.
Ovládá
- Ověřte předávání popisovačů mezi uživatelským režimem a pamětí v režimu jádra. Další informace naleznete v tématu Správa popisovačů a Selhání ověření popisovačů objektů.
Objekty zařízení
Zabezpečení objektů zařízení Další informace naleznete v tématu Zabezpečení objektů zařízení.
Ověřte objekty zařízení. Další informace naleznete v tématu Selhání ověření objektů zařízení.
IrPs
WDF a IRPs
Jednou z výhod použití WDF je, že ovladače WDF obvykle nemají přímý přístup k irps. Rámec například převádí WDM IRP, které představují operace čtení, zápisu a řízení vstupně/výstupních zařízení, na objekty žádostí v rámci, které KMDF/UMDF přijímá ve vstupně-výstupních frontách.
Pokud píšete ovladač WDM, projděte si následující pokyny.
Správná správa vstupně-výstupních vyrovnávacích pamětí protokolu IRP
Následující články obsahují informace o ověřování vstupních hodnot protokolu IRP:
DispatchReadWrite s využitím vstupně-výstupních ve vyrovnávací paměti
Chyby v vstupně-výstupních ve vyrovnávací paměti
DispatchReadWrite s využitím přímého vstupu/výstupu
Chyby v přímých vstupně-výstupních
problémy se zabezpečením pro kódy řízení vstupně-výstupních operací
Zvažte ověření hodnot přidružených k protokolu IRP, jako jsou adresy vyrovnávací paměti a délky.
Pokud jste se rozhodli použít Neither I/O, mějte na paměti, že na rozdíl od operací Čtení a Zápis a na rozdíl od Vyrovnávacího I/O a Přímého I/O, při použití IOCTL Neither I/O nejsou ukazatele a délky vyrovnávací paměti ověřovány správcem I/O operací.
Správné zpracování operací dokončování protokolu IRP
Ovladač nesmí nikdy dokončit protokol IRP se stavovou hodnotou STATUS_SUCCESS, pokud ve skutečnosti nepodporuje a nezpracuje protokol IRP. Informace o správných způsobech zpracování operací dokončení IRP najdete v tématu Dokončení IRP.
Správa čekajícího stavu IRP ovladače
Ovladač by měl označit IRP jako čekající před jeho uložením a je vhodné zvážit zahrnutí volání IoMarkIrpPending a přiřazení ve vzájemně blokované sekvenci. Další informace naleznete v dokumentu Selhání kontroly stavu ovladače a Uchovávání příchozích IRPs, když je zařízení pozastavené.
Správně zacházejte s operacemi zrušení IRP
Operace zrušení můžou být obtížné správně kódovat, protože se obvykle provádějí asynchronně. Problémy s kódem, který zpracovává operace zrušení, mohou být dlouho bez upozornění, protože tento kód se obvykle nespustí často v běžícím systému. Nezapomeňte si přečíst a porozumět všem informacím uvedeným v části Zrušení IRPs. Věnujte zvláštní pozornost synchronizaci zrušení IRP a bodům, které je třeba zvážit při rušení IRP.
Jedním z doporučených způsobů, jak minimalizovat problémy se synchronizací spojené s operacemi zrušení, je implementovat frontu protokolu IRP bezpečného zrušení.
Správné zpracování operací vyčištění a zavření protokolu IRP
Ujistěte se, že rozumíte rozdílu mezi požadavky IRP_MJ_CLEANUP a IRP_MJ_CLOSE. Žádosti o vyčištění dorazí poté, co aplikace uzavře všechny popisovače objektu souboru, ale někdy předtím, než jsou dokončeny všechny I/O požadavky. Požadavky na zavření přicházejí poté, co byly dokončeny nebo zrušeny všechny vstupně-výstupní požadavky na objekt souboru. Další informace najdete v následujících článcích:
Rutiny DispatchCreate, DispatchClose a DispatchCreateClose
Rutiny pro vyčištění odesílání
Chyby při řízení operací úklidu a zavření
Další informace o správném zpracování IRP naleznete v tématu Další chyby při zpracování IRP.
Další problémy se zabezpečením
K prevenci kritických situací použijte zámek nebo vzájemně zablokovanou sekvenci. Další informace naleznete v tématu Chyby v multiprocesorovém prostředí.
Ujistěte se, že ovladače zařízení správně zpracovávají různé uživatelské módy a také kernel ke kernelu I/O požadavky.
Ujistěte se, že během instalace nebo používání nejsou nainstalovány žádné filtry TDI ani LSP ovladačem nebo přidruženými softwarovými balíčky.
Použití bezpečných funkcí
Používejte bezpečné řetězcové funkce. Další informace naleznete v tématu Použití bezpečných řetězcových funkcí.
Používejte bezpečné aritmetické funkce. Další informace naleznete v části Rutiny knihovny pro bezpečné celočíselné operace
Používejte bezpečné převodní funkce.
Další ohrožení zabezpečení kódu
Kromě možných ohrožení zabezpečení popsaných v tomto článku najdete další informace o vylepšení zabezpečení kódu ovladače režimu jádra: vytváření spolehlivých ovladačů Kernel-Mode.
Další informace o zabezpečeném kódování jazyka C a C++ najdete v tématu bezpečné kódování prostředků na konci tohoto článku.
Správa řízení přístupu k ovladačům
položku kontrolního seznamu zabezpečení č. 7:Zkontrolujte ovladač, abyste měli jistotu, že správně řídíte přístup.
Správa řízení přístupu k ovladačům – WDF
Ovladače musí fungovat tak, aby uživatelům zabránily v nevhodném přístupu k zařízením a souborům počítače. Pokud chcete zabránit neoprávněnému přístupu k zařízením a souborům, musíte:
Pojmenujte objekty zařízení pouze v případě potřeby. Pojmenované objekty zařízení jsou obecně nezbytné pouze z historických důvodů, například pokud máte aplikaci, která očekává, že zařízení otevře pomocí konkrétního názvu, nebo pokud používáte ne-PNP zařízení/řídící zařízení. Všimněte si, že ovladače WDF nemusí pojmenovat své PnP zařízení jako FDO, aby bylo možné vytvořit symbolický odkaz pomocí WdfDeviceCreateSymbolicLink.
Zabezpečený přístup k objektům a rozhraním zařízení
Pokud chcete povolit aplikacím nebo jiným ovladačům WDF přístup k PDO zařízení PnP, měli byste použít rozhraní zařízení. Další informace naleznete v tématu Použití rozhraní zařízení. Rozhraní zařízení slouží jako symbolický odkaz na PDO zásobníku vašich zařízení.
Jedním z nejlepších způsobů, jak řídit přístup k PDO, je zadání řetězce SDDL v INF. Pokud řetězec SDDL není v souboru INF, systém Windows použije výchozí popisovač zabezpečení. Další informace najdete v tématu Zabezpečení objektů zařízení a SDDL pro objekty zařízení.
Další informace o řízení přístupu najdete v následujících článcích:
řízení přístupu zařízení v ovladačích KMDF
Názvy, bezpečnostní popisovače a třídy zařízení – zpřístupnění objektů zařízení... a SAFE z ledna až února 2017 bulletin NT Insider vydaný OSR.
Správa řízení přístupu k ovladačům – WDM
Pokud pracujete s ovladačem WDM a použili jste pojmenovaný objekt zařízení, můžete použít IoCreateDeviceSecure a zadat SDDL k jeho zabezpečení. Při implementaci IoCreateDeviceSecure vždy uveďte identifikátor GUID vlastní třídy pro DeviceClassGuid. Zde byste neměli zadávat existující identifikátor GUID třídy. Díky tomu může dojít k narušení nastavení zabezpečení nebo kompatibility pro jiná zařízení patřící do této třídy. Další informace naleznete v tématu WdmlibIoCreateDeviceSecure.
Další informace najdete v následujících článcích:
Řízení Přístupu k Namespace Zařízení
model zabezpečení Windows pro vývojáře ovladačů
Hierarchie rizik identifikátorů zabezpečení (SID)
Následující část popisuje hierarchii rizik běžných identifikátorů SID používaných v kódu ovladače. Obecné informace o SDDL najdete v tématech SDDL pro objekty zařízení, SID řetězcea syntaxe řetězce SDDL.
Je důležité vědět, že pokud mají volající s nižšími oprávněními povolený přístup k jádru, zvyšuje se riziko kódu. V tomto souhrnném diagramu se riziko zvyšuje, protože povolíte přístup identifikátorů SID s nižšími oprávněními k funkcím ovladače.
SY (System)
\/
BA (Built-in Administrators)
\/
LS (Local Service)
\/
BU (Built-in User)
\/
AC (Application Container)
Podle obecného principu zabezpečení s nejnižšími oprávněními nakonfigurujte pouze minimální úroveň přístupu, která se vyžaduje pro fungování ovladače.
Ovládací prvek zabezpečení WDM Granular IOCTL
Aby bylo možné dále spravovat zabezpečení, když volající v uživatelském režimu posílají IOCTLs, může kód ovladače obsahovat IoValidateDeviceIoControlAccess funkci. Tato funkce umožňuje ovladači kontrolovat přístupová práva. Při přijetí IOCTL může ovladač volat IoValidateDeviceIoControlAccesss určením FILE_READ_ACCESS, FILE_WRITE_ACCESS nebo obojího.
Implementace podrobného řízení zabezpečení IOCTL nenahrazuje potřebu správy přístupu k ovladačům pomocí technik probíraných výše.
Další informace najdete v následujících článcích:
definování kódů ovládacích prvků vstupně-výstupních operací
Implementace kompatibilního kódu HVCI
položku kontrolního seznamu zabezpečení č. 8:Ověřte, zda ovladač používá paměť, aby byl kompatibilní s HVCI.
Využití paměti a kompatibilita HVCI
HVCI využívá hardwarovou technologii a virtualizaci k izolaci rozhodovací funkce integrity kódu (CI) od zbytku operačního systému. Pokud k izolaci CI používáte zabezpečení založené na virtualizaci, jediným způsobem, jak se může stát spustitelná paměť jádra, je ověření CI. To znamená, že stránky paměti jádra nemohou být nikdy zapisovatelné a spustitelné soubory (W+X) a spustitelný kód nelze přímo upravit.
Pokud chcete implementovat kód kompatibilní s HVCI, ujistěte se, že kód ovladače provede následující:
- NX je ve výchozím nastavení povolen.
- Používá NX API a příznaky pro přidělení paměti (NonPagedPoolNx).
- Nepoužívá oddíly, které jsou zapisovatelné i spustitelné.
- Nepokoušá se přímo upravit paměť spustitelného systému.
- Nepoužívá dynamický kód v jádru.
- Nenačítá datové soubory jako spustitelné soubory.
- Zarovnání oddílu je násobkem 0x1000 (PAGE_SIZE). Například DRIVER_ALIGNMENT=0x1000
Další informace o použití nástroje a seznamu nekompatibilních volání paměti naleznete v tématu Implementace kompatibilního kódu HVCI.
Další informace o souvisejícím testu základů zabezpečení systému naleznete v tématu HyperVisor Code Integrity Readiness Test a Hypervisor-Protected Integrita kódu (HVCI).
Postupujte podle osvědčených postupů pro kód specifický pro technologie.
položku kontrolního seznamu zabezpečení č. 9:Zkontrolujte následující pokyny týkající se technologií pro váš ovladač.
Systémy souborů
Další informace o zabezpečení ovladačů systému souborů najdete v následujících článcích:
Úvod do zabezpečení souborových systémů
Problémy se zabezpečením systému souborů
funkce zabezpečení pro systémy souborů
koexistence s jinými ovladači filtru systému souborů
NDIS – Sítě
Informace o zabezpečení ovladačů NDIS naleznete v tématu Problémy se zabezpečením síťových ovladačů.
Displej
Informace o zabezpečení ovladače zobrazení naleznete v tématu <Obsah čeká na vyřízení>.
Tiskárny
Informace týkající se zabezpečení ovladače tiskárny naleznete v tématu V4 Aspekty zabezpečení ovladačů tiskárny.
Problémy se zabezpečením ovladačů WIA (Windows Image Acquisition)
Informace o zabezpečení WIA naleznete v tématu Problémy se zabezpečením ovladačů WIA (Windows Image Acquisition).
Vylepšení zabezpečení instalace zařízení
položku kontrolního seznamu zabezpečení č. 10:Zkontrolujte pokyny k vytvoření a instalaci ovladače, abyste měli jistotu, že používáte osvědčené postupy.
Když vytvoříte kód, který nainstaluje ovladač, musíte zajistit, aby se instalace zařízení vždy prováděla zabezpečeným způsobem. Zabezpečená instalace zařízení je ta, která provádí následující akce:
- Omezuje přístup k zařízení a jeho třídám rozhraní zařízení.
- Omezuje přístup ke službám ovladačů vytvořeným pro zařízení.
- Chrání soubory ovladačů před úpravami nebo odstraněním.
- Omezuje přístup k položkám registru zařízení.
- Omezuje přístup k WMI třídám zařízení.
- Používá správně funkce SetupAPI.
Další informace najdete v následujících článcích:
vytváření zabezpečených instalací zařízení
Použití funkcí instalace zařízení
Pokročilá témata o instalaci zařízení a ovladačů
Kontrola partnerského kódu
položka kontrolního seznamu zabezpečení č. 11:Provést kontrolu partnerského kódu a hledat problémy, které ostatní nástroje a procesy
Vyhledejte znalé revidujících kódu, aby vyhledali problémy, které jste mohli zmeškat. Druhá sada očí často uvidí problémy, které jste možná přehlédli.
Pokud nemáte vhodné zaměstnance pro interní kontrolu kódu, zvažte zapojení externí nápovědy pro tento účel.
Provedení správného podepisování ovladačů vydaných verzí
položku kontrolního seznamu zabezpečení č. 12:Pomocí partnerského portálu pro Windows správně podepište ovladač pro distribuci.
Před vydáním balíčku ovladačů pro veřejnost doporučujeme odeslat balíček k certifikaci. Další informace najdete v tématu Testování výkonu a kompatibility, Začínáme s hardwarovým programem, služby hardwarového řídicího panelua Ověření identity podpisem ovladače jádra pro veřejnou verzi.
Použití CodeQL ke kontrole kódu ovladače
položku kontrolního seznamu zabezpečení č. 13:Pomocí codeQL zkontrolujte ohrožení zabezpečení v kódu ovladače.
CodeQL, by GitHub, je sémantický modul pro analýzu kódu a kombinace rozsáhlé sady bezpečnostních dotazů spolu s robustní platformou představuje neocenitelný nástroj pro zabezpečení kódu ovladače. Další informace naleznete v tématu CodeQL a testu loga statických nástrojů.
Přidání poznámek SAL do kódu ovladače
položku kontrolního seznamu zabezpečení č. 14:přidat poznámky SAL do kódu ovladače.
Jazyk SAL (Source Code Annotation Language) poskytuje sadu poznámek, které můžete použít k popisu, jak funkce používá své parametry, předpoklady, které o nich dělá, a záruky, které provede po dokončení. Poznámky jsou definovány v souboru záhlaví sal.h. Analýza kódu sady Visual Studio pro C++ používá k úpravě analýzy funkcí poznámky SAL. Další informace o sal 2.0 pro vývoj ovladačů systému Windows naleznete v tématu SAL 2.0 Poznámky pro ovladače systému Windows a Použití poznámek SAL ke snížení vad kódu C/C++.
Obecné informace o SAL najdete v tomto článku, který je k dispozici v OSR. https://www.osr.com/blog/2015/02/23/sal-annotations-dont-hate-im-beautiful/
Kontrola ohrožení zabezpečení pomocí nástroje Driver Verifier
položku kontrolního seznamu zabezpečení č. 15:Pomocí nástroje Driver Verifier zkontrolujte ohrožení zabezpečení v kódu ovladače.
Ovladač Verifier používá sadu pravidel rozhraní a model operačního systému k určení, zda ovladač pracuje správně s operačním systémem Windows. DV najde chyby v kódu ovladače, které by mohly odkazovat na potenciální chyby v ovladačích.
Ověření ovladače umožňuje živé testování ovladače. Nástroj Driver Verifier monitoruje ovladače režimu jádra Systému Windows a grafické ovladače, aby detekovali neplatná volání funkcí nebo akce, které by mohly poškodit systém. Ovladač Verifier může ovladače systému Windows podmět nejrůznějším stresům a testům, aby zjistil nesprávné chování. Další informace naleznete v tématu Driver Verifier.
Všimněte si, že DV podporuje pouze určité typy ovladačů. Další informace o ovladačích, které DV může ověřit, naleznete v tématu Podporované ovladače. Informace o testech DV dostupných pro typ ovladače, se kterým pracujete, najdete na následujících stránkách.
- pravidla pro ovladače WDM
- pravidla pro ovladače KMDF
- pravidla pro ovladače NDIS
- Pravidla pro ovladače Storport
- pravidla pro ovladače zvuku
- pravidla pro ovladače AVStream
Abyste se seznámili s DV, můžete použít jeden z ukázkových ovladačů (například ukázkový ovladač toustovače: https://github.com/Microsoft/Windows-driver-samples/tree/main/general/toaster/toastDrv/kmdf/func/featured).
Kontrola kódu pomocí binárního analyzátoru BinSkim
položku kontrolního seznamu zabezpečení č. 16:Pomocí tohoto postupu zkontrolujte, jestli jsou možnosti kompilace a sestavení nakonfigurované tak, aby se minimalizovaly známé problémy se zabezpečením.
Pomocí BinSkim prozkoumejte binární soubory a identifikujte postupy kódování a sestavování, které můžou potenciálně způsobit ohrožení binárního souboru.
BinSkim kontroluje:
- Použití zastaralých sad nástrojů kompilátoru – Binární soubory by se měly zkompilovat proti nejnovějším sadám nástrojů kompilátoru, kdykoli je to možné, aby se maximalizovalo použití aktuálních omezení zabezpečení na úrovni kompilátoru a operačního systému.
- Nezabezpečená nastavení kompilace – Binární soubory by měly být zkompilovány s nejbezpečnějšími možnými nastaveními, aby bylo možné povolit zmírnění rizik zabezpečení poskytované operačním systémem, maximalizovat chyby kompilátoru a hlášení upozornění s možností akcí, mimo jiné.
- Problémy s podepisováním – Podepsané binární soubory by měly být podepsané kryptograficky silnými algoritmy.
BinSkim je opensourcový nástroj a generuje výstupní soubory, které používají formát Static Analysis Results Interchange Format (SARIF). BinSkim nahrazuje bývalý nástroj BinScope.
Další informace o BinSkim naleznete v Použití BinSkim pro kontrolu binárních souborů a v Uživatelské příručce BinSkim.
Kontrola kódu pomocí testů programu kompatibility hardwaru
položka kontrolního seznamu zabezpečení č. 17:Pomocí testů programu kompatibility hardwaru souvisejících se zabezpečením zkontrolujte problémy se zabezpečením.
Program kompatibility hardwaru zahrnuje testy související se zabezpečením, které lze použít k vyhledání ohrožení zabezpečení kódu. Program kompatibility hardwaru systému Windows využívá testy v sadě Windows Hardware Lab Kit (HLK). Testy HLK Device Fundamentals lze použít na příkazovém řádku k testování kódu ovladače a odhalování slabin. Obecné informace o základních testech zařízení a programu kompatibility hardwaru naleznete v tématu Windows Hardware Lab Kit.
Následující testy jsou příklady testů, které můžou být užitečné ke kontrole kódu ovladače pro určité chování spojené s ohrožením zabezpečení kódu:
DF – přibližný náhodný test IOCTL (spolehlivost)
DF – test přibližného otevření (spolehlivost)
DF - Fuzz testování bufferu FSCTL s nulovou délkou (spolehlivost)
DF – přibližný náhodný test FSCTL (spolehlivost)
DF – Test API fuzzingu (spolehlivost)
Můžete také použít přibližné zpoždění synchronizace jádra, které je součástí nástroje Driver Verifier.
Testy CHAOS (Concurrent Hardware and Operating System) spouští různé testy ovladače PnP, testy přibližných chyb ovladačů zařízení a testy napájecího systému souběžně. Další informace naleznete v tématu CHAOS Testy (Základy zařízení).
Testy penetrace Device Fundamentals provádějí různé formy vstupních útoků, které jsou důležitou součástí testování zabezpečení. Testování útoku a průniku může pomoct identifikovat ohrožení zabezpečení v softwarových rozhraních. Další informace naleznete v tématu Penetrační Testy (Základy Zařízení).
Pomocí Device Guard – testu shody, spolu s dalšími nástroji popsanými v tomto článku, ověřte, že váš ovladač je kompatibilní s HVCI.
Vlastní testovací nástroje a testovací nástroje specifické pro doménu
Zvažte vývoj vlastních testů zabezpečení specifických pro doménu. Pokud chcete vyvíjet další testy, shromážděte vstup od původních návrhářů softwaru a také nesouvisejících vývojových prostředků známých s konkrétním typem ovladače, který se vyvíjí, a jeden nebo více lidí, kteří znají analýzu a prevenci narušení zabezpečení.
Vysvětlení toho, jak se hlásí ovladače pomocí Centra pro hlášení ohrožení zabezpečení a škodlivého ovladače od Microsoftu
položka kontrolního seznamu zabezpečení č. 18: Zjistěte, jak se hlásí ovladače pomocí Centra pro hlášení ohrožení zabezpečení a škodlivého ovladače od Microsoftu.
Kdokoli může nahlásit podezřelý ovladač prostřednictvím Centra pro hlášení zranitelných a škodlivých ovladačů společnosti Microsoft. Informace o tom, jak se ovladače odesílají k analýze, najdete v tomto blogovém příspěvku – Vylepšení zabezpečení jádra pomocí nového centra microsoftu pro sestavy ohrožených a škodlivých ovladačů
Centrum pro vytváření sestav může prohledávat a analyzovat ovladače Systému Windows vytvořené pro architektury x86 a x64. Ohrožené a škodlivé ovladače jsou označeny pro analýzu a prošetření týmem pro zranitelné ovladače společnosti Microsoft. Po potvrzení ohrožených ovladačů je provedeno příslušné oznámení a tito ovladače jsou přidány do seznamu blokovaných ovladačů. Další informace o tom naleznete v tématu doporučené pravidla blokování ovladačů společnosti Microsoft. Tato pravidla se ve výchozím nastavení použijí pro zařízení s podporou integrity kódu chráněného hypervisorem (HVCI) a Windows 10 v režimu S.
Kontrola zabezpečených prostředků kódování
položku kontrolního seznamu zabezpečení č. 19:Projděte si tyto zdroje informací o osvědčených postupech pro bezpečné kódování, které platí pro vývojáře ovladačů.
Pokyny pro bezpečné kódování ovladačů v režimu jádra
vytváření spolehlivých ovladačů Kernel-Mode
Organizace zabezpečeného kódování
Carnegie Mellon University SEI CERT
Carnegie Mellon University SEI CERT C Coding Standard: Pravidla pro vývoj bezpečných, spolehlivých a zabezpečených systémů (2016 Edition).
MITRE – slabá místa adresovaná standardem zabezpečeného kódování CERT C
Sestavování zabezpečení v modelu vyspělosti (BSIMM) – https://www.bsimm.com/
SAFECode – https://safecode.org/
OSR
OSR poskytuje školení a konzultační služby pro vývoj ovladačů. Tyto články z bulletinu OSR zvýrazňují problémy se zabezpečením ovladačů.
Názvy, popisovače zabezpečení a třídy zařízení – zpřístupnění objektů zařízení... a SAFE
Musíte se chránit – uvnitř ovladače & zabezpečení zařízení
Uzamčení ovladačů – Průzkum technik
Meltdown a Spectre: Co ovladače?
Případová studie
Knihy
24 smrtelných hříchů zabezpečení softwaru : programovací nedostatky a jak je opravit Michael Howard, David LeBlanc a John Viega
Umění posouzení zabezpečení softwaru : identifikace a prevence ohrožení zabezpečení softwaru, Mark Dowd, John McDonald a Justin Schuh
Psaní Zabezpečeného Softwaru Druhé VydáníMichael Howard a David LeBlanc
Umění posouzení zabezpečení softwaru: Identifikace a prevence ohrožení zabezpečení softwaru, Mark Dowd a John McDonald
zabezpečené kódování v C a C++ (řada SEI v softwarovém inženýrství) 2. vydání, Robert C. Seacord
Programování modelu ovladače systému Microsoft Windows (2. vydání), Walter Oney
Vývoj ovladačů pomocí Windows Driver Foundation (Reference pro vývojáře), Penny Orwick a Guy Smith
Školení
Školení ovladačů systému Windows je k dispozici od dodavatelů, jako jsou následující:
Online školení o bezpečném kódování je k dispozici od různých poskytovatelů. Tento kurz je například k dispozici na webu coursera na:
Identifikace zranitelností zabezpečení v programovánív C/C++.
SAFECode nabízí také bezplatné školení:
Profesionální certifikace
CERT nabízí Osvědčení o profesionálním bezpečném programování.
Shrnutí klíčových poznatků
Zabezpečení řidičů je složitý úkol obsahující mnoho prvků, ale tady je několik klíčových bodů, které je potřeba vzít v úvahu:
Ovladače jsou součástí jádra Windows a problém při jejich spuštění v jádru může ohrozit celý operační systém. Z tohoto důvodu věnujte zvláštní pozornost zabezpečení řidičů a navrhujte s ohledem na bezpečnost.
Použijte zásadu nejnižších oprávnění:
a. Použití striktního řetězce SDDL k omezení přístupu k ovladači
b. Další omezení individuální hodnoty IOCTL
Vytvořte model hrozeb pro identifikaci vektorů útoku a zvažte, jestli je možné cokoli dál omezit.
Buďte opatrní, pokud jde o vložené ukazatele předávané z uživatelského režimu. Musí být důkladně zkontrolovány, přístupné v rámci bloku try except, a jsou náchylné k problémům času kontroly a času použití (ToCToU), pokud není zachycena a porovnána hodnota vyrovnávací paměti.
Pokud si nejste jistí, použijte METHOD_BUFFERED jako metodu ukládání do vyrovnávací paměti IOCTL.
Pomocí nástrojů pro kontrolu kódu vyhledejte známá ohrožení zabezpečení kódu a opravte případné zjištěné problémy.
Vyhledejte znalé revidujících kódu, aby vyhledali problémy, které jste mohli zmeškat.
Použijte ověřovatele ovladačů a otestujte ovladač s různými vstupy, včetně hraničních případů.