Illesztőprogramok biztonsági ellenőrzőlistája

Ez a cikk egy illesztőprogram-biztonsági ellenőrzőlistát biztosít az illesztőprogram-fejlesztők számára, amely segít csökkenteni az illesztőprogramok sérülésének kockázatát. Az illesztőprogram biztonsága kritikus fontosságú, és közvetlenül befolyásolja a megbízhatóságot. Amikor a Windows észleli, hogy helytelen memóriahozzáférés történik, leállítja az operációs rendszert, és kék hibaképernyőt jelenít meg. Windows-partnerként azon kell dolgoznia, hogy csökkentse a sikertelen illesztőprogramok által az ügyfeleink életére gyakorolt jelentős hatást.

A biztonságos és megbízható illesztőprogramok előnyeiről további információt talál a Illesztőprogram biztonsági útmutatójacímű dokumentumban.

Illesztőprogramok biztonsága – áttekintés

A biztonsági hiba minden olyan hiba, amely lehetővé teszi a támadó számára, hogy az illesztőprogram meghibásodását okozza oly módon, hogy lehetővé teszi a támadó számára a jogosulatlan hozzáférést, a rendszer manipulálását vagy az adatok veszélyeztetését, ami a rendszer összeomlását vagy használhatatlanná válását okozhatja. Emellett az illesztőprogram-kód biztonsági rései lehetővé teszik a támadók számára a kernelhez való hozzáférést, ami lehetővé teszi a teljes operációs rendszer veszélyeztetésének lehetőségét.

Amikor a legtöbb fejlesztő az illesztőprogramon dolgozik, az illesztőprogram megfelelő működésére összpontosítanak, és nem arra, hogy egy rosszindulatú támadó megpróbálja-e kihasználni a kódban lévő biztonsági réseket. Az illesztőprogram kiadása után azonban a támadók megpróbálhatják felderíteni és azonosítani a biztonsági hibákat. A fejlesztőknek a tervezési és megvalósítási fázisban figyelembe kell venniük ezeket a problémákat, hogy a lehető legkisebb legyen az ilyen biztonsági rések valószínűsége. A cél az összes ismert biztonsági hiba kiküszöbölése az illesztőprogram kiadása előtt.

A biztonságosabb illesztőprogramok létrehozásához szükség van a rendszermérnök együttműködésére (tudatosan gondolva a potenciális fenyegetésre a vezetőre), a kód implementálására (a közös műveletek védelmi kódolására, amelyek a biztonsági rések forrása lehet) és a tesztcsapat (proaktív módon próbálják megtalálni a gyengeségeket és a sebezhetőségeket). Ezeknek a tevékenységeknek a megfelelő koordinálásával a vezető biztonsága jelentősen megnő.

Amellett, hogy elkerüli az illesztőprogramok támadásával kapcsolatos problémákat, számos leírt lépés, például a kernelmemória pontosabb használata növeli az illesztőprogram megbízhatóságát. Ez csökkenti a támogatási költségeket, és növeli az ügyfelek elégedettségét a termékkel. Az alábbi ellenőrzőlistán szereplő feladatok elvégzése segít elérni ezeket a célokat.

biztonsági ellenőrzőlista:Végezze el az egyes témakörökben leírt biztonsági feladatot.

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. Győződjön meg arról, hogy kernelillesztőre van szükség

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. Illesztőprogram-keretrendszerek használata

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. Hozzáférés-vezérlés kezelése az illesztőprogramokhoz

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. A hozzáférés szabályozása kizárólag a szoftveres illesztőprogramokhoz

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. Illesztőprogramok biztonságos kódolási irányelveinek követése

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. HVCI-kompatibilis kód implementálása

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. A technológiaspecifikus kódokkal kapcsolatos ajánlott eljárások követése

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. SAL-széljegyzetek hozzáadása az illesztőprogram kódjához

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. Társkód ellenőrzése

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. Hajts végre fenyegetés-elemzést

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. A CodeQL használatával ellenőrizze az illesztőprogram kódját

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. Az Illesztőprogram-ellenőrző használatával ellenőrizze a biztonsági réseket

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. Kód ellenőrzése a hardverkompatibilitási program tesztjeivel

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. Ellenőrizze, hogy készen áll-e a sofőrök szállítására olyan eszközökkel, mint a BinSkim és a SignTool

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. Ne írja alá a tesztillesztő-kódot produkcióra

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. Hajtsa végre a megfelelő kiadási illesztőprogram-aláírást, és terjessze az illesztőprogram-csomagot a Windows Update szolgáltatáson keresztül.

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. Megértése annak, hogy az illesztőprogramok hogyan kerülnek jelentésre a Microsoft Sebezhető és Rosszindulatú Illesztőprogram Jelentési Központban

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. Biztonságos kódolási erőforrások áttekintése

A biztonsági ellenőrzőlista egyik elemét jelképező jelöletlen jelölőnégyzet. A legfontosabb tanulságok összegzésének áttekintése

Győződjön meg arról, hogy kernelillesztőre van szükség

biztonsági ellenőrzőlista 1. eleme:Győződjön meg arról, hogy kernelillesztőre van szükség, és hogy az alacsonyabb kockázatú megközelítés, például a Windows szolgáltatás vagy az alkalmazás, nem jobb megoldás.

A kernelillesztők a Windows kernelben futnak, és ha valamilyen probléma merül fel a kernel működése során, az kihat az egész operációs rendszerre. Ha bármilyen más lehetőség is elérhető, az valószínűleg alacsonyabb költséggel jár, és kisebb kockázattal jár, mint egy új kernelillesztő létrehozása.

További információ a beépített Windows-illesztőprogramok használatáról: Kell-e illesztőprogramot írnia?.

További információ a háttérfeladatok használatáról: Az alkalmazás támogatása háttérfeladatokkal.

További információ a Windows Services használatáról: Services.

Az illesztőprogram-keretrendszerek használata

2. biztonsági ellenőrzőlistaelem:Az illesztőprogram-keretrendszerek használatával csökkentheti a kód méretét, és növelheti annak megbízhatóságát és biztonságát.

A Windows illesztőprogram-keretrendszerek használatával csökkentheti a kód méretét, és növelheti annak megbízhatóságát és biztonságát. Első lépésként tekintse át a WDF használata illesztőprogram fejlesztésére. Az alacsonyabb kockázatú felhasználói módú illesztőprogram-keretrendszer (UMDF) használatáról további információt Illesztőprogram-modell kiválasztásacímű témakörben talál.

A Régimódi Windows Illesztőprogram-modell (WDM) illesztőprogram írása időigényesebb, költségesebb, és magában foglalja az illesztőprogram-keretrendszerekben elérhető kód újraírását.

A Windows Driver Framework (WDF) forráskódja nyílt forráskódú, és elérhető a GitHubon. Ez ugyanaz a WDF-forráskód, amely a Windowsban található. Hatékonyabban hibakeresést végezhet az illesztőprogramban, ha követni tudja az illesztőprogram és a WDF közötti interakciókat. Töltse le https://github.com/Microsoft/Windows-Driver-Frameworks.

DMF – Illesztőprogram-modul keretrendszere

Fontolja meg az illesztőmodul-keretrendszer (DMF) használatát az illesztőprogram-projektben. A Microsoft Surface csapata által kifejlesztett DMF egy olyan keretrendszer, amely lehetővé teszi WDF-objektumok, úgynevezett DMF-modulok létrehozását. Ezeknek a DMF-moduloknak a kódja megosztható a különböző illesztőprogramok között. A DMF emellett olyan DMF-modulok könyvtárát is biztosítja, amelyeket illesztőprogramok számára fejlesztettek ki, és kódokat kínálnak újra az olyan feladatokhoz, mint a szál- és az I/O-felügyelet. A DMF-modul az illesztőprogram-feladatok kisebb egységekbe való beágyazására szolgál. Minden modul önálló, és saját kóddal, környezettel és visszahívásokkal rendelkezik, így könnyebben újrafelhasználható. További információ: Illesztőprogram-modul keretrendszerének bemutatása és a GitHub-webhely dokumentációja.

Illesztőprogramok hozzáférés-vezérlésének kezelése

3. biztonsági ellenőrzőlistaelem:Ellenőrizze az illesztőprogramot, hogy biztosan megfelelően szabályozza-e a hozzáférést.

Illesztőprogram-hozzáférés-vezérlés kezelése – WDF

Az illesztőprogramoknak meg kell akadályozni, hogy a felhasználók nem férhessenek hozzá a számítógép eszközeihez és fájljaihoz. Az eszközökhöz és fájlokhoz való jogosulatlan hozzáférés megakadályozása érdekében a következőt kell tennie:

  • Csak akkor nevezze el az eszközobjektumokat, ha szükséges. Az elnevezett eszközobjektumok általában csak örökölt okokból szükségesek, például ha egy olyan alkalmazással rendelkezik, amely egy adott névvel szeretné megnyitni az eszközt, vagy ha nem PNP-eszközt/vezérlőeszközt használ. A WDF-illesztőprogramoknak nem kell megnevezniük a PnP-eszköz FDO-ját, hogy szimbolikus hivatkozást hozzanak létre WdfDeviceCreateSymbolicLinkhasználatával.

  • Biztonságos hozzáférés az eszközobjektumokhoz és -felületekhez.

Annak érdekében, hogy az alkalmazások vagy más WDF-illesztőprogramok hozzáférhessenek a PnP-eszköz PDO-jához, eszközfelületeket kell használnia. További információ: Eszközfelületek használata. Az eszközfelület szimbolikus hivatkozásként szolgál az eszközkészlet PDO-jához.

Az egyik jobb módja a PDO-hoz való hozzáférés szabályozásának, ha megad egy SDDL-sztringet az INF-ben. Ha az SDDL-sztring nem szerepel az INF-fájlban, a Windows egy alapértelmezett biztonsági leírót alkalmaz. További információ: Eszközobjektumok biztonságának biztosítása és Eszközobjektumok SDDL-je.

A hozzáférés szabályozásáról további információt a következő témakörben talál:

Eszközhozzáférés vezérlése a KMDF-illesztőprogramokban

Nevek, biztonsági leírók és eszközosztályok – Eszközobjektumok hozzáférhetővé tétele... és biztonságos 2017. január-február OSRáltal közzétett NT Insider-hírlevél.

Meghajtó-hozzáférés-vezérlés kezelése – WDM

Ha WDM-illesztőprogrammal dolgozik, és egy elnevezett eszközobjektumot használt, használhatja IoCreateDeviceSecure, és megadhat egy SDDL-t a biztonságossá tételéhez. Az IoCreateDeviceSecure implementálásakor mindig adjon meg egy egyéni osztály GUID azonosítót a DeviceClassGuidhez. Itt nem szabad meglévő osztály GUID azonosítót megadnia. Ezzel megszakíthatja az adott osztályhoz tartozó egyéb eszközök biztonsági beállításait vagy kompatibilitását. További információ: WdmlibIoCreateDeviceSecure.

További információ:

Az eszközök elérésének vezérlése

Az eszköznévtér hozzáférésének vezérlése

Windows biztonsági modell illesztőprogram-fejlesztőknek

Biztonsági azonosítók (SID-k) kockázati hierarchiája

Az alábbi szakasz az illesztőprogram-kódban használt gyakori SID-k kockázati hierarchiáját ismerteti. Az SDDL-vel kapcsolatos általános információkért lásd a eszközobjektumok SDDL-jét, a SID-sztringeket, és a SDDL-sztring szintaxisát.

Fontos tisztában lenni azzal, hogy ha az alacsonyabb jogosultságú hívók hozzáférhetnek a kernelhez, a kód kockázata nő. Ebben az összefoglaló ábrán a kockázat növekszik, mivel lehetővé teszi az alacsonyabb jogosultságú SID-k számára az illesztőprogram funkcióinak elérését.

SY (System)
     \/
BA (Built-in Administrators)
     \/
LS (Local Service)
     \/
BU (Built-in User)
     \/
AC (Application Container)

Az általános minimális jogosultsági biztonsági alapelvet követve konfigurálja csak az illesztőprogram működéséhez szükséges minimális hozzáférési szintet.

WDM finom IOCTL biztonsági vezérlő

A Windowsban az IOCTL (Input/Output Control) eszközspecifikus bemeneti/kimeneti műveletek rendszerhívása. Az IOCTL-eket az alkalmazások az eszközillesztőkkel való kommunikációra használják, így parancsokat küldhetnek, vagy adatokat kérhetnek a hardvertől. További információ: Bevezetés az I/O-vezérlőkódok és I/O-példakérés – Áttekintés.

A felhasználói módú hívók által küldött IOCTLs-üzenetek biztonságának további kezeléséhez az illesztőprogram-kód tartalmazhatja az IoValidateDeviceIoControlAccess függvényt. Ez a függvény lehetővé teszi az illesztőprogram számára a hozzáférési jogosultságok ellenőrzését. Az IOCTL fogadása után az illesztőprogram meghívhatja IoValidateDeviceIoControlAccess, megadva FILE_READ_ACCESS, FILE_WRITE_ACCESS vagy mindkettőt.

Az IOCTL részletes biztonsági vezérlésének implementálása nem helyettesíti az illesztőprogram-hozzáférés felügyeletének szükségességét a fent tárgyalt technikákkal.

További információ: I/O-vezérlőkódok definiálása és I/O-vezérlőkódokkal kapcsolatos biztonsági problémák.

A csak szoftverillesztőként működő driverek hozzáférésének szabályozása

4. biztonsági ellenőrzőlista-elem:Ha létrejön egy csak szoftveres illesztőprogram, további hozzáférés-vezérlést kell implementálnia.

A csak szoftveres kernelillesztők nem használnak plug-and-play (PnP) protokollt adott hardverazonosítókhoz való társításhoz, és bármilyen számítógépen futtathatók. Az ilyen illesztő az eredetileg tervezetten kívüli célokra is használható, és támadási vektort hoz létre.

Mivel a csak szoftveres kernelillesztők további kockázatot jelentenek, bizonyos hardvereken kell futniuk, például egy egyedi PnP-azonosító használatával, amely lehetővé teszi egy PnP-illesztőprogram létrehozását, vagy az SMBIOS-tábla adott hardver meglétének ellenőrzésével.

Tegyük fel például, hogy az OEM Fabrikam olyan illesztőprogramot szeretne elosztani, amely lehetővé teszi a rendszerek túlhajtását. Ha ez a csak szoftveres illesztőprogram egy másik OEM-ből származó rendszeren futna, a rendszer instabilitása vagy sérülése okozhat. A Fabrikam rendszereinek tartalmazniuk kell egy egyedi PnP-azonosítót, amely lehetővé teszi a Windows Update-ben is frissíthető PnP-illesztőprogram létrehozását. Ha ez nem lehetséges, és a Fabrikam egy örökölt illesztőprogramot hoz létre, az illesztőprogramnak egy másik módszert kell találnia annak ellenőrzésére, hogy egy Fabrikam rendszeren fut-e, például az SMBIOS-tábla vizsgálatával, mielőtt bármilyen képességet engedélyez.

Az illesztőprogram biztonságos kódolási irányelveinek követése

5. biztonsági ellenőrzőlista-elem:Tekintse át a kódot, és távolítsa el az ismert kódbiztonsági réseket.

A biztonságos illesztőprogramok létrehozásának fő tevékenysége a kód azon területeinek azonosítása, amelyeket módosítani kell az ismert szoftveres biztonsági rések elkerülése érdekében. Számos ismert szoftveres biztonsági rés azzal foglalkozik, hogy szigorúan nyomon kövesse a memóriahasználatot, hogy elkerülje az illesztőprogram által használt memóriahelyeket felülíró vagy más módon veszélyeztető másokkal kapcsolatos problémákat.

Az olyan kódolvasó eszközök, mint a CodeQL és az illesztőprogram-specifikus tesztek, segíthetnek megtalálni a biztonsági rések némelyikét, de nem mindegyiket. Ezeket az eszközöket és teszteket a jelen témakör későbbi részében ismertetjük.

Memóriapufferek

Az adatpufferek IOCTL-ekkel való eléréséhez használja a megfelelő módszert

A Windows-illesztőprogramok egyik elsődleges feladata az adatok átvitele a felhasználói módú alkalmazások és a rendszer eszközei között. Az adatpufferek elérésének három módszere az alábbi táblázatban látható.

IOCTL-puffer típusa Összefoglalás További információ
METHOD_BUFFERED A legtöbb esetben ajánlott pufferelt I/O- használata
METHOD_IN_DIRECT vagy METHOD_OUT_DIRECT Néhány nagy sebességű hardveres I/O-ban használatos Közvetlen I/O- használata
MÓDSZER_EGYIK_SEM Ha lehetséges, kerülje sem pufferelt, sem közvetlen I/O-

Általában a pufferelt I/O használata ajánlott, mivel a legbiztonságosabb pufferelési módszereket biztosítja. De még pufferelt I/O használata esetén is vannak kockázatok, például beágyazott mutatók, amelyeket csökkenteni kell.

További információ a pufferek IOCTLs-ben való használatával kapcsolatban: Az adatpufferek elérésének módszerei.

Az IOCTL pufferelt I/O használata során felmerülő hibák

  • Ellenőrizze az IOCTL-hez kapcsolódó pufferek méretét. További információért lásd: A pufferek méretének ellenőrzésének elmulasztása.

  • A kimeneti pufferek megfelelő inicializálása. További információ: Kimeneti pufferek inicializálásának sikertelensége.

  • A változóhosszúságú pufferek megfelelő ellenőrzése. További információ: Variable-Length pufferek ellenőrzésének sikertelensége.

  • Pufferelt I/O használatakor győződjön meg róla, és adja vissza az OutputBuffer megfelelő hosszát a IO_STATUS_BLOCK structure Information mezőben. Ne csak közvetlenül a READ kérésből adja vissza a hosszt. Vegyük például azt a helyzetet, amikor a felhasználói területről visszaadott adatok azt jelzik, hogy 4K puffer van. Ha az illesztőprogramnak valójában csak 200 bájtot kellene visszaadnia, hanem csak 4K értéket ad vissza az Információ mezőben egy információfelfedés biztonsági rése lépett fel. Ez a probléma azért fordul elő, mert a Windows korábbi verzióiban az I/O-kezelő által a pufferelt I/O-hoz használt puffer nincs nullázva. Így a felhasználói alkalmazás visszakapja az eredeti 200 bájtnyi adatot, valamint 4K-200 bájtnyi adatot, ami a pufferben volt (nem lapozott készlettartalom). Ez a forgatókönyv a pufferelt I/O minden használatával előfordulhat, és nem csak az IOCTL-ekkel.

Hibák az IOCTL közvetlen I/O műveleteiben

A nulla hosszúságú pufferek helyes kezelése. További információért lásd: Közvetlen I/O hibák.

Felhasználói hely címére való hivatkozással kapcsolatos hibák

  • Ellenőrizze a pufferelt I/O-kérelmekbe ágyazott mutatókat. További információért lásd: Hivatkozási hibák, User-Space címek és.

  • Ellenőrizze a felhasználói térben található címeket, mielőtt megpróbálná használni őket, például a ProbeForReadAPI-k használatával.

Az illesztőprogram-kódnak helyesen kell használnia a memóriát

  • Minden illesztőprogramkészlet-foglalásnak nem végrehajtható (NX) készletben kell lennie. Az NX memóriakészletek használata természeténél fogva biztonságosabb, mint a végrehajtható, nem lapszámozott (NP) készletek használata, és jobb védelmet nyújt a túlcsordulásos támadások ellen.

  • Annak érdekében, hogy az illesztőprogramok támogatják a HVCI-virtualizálást, további memóriakövetelmények állnak rendelkezésre. További információkért lásd: HVCI-kompatibilis kód implementálása a cikkben később.

TOCTOU biztonsági rések

A közvetlen I/O (IOCTL-ekhez vagy írási/olvasási műveletekhez) (TOCTOU) biztonsági rés használata lehetséges idő. Vegye figyelembe, hogy mivel az illesztőprogram hozzáfér a felhasználói adatpufferhez, a felhasználói alkalmazás egyszerre is hozzáférhet ugyanahhoz az adatpufferhez.

A kockázat kezeléséhez másolja a felhasználói adatpufferből érvényesítendő paramétereket a csak kernel módból hozzáférhető memóriába, például a verembe vagy a halmazba. Ezután, miután a felhasználói alkalmazás nem férhet hozzá az adatokhoz, ellenőrizze az átadott adatokat, majd működtessen rajtuk.

MSR-modellspecifikus regiszter olvasása és írása

A fordító belső elemei, például __readmsr és __writemsr használhatók a modellspecifikus regiszterek eléréséhez. Ha erre a hozzáférésre van szükség, az illesztőnek mindig ellenőriznie kell, hogy az olvasáshoz vagy íráshoz használt regiszter a várt indexre vagy tartományra van-e korlátozva.

További információkért és kódpéldákért lásd: MsRs- olvasási/írási lehetőségének biztosítása Ajánlott eljárások a magas jogosultsági szintű viselkedés korlátozásához a kernel módú illesztőprogramok.

Fogantyúk

Eszközobjektumok

IRP-k

A Windows I/O-kéréscsomagok (IRP-k) az operációs rendszer és a kernel módú illesztőprogramok közötti I/O-kérések kommunikációára szolgálnak, és a csomagban található összes szükséges információt belefoglalják. Az IRP-k megkönnyítik az aszinkron adatátvitelt, szinkronizálást és hibakezelést, biztosítva a hardvereszközökkel való hatékony és megbízható kommunikációt. További információ: I/O-kéréscsomagok és Windows I/O-modelláttekintése.

WDF és IRP-k

A WDF használatának egyik előnye, hogy a WDF-illesztőprogramok általában nem férnek hozzá közvetlenül az integrációs modulhoz. A keretrendszer például átalakítja az olvasási, írási és eszköz I/O-vezérlési műveleteket képviselő WDM-integrációs modulokat keretrendszerkérési objektumokká, amelyeket a KMDF/UMDF fogad az I/O-üzenetsorokban. Amikor csak lehetséges, erősen ajánlott a WDF használata.

Ha WDM-illesztőprogramot kell írnia, tekintse át az alábbi útmutatást.

IRP I/O-pufferek megfelelő kezelése

Tekintse át az alábbi témaköröket, amelyek az IRP bemeneti értékeinek érvényesítését ismertetik:

DispatchReadWrite pufferelt I/O használatával

Hibák a pufferelt I/O-ban

DispatchReadWrite közvetlen I/O használatával

közvetlen I/O- hibái

Ellenőrizze az IRP-hez társított értékeket, például a puffercímeket és a hosszokat.

Ha a Neither I/O használatát választotta, vegye figyelembe, hogy az Olvasás és Írás, valamint a pufferelt és közvetlen I/O használatával ellentétben, amikor a Neither I/O IOCTL-t használja, az I/O-kezelő nem érvényesíti a puffermutatókat és azok hosszát.

Az IRP-befejezési műveletek megfelelő kezelése

Az illesztőnek soha nem szabad STATUS_SUCCESS állapotértékkel rendelkező IRP-t befejeznie, kivéve, ha ténylegesen támogatja és feldolgozza az IRP-t. Az IRP-k befejezésének helyes módjairól további információt a "Az IRP-k befejezése" című részben talál.

Az eszközillesztő IRP függő állapotának kezelése

Az illesztőprogramnak meg kell jelölnie az IRP-t függőben lévőként, mielőtt menti az IRP-t, és fontolóra kell vennie mind az IoMarkIrpPending hívást, mind a hozzárendelést egy összefűzött műveletsorba. További információ: lásd Illesztőprogram állapotának ellenőrzésének elmulasztása és az eszköz szüneteltetésekor bejövő IRP-k visszatartása.

Az IRP-lemondási műveletek megfelelő kezelése

A megszakítási műveletek kódolása nehéz lehet, mert általában aszinkron módon futnak. A megszakítási műveleteket kezelő kód problémái hosszú ideig észrevétlenek lehetnek, mivel ezt a kódot általában nem gyakran hajtják végre egy futó rendszerben. Mindenképpen olvassa el és ismerje meg a IrP-k megszakításacímű témakörben megadott összes információt. Különös figyelmet kell fordítani az IRP-lemondások szinkronizálására és az IRP-lemondáskor figyelembe veendő szempontokra.

A megszakítási műveletekhez kapcsolódó szinkronizálási problémák minimalizálásának egyik ajánlott módja egy megszakításmentes IRP-üzenetsorimplementálása.

Az IRP-karbantartás és a műveletek megfelelő bezárása

Ügyeljen arra, hogy megértse a IRP_MJ_CLEANUP és IRP_MJ_CLOSE kérések közötti különbséget. A törlési kérelmek akkor érkeznek meg, ha egy alkalmazás bezárja egy fájlobjektum összes leíróját, de néha még az összes I/O-kérés befejeződése előtt. A kérelmek bezárása a fájlobjektumra vonatkozó összes I/O-kérés befejezése vagy megszakítása után érkezik. További információ:

DispatchCreate, DispatchClose és DispatchCreateClose rutinok

DispatchCleanup rutinok

Hibák a tisztítási és bezárási műveletek kezelésében

További információ az IRP-k helyes kezeléséről: További hibák az IRP-k kezelésében.

Használj biztonságos függvényeket

Egyéb biztonsági problémák

  • A versenyfeltételek elkerülése érdekében használjon zárolást vagy egymáshoz kapcsolt sorozatot. További információ: Többprocesszoros környezet hibái.

  • Győződjön meg arról, hogy a telepítés vagy használat során az illesztőprogram vagy a kapcsolódó szoftvercsomagok nem telepítettek hálózati átviteli illesztőprogram-szűrőket vagy rétegzett szolgáltatókat (LSP-ket). Ehelyett használjon modern API-kat, például a Windows szűrőplatformot (WFP) .

További kódszintű biztonsági rések

Az itt ismertetett lehetséges biztonsági réseken kívül ez a cikk további információkat is tartalmaz a kernel módú illesztőprogram-kód biztonságának növeléséről: Megbízható Kernel-Mode illesztőprogramok létrehozása.

A C és C++ biztonságos kódolásáról a cikk végén Biztonságos kódolási erőforrások című cikkben talál további információt.

HVCI-kompatibilis kód implementálása

6. biztonsági ellenőrzőlistaelem:Ellenőrizze, hogy az illesztőprogram memóriát használ-e, hogy HVCI-kompatibilis legyen.

Memóriaintegritás és HVCI-kompatibilitás

A memória integritása, más néven Hypervisor által védett kódintegritás (HVCI) hardvertechnológiával és virtualizálással elkülöníti a kódintegritási (CI) döntési függvényt az operációs rendszer többi részétől. Ha virtualizációalapú biztonságot használ a CI elkülönítésére, a kernelmemória csak ci-ellenőrzéssel válhat végrehajthatóvá. Ez azt jelenti, hogy a kernel memórialapjai soha nem írhatók és végrehajthatóak (W+X), és a végrehajtható kód nem módosítható közvetlenül.

A HVCI-kompatibilis kód implementálásához győződjön meg arról, hogy az illesztőprogram kódja a következő:

  • Alapértelmezés szerint az NX-et választja
  • NX API-kat/jelzőket használ a memóriafoglaláshoz (NonPagedPoolNx)
  • Nem használ írható és végrehajtható szakaszokat
  • Nem próbálja meg közvetlenül módosítani a végrehajtható rendszermemóriát
  • Nem használ dinamikus kódot a kernelben
  • Nem tölt be adatfájlokat végrehajtható fájlként
  • A szakaszigazítás a 0x1000 (PAGE_SIZE) többszöröse. Például DRIVER_ALIGNMENT=0x1000

Az eszköz használatáról és a nem kompatibilis memóriahívások listájáról további információt HVCI-kompatibilis kód implementálásacímű témakörben talál.

A kapcsolódó rendszerbiztonsági teszttel kapcsolatos további információkért lásd HyperVisor Code Integrity Readiness Test és Hypervisor-Protected Code Integrity (HVCI).

Az eszköztelepítés biztonságának javítása

7. biztonsági ellenőrzőlista-elem:Tekintse át az illesztőprogram inf létrehozásának és telepítésének útmutatóját, hogy biztosan kövesse az ajánlott eljárásokat.

Amikor létrehozza az illesztőprogram-csomagot telepítő kódot, győződjön meg arról, hogy az eszköz telepítése mindig biztonságos módon történik. A biztonságos eszköztelepítés a következő:

  • Az eszközhöz és az eszköz interfészosztályaihoz való hozzáférés korlátozása
  • Korlátozza az eszközhöz létrehozott illesztőprogram-szolgáltatásokhoz való hozzáférést
  • Az illesztőprogram-fájlok módosítása és törlése elleni védelem
  • Az eszköz beállításjegyzék-bejegyzéseihez való hozzáférés korlátozása
  • Az eszköz WMI-osztályaihoz való hozzáférés korlátozása
  • A SetupAPI függvények helyes használata

További információ:

Biztonságos eszköztelepítések létrehozása

SetupAPI- használatának irányelvei

Eszköztelepítési függvények használata

Eszköz- és illesztőprogram-telepítés – speciális témakörök

A technológiaspecifikus kódokkal kapcsolatos ajánlott eljárások követése

8. biztonsági ellenőrzőlista-elem:Tekintse át az illesztőprogramra vonatkozó alábbi technológiaspecifikus útmutatást.

Fájlrendszerek

További információ a fájlrendszer-illesztőprogramok biztonságáról:

Bevezetés a fájlrendszerek biztonságába

fájlrendszer biztonsági problémái

Fájlrendszerek biztonsági funkciói

más fájlrendszerszűrő-illesztőprogramokkal való együttélés

Microsoft Virus Initiative

A Microsoft Virus Initiative (MVI) segítségével a szervezetek fejleszthetik azokat a biztonsági megoldásokat, amelyekre ügyfeleink támaszkodnak, hogy biztonságban maradjanak. A Microsoft olyan eszközöket, erőforrásokat és ismereteket biztosít, amelyek nagy teljesítménnyel, megbízhatósággal és kompatibilitással támogatják a jobb együttélés élményét. A Microsoft az MVI-partnerekkel együttműködve határozza meg és követi a biztonságos üzembehelyezési eljárásokat (SDP) a kölcsönös ügyfeleink biztonságának és rugalmasságának támogatása érdekében.

Ha Ön víruskereső gyártó, tekintse meg Microsoft Virus Initiative, amelyből megtudhatja, hogyan csatlakozhat az MVI-hez a szoftvertelepítéssel kapcsolatos további segítségért. További információ arról, hogy a biztonsági szállítók hogyan tudják jobban kihasználni a Windows integrált biztonsági képességeit a nagyobb biztonság és megbízhatóság érdekében, lásd ajánlott Windows biztonsági eljárásokat a biztonsági eszközökintegrálásához és kezeléséhez.

NDIS – Hálózatkezelés

További információ az NDIS-illesztőprogramok biztonságáról: Hálózati illesztőprogramok biztonsági problémái.

Nyomtatók

A nyomtatóillesztők biztonságával kapcsolatos információkért tekintse meg V4 nyomtatóillesztő biztonsági szempontjait.

Biztonsági problémák a Windows rendszerkép-beszerzési (WIA) illesztőprogramjaival kapcsolatban

További információ a WIA biztonságáról: Windows rendszerkép-beszerzési (WIA) illesztőprogramok biztonsági problémái.

SAL-széljegyzetek hozzáadása az illesztőprogram kódjához

9. biztonsági ellenőrzőlista-elem:SAL-széljegyzetek hozzáadása az illesztőprogram kódjához.

A forráskód széljegyzetnyelve (SAL) olyan széljegyzeteket biztosít, amelyekkel leírhatja, hogy egy függvény hogyan használja a paramétereit, milyen feltételezéseket állít elő róluk, és milyen garanciákat biztosít a befejezéskor. A széljegyzetek sal.hfejlécfájlban vannak definiálva. A C++ Visual Studio kódelemzése SAL-széljegyzetekkel módosítja a függvények elemzését. További információ a Windows illesztőprogram-fejlesztéshez készült SAL 2.0-s verzióról: Windows-illesztőprogramok SAL 2.0-s széljegyzetei és A C/C++ kódhibák csökkentése.

A SAL-ról az OSR-ből elérhető cikkben talál általános információkat. SAL széljegyzetek: Ne utálj, mert gyönyörű vagyok

Kód áttekintése kollégákkal

10. biztonsági ellenőrzőlista-elem:Társkód-ellenőrzés végrehajtása, a többi eszköz és folyamat által nem feltárt problémák kereséséhez

Keressen hozzáértő kódellenőröket, hogy megtalálja azokat a problémákat, amelyeket esetleg elmulasztott. Egy második személy gyakran észreveszi a problémákat, amelyeket esetleg figyelmen kívül hagyott.

Ha nem rendelkezik megfelelő személyzettel a kód belső áttekintéséhez, fontolja meg külső segítség bevonását erre a célra.

Fenyegetéselemzés végrehajtása

11. biztonsági ellenőrzőlista-elem:Módosítsa a meglévő illesztőprogram-fenyegetésmodellt, vagy hozzon létre egy egyéni fenyegetésmodellt az illesztőprogramhoz.

A biztonság szempontjából gyakori módszer az olyan konkrét fenyegetésmodellek létrehozása, amelyek megkísérlik leírni a lehetséges támadástípusokat. Ez a technika azért hasznos egy illesztőprogram tervezésekor, mert arra kényszeríti a fejlesztőt, hogy előre mérlegelje a potenciális támadási vektorokat egy illesztőprogram ellen. Miután azonosította a lehetséges fenyegetéseket, az illesztőprogram-fejlesztő ezután megfontolhatja a fenyegetések elleni védelem eszközeit, hogy megerősítse az illesztőprogram-összetevő általános biztonságát.

Ez a cikk illesztőprogram-specifikus útmutatást nyújt egy egyszerűsített fenyegetésmodell létrehozásához: Illesztőprogramok fenyegetésmodellezése. A cikk egy példa illesztőprogram-fenyegetésmodell-diagramot tartalmaz, amely kiindulópontként használható az illesztőprogramod számára.

Minta adatfolyam-diagram, amely egy hipotetikus kernel módú illesztőprogramot szemléltet.

A biztonsági fejlesztési életciklus (SDL) ajánlott eljárásait és a kapcsolódó eszközöket az IHV-k és az oem-ek használhatják termékeik biztonságának javítása érdekében. További információ: oem-ekre vonatkozó SDL-javaslatok.

Az illesztőprogram kódját a CodeQL használatával ellenőrizheti

biztonsági ellenőrzőlista 12. eleme:A CodeQL használatával ellenőrizze az illesztőprogram kódjának biztonsági réseit.

A GitHub által készített CodeQL egy szemantikai kódelemző motor, és a biztonsági lekérdezések széles választékának és egy robusztus platformnak a kombinációja értékes eszközzé teszi az illesztőprogram-kód biztonságossá tételét. További információért lásd a CodeQL és a Static Tools Logo Test.

Biztonsági rések keresése az Illesztőprogram-ellenőrző használatával

biztonsági ellenőrzőlista 13. eleme:Illesztőprogram-ellenőrző használata az illesztőprogram-kód biztonsági réseinek ellenőrzéséhez.

Az Illesztőprogram-ellenőrző felületi szabályok és az operációs rendszer modellje alapján határozza meg, hogy az illesztőprogram megfelelően kommunikál-e a Windows operációs rendszerrel. A Driver Verifier olyan illesztőprogram-kódhibákat talál, amelyek az illesztőprogramok lehetséges hibáira mutathatnak.

A Driver Verifier lehetővé teszi az illesztőprogram élő tesztelését. Az Illesztőprogram-ellenőrző figyeli a Windows kernelmódú illesztőprogramjait és grafikus illesztőprogramjait, hogy észlelje a rendszer sérülését okozó szabálytalan függvényhívásokat vagy műveleteket. Csatolt hibakereső, amely lehetővé teszi az operációs rendszer és az illesztőprogram kódjának valós idejű végrehajtását. A Driver Verifier számos stressznek és tesztnek vetheti alá a Windows-illesztőprogramokat, hogy helytelen viselkedést találjon. További információ: Driver Verifier.

A Driver Verifer WDM- és KMDF-illesztőprogramokkal is működik. Az ellenőrzésre vonatkozó részletekért tekintse meg az alábbi témaköröket.

Az illesztőprogram-ellenőrző által használható illesztőprogramokról további információt DDI megfelelőségi szabályok és támogatott illesztőprogramokcímű cikkben talál. Az egyes illesztőprogram-típusokra vonatkozó további ellenőrző szabályokért lásd:

A DV megismeréséhez használhatja az egyik mintavezetőt (például a kiemelt kenyérpirító minta: https://github.com/Microsoft/Windows-driver-samples/tree/main/general/toaster/toastDrv/kmdf/func/featured).

Kód ellenőrzése a hardverkompatibilitási program tesztjeivel

biztonsági ellenőrzőlista 14. eleme:A biztonsági problémák ellenőrzéséhez használja a hardverkompatibilitási program biztonsági tesztjeit.

A hardverkompatibilitási program biztonsági teszteket tartalmaz a kód biztonsági réseinek kereséséhez. A Windows hardverkompatibilitási programja a Windows Hardware Lab Kit (HLK) tesztjeit használja. A HLK-eszköz alapszintű tesztjei a parancssorban használhatók az illesztőprogram kódjának gyakorlásához és a gyengeség vizsgálatához. Az eszköz alapvető tesztjeiről és a hardverkompatibilitási programról az Windows Hardware Lab Kitcímű témakörben olvashat.

Az alábbi tesztek olyan tesztekre mutatnak be példákat, amelyek hasznosak lehetnek az illesztőprogram kódjának ellenőrzéséhez a kód biztonsági réseivel kapcsolatos bizonyos viselkedések esetében:

DF – Fuzz véletlenszerű IOCTL-teszt (megbízhatóság)

DF – Fuzz alnyitási teszt (megbízhatóság)

DF – Nulla hosszúságú puffer FSCTL tesztelése fuzzing módszerrel (Megbízhatóság)

DF – Véletlenszerű FSCTL-teszt (Megbízhatóság)

DF – Fuzz Misc API-teszt (megbízhatóság)

A Driver Verifier részévé tartozó kernel szinkronizáció késleltetési fuzzing is használható.

A CHAOS (egyidejű hardver és operációs rendszer) tesztek egyszerre futtatnak különböző PnP-illesztőprogram-teszteket, eszközillesztő fuzz teszteket és power system-teszteket. További információ: CHAOS-tesztek (eszköz alapjai).

Az eszköz alapvető behatolási tesztjei a bemeneti támadások különböző formáit hajtják végre, amelyek a biztonsági tesztelés kritikus összetevői. A támadás- és behatolástesztelés segíthet azonosítani a szoftverfelületek biztonsági réseit. További információ: Behatolástesztek (Eszköz alapjai).

A cikkben ismertetett egyéb eszközökkel együtt használja a Device Guard – Megfelelőségi tesztannak ellenőrzéséhez, hogy az illesztőprogram HVCI-kompatibilis-e.

Egyéni és tartományspecifikus teszteszközök

Fontolja meg az egyéni tartományspecifikus biztonsági tesztek fejlesztését. További tesztek fejlesztéséhez gyűjtsön bemenetet a szoftver eredeti tervezőitől, valamint a fejlesztés alatt álló illesztőprogram típusát ismerő nem kapcsolódó fejlesztési erőforrásoktól, valamint egy vagy több, a biztonsági behatolás elemzésével és megelőzésével foglalkozó személytől.

Ellenőrizze, hogy készen áll-e a vezetők szállítására olyan eszközökkel, mint a BinSkim és a SignTool

15. biztonsági ellenőrzőlista-elem:A lefordított kód ellenőrzése az olyan eszközökkel, mint a BinSkim és a SignTool, mielőtt feltöltené a partnerközpontba.

Használjon olyan eszközöket, mint a BinSkim és a SignTool, hogy megvizsgálja a bináris fájlokat, és ellenőrizze a lefordított kódot, mielőtt feltöltené a partnerközpontba a Windows Update használatával való terjesztésre. Ha rendelkezik a lefordított bináris fájlok ellenőrzéséhez szükséges eszközökkel, mielőtt terjesztésre küldené őket, egy másik védelmi réteget ad hozzá.

BinSkim

A BinSkim képes azonosítani azokat a kódolási és építési eljárásokat, amelyek sebezhetővé tehetik a bináris fájlokat. A BinSkim a következőt ellenőrzi:

  • Elavult fordítóeszközkészletek használata – A bináris fájlokat a legújabb fordítóeszközkészletek alapján kell összeállítani, ahol csak lehetséges, a jelenlegi fordítószintű és operációs rendszer által biztosított biztonsági megoldások maximális kihasználása érdekében.
  • Nem biztonságos fordítási beállítások – A bináris fájlokat a lehető legbiztonságosabb beállításokkal kell összeállítani, hogy lehetővé tegyék az operációs rendszer által biztosított biztonsági kockázatcsökkentéseket, maximalizálják a fordítóhibákat és a végrehajtható figyelmeztetéseket, többek között.
  • Aláírási problémák – Az aláírt bináris fájlokat kriptográfiailag erős algoritmusokkal kell aláírni.

A BinSkim egy nyílt forráskódú eszköz, és olyan kimeneti fájlokat hoz létre, amelyek a Static Analysis Results Interchange Format (SARIF) formátumot használják. A BinSkim lecseréli a korábbi BinScope eszközt.

További információ a BinSkimről: Bináris fájlok ellenőrzése a BinSkim használatával és a BinSkim felhasználói útmutató.

SignTool

A SignTool használatával ellenőrizze a kiadás által aláírt illesztőprogram-fájlokat. További információért lásd: az Release-Signed meghajtó fájl aláírásának ellenőrzése-t és a kereskedelmi kiadási tanúsítvány által aláírt katalógusfájl aláírásának ellenőrzése-et.

Ne használja a tesztkódot éles környezetben

16. biztonsági ellenőrzőlista-elem:Ne legyen éles kódjelek fejlesztése, tesztelése és gyártási kernelillesztő-kód.

A fejlesztéshez, teszteléshez vagy gyártáshoz használt kernelillesztő-kód biztonsági kockázatot jelentő veszélyes képességeket is tartalmazhat. Ezt a veszélyes kódot soha nem szabad olyan tanúsítvánnyal aláírni, amelyet a Windows megbízható. A veszélyes illesztőprogram-kód végrehajtásának megfelelő mechanizmusa az UEFI Biztonságos rendszerindítás letiltása, a BCD "TESTSIGNING" engedélyezése, valamint a fejlesztési, tesztelési és gyártási kód aláírása nem megbízható tanúsítvány használatával (például makecert.exeáltal létrehozott).

A megbízható szoftverkiadói tanúsítvány (SPC) vagy a Windows Hardverminőségi tesztkörnyezetek (WHQL) aláírásával aláírt kód nem segítheti a Windows kódintegritási és biztonsági technológiáinak megkerülését. Mielőtt megbízható SPC- vagy WHQL-aláírással írna alá kódot, először győződjön meg arról, hogy megfelel Megbízható Kernel-Mode illesztőprogramok létrehozásacímű cikk útmutatásának. Ezenkívül a kód nem tartalmazhat veszélyes viselkedést, az alábbiakban leírtak szerint.

A veszélyes viselkedésre példák a következők:

  • Lehetővé teszi tetszőleges kernel-, fizikai vagy eszközmemória felhasználói módra való leképezését.
  • Lehetővé teszi tetszőleges kernel, fizikai vagy eszközmemória olvasását vagy írását, beleértve a portbemenetet/kimenetet (I/O).
  • A Windows hozzáférés-vezérlését megkerülő tárterülethez való hozzáférés biztosítása.
  • Lehetővé teszi az illesztőprogram által nem felügyelt hardver vagy belső vezérlőprogram módosítását.

A megfelelő kiadási illesztőprogram aláírásának végrehajtása és az illesztőprogram-csomag terjesztése a Windows Update használatával

17. biztonsági ellenőrzőlista-elem:A Windows partnerportál használatával küldje el az illesztőprogram-csomagot, amelyet a Windows Update használatával szeretne aláírni és terjeszteni.

Mielőtt közzétennénk egy illesztőprogram-csomagot a nyilvánosság számára, elküldheti a csomagot minősítésre. További információ: Teljesítmény- és kompatibilitási teszt és A hardverprogram használatának első lépései.

A Windows Update használata erősen ajánlott az illesztőprogram-csomagok terjesztéséhez. A Windows Update robusztus, biztonságos, globálisan skálázott és szabályozásilag megfelelő terjesztési rendszert biztosít, amelyet az illesztőprogram-frissítések továbbításához kell használni. További információ: Illesztőprogram-csomag terjesztése.

A windowsos hardveres Partnerközpontban fokozatos bevezetést és illesztőprogram-repülési használhatja az illesztőprogram-csomag meghatározott Windows Insider-körökön belüli elosztásához, miközben automatikus monitorozást és kiértékelést biztosít. Az illesztőprogram bevezetésének monitorozása a microsoftos illesztőprogramokhasználatával, például Kernel módú összeomlás nélküli gépek százalékos aránya a minőség fenntartása érdekében.

A biztonságos szoftvertelepítési eljárások leírását a CISA Biztonságos szoftvertelepítés: Hogyan biztosíthatják a szoftvergyártók a megbízhatóságot az ügyfelek számára.

Az illesztőprogramok bejelentésének módjának megértése a Microsoft Sebezhető és Rosszindulatú Illesztőprogramok Jelentési Központ használatával

18. biztonsági ellenőrzőlistaelem: Az illesztőprogramok jelentésének ismertetése a Microsoft sebezhető és rosszindulatú illesztőprogramok jelentési központjának

Bárki elküldhet egy megkérdőjelezhető illesztőprogramot a Microsoft sebezhető és rosszindulatú illesztőprogramok jelentési központjának. Ebből a blogbejegyzésből megtudhatja, hogyan küldik el az illesztőprogramokat elemzésre – A rendszermag biztonságának javítása az új Microsoft sebezhető és rosszindulatú illesztőprogram-jelentéskészítő központtal

A Jelentéskészítő központ képes az x86- és x64-architektúrákhoz készült Windows-illesztőprogramok vizsgálatára és elemzésére. A sebezhető és rosszindulatú illesztőprogramokat a Microsoft sebezhető illesztőprogram-csapata elemzésre és vizsgálatra jelöli ki. A sebezhető illesztőprogramok megerősítése után megfelelő értesítés történik, és hozzáadja őket a sebezhető illesztőprogramok tiltólistájához. Erről további információt Microsoft által javasolt illesztőprogram-blokkolási szabályokcímű témakörben talál. Ezek a szabályok alapértelmezés szerint a Hypervisor által védett kódintegritási (HVCI) kompatibilis eszközökre és A Windows 10 S módban vannak alkalmazva.

Biztonságos kódolási erőforrások áttekintése

biztonsági ellenőrzőlista 19. eleme:Tekintse át ezeket az erőforrásokat, hogy jobban megismerje az illesztőprogram-fejlesztőkre vonatkozó ajánlott biztonságos kódolási eljárásokat.

Útmutató a Microsoft NISTIR 8397-hez

Az Egyesült Államok kormányának kiadványa, a NISTIR 8397: Útmutató a fejlesztők szoftverellenőrzésének minimális szabványaira, amelyet a Szabványügyi és Technológiai Nemzeti Intézet (NIST) adott ki, útmutatást nyújt a megbízható és biztonságos szoftverek létrehozásához bármilyen programozási nyelven.

Megbízható és biztonságos C++ programok létrehozása összefoglalja, hogyan használhat microsoftos fejlesztői termékeket a C++ és más nyelvek számára a NISTIR 8397 irányelveinek követéséhez.

A NIST ismert szoftver sebezhetőségi adatbázisa

A nemzeti biztonságirés-adatbázis (NVD) a biztonsággal kapcsolatos szoftverhibák, köztük a Windows-illesztőprogramok kereshető adattára.

Keresse a NIST sebezhetőségi adatbázist

Nemzeti Sérülékenységi Adatbázis áttekintése

Biztonságos kódolási szabványok

Carnegie Mellon University SEI CERT - C kódolási szabvány: Szabályok a biztonságos, megbízható és védett rendszerek (PDF).

MITRE – A CERT C Secure Coding Standard által kezelt hiányosságok

Microsoft Visual Studio – A C++ alapvető irányelvek ellenőrzőinek használata

Biztonságos kódolási szervezetek

Kiberbiztonsági és Infrastruktúra Biztonsági Ügynökség (CISA)

CISA-erőforrások

Carnegie Mellon Egyetem SEI CERT

SAFECode

OSR

OSR illesztőprogram-fejlesztési képzési és tanácsadási szolgáltatásokat nyújt. Az OSR hírlevélben található cikkek az illesztőprogramok biztonsági problémáit emelik ki.

Nevek, biztonsági leírók és eszközosztályok – Eszközobjektumok hozzáférhetővé tétele... és biztonságos

Védeni kell magát – sofőr eszközbiztonság belül &

Illesztőprogramok zárolása – Technikák áttekintése

Meltdown és Spectre: Mi a helyzet az illesztőprogramokkal?

Az illesztőprogram biztonsági résének esettanulmánya

Riasztástól az illesztőprogram sebezhetőségig: A Microsoft Defender ATP vizsgálat feltárja a jogosultságok eszkalációs hibáját

A szoftverellátási lánc biztonsága és a szoftveres anyagjegyzék (SBOM-ek)

Az SBOM-ek felsorolják azokat az összetevőket, amelyeket egy szoftver létrehozásakor használnak, például nyílt forráskódú szoftvereket, összetevőket és akár buildelési eszközöket is. Ez lehetővé teszi a gyártók és a fogyasztók számára a jobb leltározást és a licenc- és sebezhetőségi kockázat kiértékelését. A Microsoft SBOM-dokumentumformátumként használja az SPDX -. További információkért lásd: Szoftverjegyzékek (SBOM) létrehozása SPDX használatával a Microsoftnál és a Microsoft nyílt forráskódú szoftverjegyzék-létrehozási eszközét.

Az ellátási lánc integritása, átláthatósága és megbízhatósága (SCITT) kezdeményezés az IETF internetes szabványkészlete, amely az áruk és szolgáltatások teljes körű ellátási láncok közötti megfelelőségének kezelésére használható. Az SCITT támogatja az áruk és szolgáltatások folyamatos ellenőrzését, ahol biztosítható az entitások, bizonyítékok, szabályzatok és összetevők hitelessége, és az entitások tevékenységei garantáltan engedélyezettek, nem kifogásolhatók, nem módosíthatók és ellenőrizhetők.

Könyvek

A szoftverbiztonság 24 halálos bűne: programozási hibák és azok javítási módjai Michael Howard, David LeBlanc és John Viega

A Biztonságos Szoftver Írása, Második Kiadás, Michael Howard és David LeBlanc írása

A szoftverbiztonsági értékelés művészete: A szoftveres biztonsági rések azonosítása és megelőzése, Mark Dowd, John McDonald és Justin Schuh

Secure Coding in C and C++ (SEI Series in Software Engineering) 2nd Edition, Robert C. Seacord

A Microsoft Windows-illesztőprogram modell programozása (2. kiadás), Walter Oney

Illesztőprogramok fejlesztése a Windows Driver Foundation (fejlesztői referencia), Penny Orwick és Guy Smith használatával

Képzés

A Windows-illesztőprogramok osztálytermi képzése az alábbihoz hasonló gyártóktól érhető el:

A biztonságos kódolás online képzése számos forrásból elérhető. Például ez a kurzus elérhető a Coursera platformon:

A C/C++programozás biztonsági réseinek azonosítása.

A SAFECode ingyenes képzést is kínál:

SAFECode.org/training

Szakmai minősítés

A CERT kínál egy Biztonságos Kódolási Szakemberi Minősítést.

A legfontosabb elvitelek összegzése

A vezetőbiztonság egy összetett vállalkozás, amely számos elemet tartalmaz, de íme néhány fontos szempont:

  • Az illesztőprogramok a Windows kernelben élnek, és a kernelben történő futtatáskor felmerülő probléma az egész operációs rendszert veszélyezteti. Emiatt fokozott figyelmet kell fordítani a vezetők biztonságára, és a tervezéskor a biztonságot kell szem előtt tartani.

  • Alkalmazza a minimális jogosultság elvét:

    egy. Szigorú SDDL-sztring használata az illesztőprogramhoz való hozzáférés korlátozásához

    b. Az egyes IOCTL-ek további korlátozása

  • Hozzon létre egy fenyegetésmodellt a támadási vektorok azonosításához, és fontolja meg, hogy bármi korlátozható-e tovább.

  • Legyen óvatos a felhasználói módból érkező beágyazott mutatókkal kapcsolatban. Meg kell vizsgálni őket, és try-except blokkokban kell hozzáférni, különben hajlamosak a "ellenőrzési idő és felhasználási idő" (ToCToU) problémáira, kivéve, ha a puffer értékét rögzítik és összehasonlítják.

  • Ha bizonytalan, válassza pufferelési módszerként a METHOD_BUFFERED IOCTL-t.

  • Használjon kódolvasó segédprogramokat, például a CodeQL-t az ismert kódhibák kereséséhez és az azonosított problémák elhárításához.

  • Keressen hozzáértő kódellenőröket, hogy megtalálja azokat a problémákat, amelyeket esetleg elmulasztott.

  • Használjon illesztőprogram-ellenőrzőket, és tesztelje az illesztőprogramot különböző bemenetekkel, beleértve a sarkalatos eseteket is.

  • Last updated on