Controlelijst voor driverbeveiliging

Dit artikel bevat een controlelijst voor stuurprogrammabeveiliging voor ontwikkelaars van stuurprogramma's om het risico te verminderen dat stuurprogramma's worden aangetast. De beveiliging van drivers is cruciaal en heeft directe invloed op de betrouwbaarheid. Wanneer Windows detecteert dat er onjuiste geheugentoegang plaatsvindt, wordt het besturingssysteem afgesloten en wordt er een blauw foutscherm weergegeven. Als Windows-partner moet u werken om de aanzienlijke impact te verminderen die een mislukt stuurprogramma heeft op het leven van onze klanten.

Voor meer informatie over de voordelen van het bieden van een veilig en betrouwbaar stuurprogramma, zie Richtlijnen voor stuurprogrammabeveiliging.

Overzicht van driverbeveiliging

Een beveiligingsfout is een fout die een aanvaller in staat stelt om een stuurprogramma zodanig te laten functioneren dat een aanvaller onbevoegde toegang kan krijgen, het systeem kan manipuleren of gegevens in gevaar kan brengen, waardoor het systeem vastloopt of onbruikbaar wordt. Bovendien kunnen beveiligingsproblemen in stuurprogrammacode een aanvaller toegang geven tot de kernel, waardoor het hele besturingssysteem in gevaar kan komen.

Wanneer de meeste ontwikkelaars aan hun stuurprogramma werken, is hun focus op het goed werken van het stuurprogramma en niet op het feit of een kwaadwillende aanvaller probeert misbruik te maken van beveiligingsproblemen in hun code. Nadat een stuurprogramma is vrijgegeven, kunnen aanvallers echter proberen beveiligingsfouten te onderzoeken en te identificeren. Ontwikkelaars moeten deze problemen overwegen tijdens de ontwerp- en implementatiefase om de kans op dergelijke beveiligingsproblemen te minimaliseren. Het doel is om alle bekende beveiligingsfouten te elimineren voordat het stuurprogramma wordt vrijgegeven.

Het creëren van veiligere stuurprogramma's vereist de samenwerking van de systeemarchitect (bewust denken aan mogelijke bedreigingen voor de bestuurder), de ontwikkelaar die de code implementeert (defensieve codering van veelvoorkomende bewerkingen die de bron van aanvallen kunnen zijn) en het testteam (proactief proberen zwakke plekken en beveiligingsproblemen te vinden). Door al deze activiteiten goed te coördineren, wordt de veiligheid van de bestuurder aanzienlijk verbeterd.

Naast het voorkomen van de problemen die zijn gekoppeld aan een stuurprogramma dat wordt aangevallen, zullen veel van de beschreven stappen, zoals nauwkeuriger gebruik van kernelgeheugen, de betrouwbaarheid van uw stuurprogramma verhogen. Dit vermindert de ondersteuningskosten en verhoogt de klanttevredenheid met uw product. Als u de taken in de onderstaande controlelijst voltooit, kunt u al deze doelen bereiken.

Beveiligingscontrolelijst:Voltooi de beveiligingstaak die in elk van deze onderwerpen wordt beschreven.

Bevestigen dat een kernelstuurprogramma nodig is

Gebruik de stuurprogrammaframeworks

Stuurprogramma-toegangsbeheer beheren

Beperk toegang tot alleen softwarestuurprogramma's

Volg de richtlijnen voor veilig coderen van stuurprogramma's

HVCI-compatibele code implementeren

volg de best practices voor technologie-specifieke code

SAL-aantekeningen toevoegen aan de stuurprogrammacode

Peer Code Controleren

Uitvoeren van bedreigingsanalyse

Gebruik CodeQL om uw stuurprogrammacode te controleren

Stuurprogrammacontrole gebruiken om te controleren op beveiligingsproblemen

Code controleren met tests van het hardwarecompatibiliteitsprogramma

Controleer kant-en-klare stuurprogramma's met tools zoals BinSkim en SignTool

Test-stuurprogrammacode niet voor productie ondertekenen

Voer de juiste ondertekening van releasestuurprogramma's uit en distribueer uw stuurprogrammapakket met behulp van Windows Update

Begrijpen hoe stuurprogramma's worden gerapporteerd met het Rapportagecentrum voor kwetsbare en schadelijke stuurprogramma's van Microsoft

Beveiligingscoderingsbronnen bekijken

Bekijk de samenvatting van de belangrijkste punten

Controleer of een kernelstuurprogramma is vereist

Veiligheidscontrolelijst item #1:Bevestig dat een kernelstuurprogramma nodig is en dat een benadering met minder risico, zoals een Windows-service of app, geen betere optie is.

Kernelstuurprogramma's bevinden zich in de Windows-kernel; als er een probleem optreedt tijdens de uitvoering in de kernel, wordt het hele besturingssysteem blootgesteld aan risico's. Als er een andere optie beschikbaar is, zal deze waarschijnlijk minder kosten en minder risico met zich meebrengen dan het creëren van een nieuw kernelstuurprogramma.

Zie Wilt u een stuurprogramma schrijven voor meer informatie over het gebruik van de ingebouwde Windows-stuurprogramma's?.

Zie Uw app ondersteunen met achtergrondtakenvoor meer informatie over het gebruik van achtergrondtaken.

Zie Servicesvoor meer informatie over het gebruik van Windows Services.

De stuurprogrammaframeworks gebruiken

controlelijstitem beveiliging #2:Gebruik de frameworks voor stuurprogramma's om de grootte van uw code te verkleinen en de betrouwbaarheid en beveiliging te vergroten.

Gebruik de Windows Driver Frameworks om de grootte van uw code te verkleinen en de betrouwbaarheid en beveiliging te vergroten. Om aan de slag te gaan, bekijk WDF gebruiken om een stuurprogramma te ontwikkelen. Zie Een stuurprogrammamodel kiezenvoor meer informatie over het gebruik van het Stuurprogrammaframework voor de gebruikersmodus met een lager risico.

Het schrijven van een ouderwets Windows Driver Model (WDM) stuurprogramma is tijdrovender, kostbaar en omvat het opnieuw maken van code die beschikbaar is in de stuurprogrammaframeworks.

De WDF-broncode (Windows Driver Framework) is open source en beschikbaar op GitHub. Dit is dezelfde WDF-broncode die wordt geleverd in Windows. U kunt fouten in uw stuurprogramma effectiever opsporen wanneer u de interacties tussen het stuurprogramma en WDF kunt volgen. Download het van https://github.com/Microsoft/Windows-Driver-Frameworks.

DMF - Driver Module Framework

Overweeg het gebruik van Driver Module Framework (DMF) in uw stuurprogrammaproject. DMF is ontwikkeld door het Microsoft Surface-team en is een framework waarmee WDF-objecten met de naam DMF-modules kunnen worden gemaakt. De code voor deze DMF-modules kan worden gedeeld tussen verschillende stuurprogramma's. Daarnaast biedt DMF een bibliotheek met DMF-modules die zijn ontwikkeld voor stuurprogramma's en codehergebruik bieden voor taken zoals thread- en I/O-beheer. Een DMF-module wordt gebruikt voor het inkapselen van stuurprogrammataken in kleinere eenheden. Elke module is zelfstandig en heeft zijn eigen code, context en callbacks, waardoor u deze eenvoudiger kunt hergebruiken. Voor meer informatie, zie Introducing Driver Module Framework en de GitHub site documentation.

Toegangsbeheer voor stuurprogramma's beheren

Veiligheidscontrolelijst item #3:Controleer uw softwaredriver om ervoor te zorgen dat u de toegang goed beheert.

Toegangsbeheer voor stuurprogramma's beheren - WDF

Stuurprogramma's moeten werken om te voorkomen dat gebruikers ongepast toegang hebben tot de apparaten en bestanden van een computer. Als u onbevoegde toegang tot apparaten en bestanden wilt voorkomen, moet u het volgende doen:

• Geef apparaatobjecten alleen een naam wanneer dat nodig is. Benoemde apparaatobjecten zijn over het algemeen alleen nodig om verouderde redenen, bijvoorbeeld als u een toepassing hebt die verwacht het apparaat te openen met een bepaalde naam of als u een niet-PNP-apparaat/beheerapparaat gebruikt. WDF-stuurprogramma's hoeven hun PnP-apparaat FDO niet te benoemen om een symbolische koppeling te maken met behulp van WdfDeviceCreateSymbolicLink.

• Beveiligde toegang tot apparaatobjecten en -interfaces.

Als u wilt toestaan dat toepassingen of andere WDF-stuurprogramma's toegang hebben tot uw PnP-apparaat PDO, moet u apparaatinterfaces gebruiken. Voor meer informatie, zie Device Interfaces gebruiken. Een apparaatinterface fungeert als een symbolische koppeling naar de PDO van uw apparaatstack.

Een van de betere manieren om de toegang tot de PDO te beheren, is door een SDDL-tekenreeks op te geven in uw INF. Als de SDDL-tekenreeks zich niet in het INF-bestand bevindt, past Windows een standaardbeveiligingsdescriptor toe. Zie Apparaatobjecten beveiligen en SDDL voor apparaatobjectenvoor meer informatie.

Zie voor meer informatie over het beheren van de toegang:

Beheer van toegang tot apparaten in KMDF-stuurprogramma's

Namen, beveiligingsdescriptors en apparaatklassen - Apparaatobjecten toegankelijk maken... en VEILIG uit de januari februari 2017 The NT Insider Newsletter gepubliceerd door OSR.

Toegangsbeheer voor stuurprogramma's beheren - WDM

Als u met een WDM-stuurprogramma werkt en u een benoemd apparaatobject hebt gebruikt, kunt u IoCreateDeviceSecure- gebruiken en een SDDL opgeven om het te beveiligen. Altijd wanneer u IoCreateDeviceSecure implementeert, geeft u een aangepaste klasse-GUID voor DeviceClassGuid op. U moet hier geen bestaande klasse-GUID opgeven. Als u dit doet, is het mogelijk om beveiligingsinstellingen of compatibiliteit te verbreken voor andere apparaten die tot die klasse behoren. Zie WdmlibIoCreateDeviceSecurevoor meer informatie.

Zie voor meer informatie:

Apparaattoegang beheren

Toegang tot apparaatnaamruimten beheren

Windows-beveiligingsmodel voor ontwikkelaars van stuurprogramma's

Risicohierarchie beveiligingsidentificaties

In de volgende sectie wordt de risicohiërarchie beschreven van de algemene SID's die worden gebruikt in stuurprogrammacode. Zie SDDL voor apparaatobjecten, SID-tekenreeksenen SDDL-tekenreekssyntaxisvoor algemene informatie over SDDL.

Het is belangrijk te weten dat als bellers met een lagere bevoegdheid toegang hebben tot de kernel, het coderisico wordt verhoogd. In dit overzichtsdiagram neemt het risico toe naarmate u sid's met lagere bevoegdheden toegang geeft tot de functionaliteit van uw stuurprogramma.

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

Configureer op basis van het algemene beveiligingsprincipe met minimale bevoegdheden alleen het minimale toegangsniveau dat is vereist voor de werking van uw stuurprogramma.

WDM Granular IOCTL-beveiligingsbeheer

Een IOCTL (Input/Output Control) in Windows is een systeemaanroep voor apparaatspecifieke invoer-/uitvoerbewerkingen. IOCTL's worden door toepassingen gebruikt om te communiceren met apparaatstuurprogramma's, zodat ze opdrachten kunnen verzenden of informatie van de hardware kunnen aanvragen. Voor meer informatie, zie Introduction to I/O Control Codes en Example I/O Request - An Overview.

Als u de beveiliging verder wilt beheren wanneer IOCTLs worden verzonden door bellers in de gebruikersmodus, kan de stuurprogrammacode de IoValidateDeviceIoControlAccess--functie bevatten. Met deze functie kan een stuurprogramma toegangsrechten controleren. Bij ontvangst van een IOCTL kan een stuurprogramma IoValidateDeviceIoControlAccessoproepen, waarbij het FILE_READ_ACCESS, FILE_WRITE_ACCESS of beide specificeert.

Het implementeren van gedetailleerd IOCTL-beveiligingsbeheer vervangt niet de noodzaak om stuurprogrammatoegang te beheren met behulp van de hierboven besproken technieken.

Voor meer informatie, zie Definiëren van I/O-besturingscodes en Beveiligingsproblemen voor I/O-besturingscodes.

Toegang beheren tot stuurprogramma's die alleen voor software bedoeld zijn

beveiligingscontrolelijstitem #4:Als er een software-only stuurprogramma wordt gemaakt, moet extra toegangsbeheer worden geïmplementeerd.

Kernelstuurprogramma's met alleen software gebruiken geen plug-and-play (PnP) om te worden gekoppeld aan specifieke hardware-id's en kunnen worden uitgevoerd op elke pc. Een dergelijk stuurprogramma kan worden gebruikt voor andere doeleinden dan het oorspronkelijke doel, waardoor een aanvalsvector ontstaat.

Omdat kernelstuurprogramma's met alleen software extra risico's bevatten, moeten ze worden beperkt tot uitvoering op specifieke hardware, bijvoorbeeld door een unieke PnP-id te gebruiken om het maken van een PnP-stuurprogramma mogelijk te maken, of door de SMBIOS-tabel te controleren op de aanwezigheid van specifieke hardware.

Stel dat OEM Fabrikam een stuurprogramma wil distribueren dat een overklokprogramma voor hun systemen mogelijk maakt. Als dit alleen softwarestuurprogramma zou worden uitgevoerd op een systeem van een andere OEM, kan systeeminstabiliteit of schade tot gevolg hebben. De systemen van Fabrikam moeten een unieke PnP-id bevatten om het maken van een PnP-stuurprogramma mogelijk te maken dat ook kan worden bijgewerkt via Windows Update. Als dit niet mogelijk is en Fabrikam een verouderd stuurprogramma maakt, moet dat stuurprogramma een andere methode vinden om te controleren of het wordt uitgevoerd op een Fabrikam-systeem, bijvoorbeeld door de SMBIOS-tabel te onderzoeken voordat u mogelijkheden inschakelt.

Richtlijnen voor veilig coderen van stuurprogramma's volgen

beveiligingscontrolelijstitem #5:Controleer uw code en verwijder bekende beveiligingsproblemen met code.

De kernactiviteit van het maken van beveiligde stuurprogramma's is het identificeren van gebieden in de code die moeten worden gewijzigd om bekende beveiligingsproblemen met software te voorkomen. Veel van deze bekende beveiligingsproblemen in software houden zich bezig met het strikt bijhouden van het gebruik van geheugen om problemen te voorkomen door anderen die de geheugenlocaties overschrijven of anderszins compromitteren die uw stuurprogramma gebruikt.

Hulpprogramma's voor codescans, zoals CodeQL en stuurprogrammaspecifieke tests, kunnen worden gebruikt om te helpen bij het vinden, sommige, maar niet alle, van deze beveiligingsproblemen. Deze hulpprogramma's en tests worden verderop in dit onderwerp beschreven.

Geheugenbuffers

• Controleer altijd de grootte van de invoer- en uitvoerbuffers om ervoor te zorgen dat de buffers alle aangevraagde gegevens kunnen bevatten. Zie Fout bij het controleren van de grootte van buffersvoor meer informatie.

• Initialiseer alle uitvoerbuffers met nullen voordat deze naar de aanroeper worden geretourneerd. Zie Fout bij het initialiseren van uitvoerbuffersvoor meer informatie.

• Valideer buffers met variabele lengte. Zie Fout bij het valideren van Variable-Length buffersvoor meer informatie. Zie Bufferafhandelingvoor meer informatie over het werken met buffers en het gebruik van ProbeForRead om het adres van een buffer te valideren.

Gebruik de juiste methode voor toegang tot gegevensbuffers met IOCTLs

Een van de belangrijkste verantwoordelijkheden van een Windows-stuurprogramma is het overdragen van gegevens tussen toepassingen in de gebruikersmodus en de apparaten van een systeem. De drie methoden voor het openen van gegevensbuffers worden weergegeven in de volgende tabel.

IOCTL-buffertype	Samenvatting	Voor meer informatie
METHOD_BUFFERED	Aanbevolen voor de meeste situaties	Buffered I/O gebruiken
METHOD_IN_DIRECT of METHOD_OUT_DIRECT	Gebruikt in een snelle hardware-I/O	Direct I/O gebruiken
METHOD_NEITHER	Vermijd indien mogelijk	geen gebufferde of directe I/O- gebruiken

Over het algemeen wordt gebufferde I/O aanbevolen omdat deze de veiligste buffermethoden biedt. Maar zelfs bij het gebruik van gebufferde I/O zijn er risico's, zoals ingesloten aanwijzers die moeten worden beperkt.

Zie Methoden voor toegang tot gegevensbuffersvoor meer informatie over het werken met buffers in IOCTL's.

Fouten bij het gebruik van IOCTL-gebufferde I/O

• Controleer de grootte van gerelateerde IOCTL-buffers. Zie Fout bij het controleren van de grootte van buffersvoor meer informatie.

• Initialiseer uitvoerbuffers op de juiste manier. Zie Fout bij het initialiseren van uitvoerbuffersvoor meer informatie.

• Valideer buffers met variabele lengte op de juiste manier. Zie Fout bij het valideren van Variable-Length buffersvoor meer informatie.

• Wanneer u gebufferde I/O gebruikt, moet u ervoor zorgen dat de juiste lengte voor de OutputBuffer in het veld IO_STATUS_BLOCK structuurinformatie wordt geretourneerd. Retourneer niet zomaar de lengte rechtstreeks vanuit een READ-aanvraag. Denk bijvoorbeeld aan een situatie waarin de geretourneerde gegevens uit de gebruikersruimte aangeeft dat er een 4K-buffer is. Als het stuurprogramma eigenlijk slechts 200 bytes moet retourneren, maar in plaats daarvan alleen 4K retourneert in het veld Informatie, is er een beveiligingsprobleem met betrekking tot openbaarmaking van informatie opgetreden. Dit probleem treedt op omdat in eerdere versies van Windows de buffer die de I/O-beheer gebruikt voor gebufferde I/O niet nul is. De gebruikers-app haalt dus de oorspronkelijke 200 bytes aan gegevens plus 4K-200 bytes terug van wat er in de buffer stond (inhoud van niet-gepaginade pool). Dit scenario kan zich voordoen met alle toepassingen van gebufferde I/O en niet alleen met IOCTL's.

Fouten in directe IOCTL I/O

Behandel nul-lengte buffers correct. Zie fouten in direct I/O-voor meer informatie.

Fouten bij het verwijzen naar adressen van gebruikersruimte

• Valideer pointers die zijn ingesloten in buffered I/O-verzoeken. Voor meer informatie, zie Fouten in het verwijzen naar User-Space Adressen.

• Valideer een adres in de gebruikersruimte voordat u het probeert te gebruiken, met behulp van API's zoals ProbeForRead.

Stuurprogrammacode moet het juiste gebruik van het geheugen maken

• Alle toewijzingen van stuurprogrammagroepen moeten zich in een niet-uitvoerbare (NX)-pool bevinden. Het gebruik van NX-geheugengroepen is inherent veiliger dan het gebruik van uitvoerbare niet-paged (NP)-pools en biedt betere bescherming tegen overloopaanvallen.

• Er zijn extra geheugenvereisten om stuurprogramma's toe te staan om HVCI-virtualisatie te ondersteunen. Zie HvCI-compatibele code implementeren verderop in dit artikel voor meer informatie.

TOCTOU-beveiligingsproblemen

Er is een mogelijke TOCTOU-kwetsbaarheid van het moment van controle tot het moment van gebruik bij gebruik van directe I/O (voor IOCTLs of voor lezen/schrijven). Houd er rekening mee dat als het stuurprogramma toegang heeft tot de gegevensbuffer van de gebruiker, de gebruikers-app tegelijkertijd toegang heeft tot dezelfde gegevensbuffer.

Als u dit risico wilt beheren, kopieert u alle parameters die moeten worden gevalideerd vanuit de gegevensbuffer van de gebruiker naar het geheugen dat alleen toegankelijk is vanuit de kernelmodus, zoals de stack of pool. Zodra de gegevens niet toegankelijk zijn voor de gebruikersapplicatie, valideer en verwerk dan de doorgegeven gegevens.

MSR-modelspecifieke registerlees- en schrijfbewerkingen

Compiler-intrinsieken, zoals __readmsr en __writemsr kunnen worden gebruikt voor toegang tot de modelspecifieke registers. Als deze toegang is vereist, moet de driver altijd controleren of het register waarmee wordt gelezen of geschreven, beperkt is tot de verwachte index of het verwachte bereik.

Zie voor meer informatie en codevoorbeelden Het bieden van de mogelijkheid om MSR's te lezen/schrijven in Aanbevolen procedures voor het beperken van hoog bevoegd gedrag in stuurprogramma's voor kernelmodus.

Handgrepen

• Valideer handvatten die worden doorgegeven tussen gebruikersmodus en kernelmodus-geheugen. Zie Beheerbeheer en Fout bij het valideren van objectgrepenvoor meer informatie.

Apparaatobjecten

• Apparaatobjecten beveiligen. Voor meer informatie, zie Apparaatobjecten beveiligen.

• Apparaatobjecten valideren. Zie Fout bij het valideren van apparaatobjectenvoor meer informatie.

IRP's

Windows I/O-aanvraagpakketten (IRP's) worden gebruikt voor het communiceren van I/O-aanvragen tussen het besturingssysteem en stuurprogramma's in de kernelmodus, waarbij alle benodigde informatie in het pakket wordt ingekapseld. IR's faciliteren asynchrone gegevensoverdracht, synchronisatie en foutafhandeling, waardoor efficiënte en betrouwbare communicatie met hardwareapparaten mogelijk is. Zie I/O-aanvraagpakketten en overzicht van het Windows I/O-modelvoor meer informatie.

WDF en IRPs

Een voordeel van het gebruik van WDF is dat WDF-stuurprogramma's normaliter geen directe toegang tot IRP's hebben. Het framework converteert bijvoorbeeld de WDM-IRP's die lees-, schrijf- en apparaat-I/O-besturingsbewerkingen vertegenwoordigen, naar framework-aanvraagobjecten die KMDF/UMDF ontvangen in I/O-wachtrijen. Waar mogelijk wordt het gebruik van WDF sterk aanbevolen.

Als u een WDM-stuurprogramma moet schrijven, raadpleegt u de volgende richtlijnen.

IRP I/O-buffers correct beheren

Bekijk deze onderwerpen over het valideren van IRP-invoerwaarden:

DispatchReadWrite met gebufferde I/O

Fouten bij met gebufferde I/O

DispatchReadWrite met behulp van directe I/O

Fouten in Directe I/O

Valideer waarden die zijn gekoppeld aan een IRP, zoals bufferadressen en lengten.

Als u ervoor kiest om Geen I/O te gebruiken, moet u er rekening mee houden dat, in tegenstelling tot Lezen en Schrijven, en in tegenstelling tot Gebufferde I/O en Directe I/O, bij het gebruik van Geen I/O IOCTL de bufferpointers en lengtes niet worden gevalideerd door de I/O Manager.

IRP-voltooiingsbewerkingen correct verwerken

Een stuurprogramma moet nooit een IRP voltooien met een statuswaarde van STATUS_SUCCESS, tenzij het daadwerkelijk de IRP ondersteunt en verwerkt. Zie voor meer informatie over de juiste manieren om IRP-voltooiingsbewerkingen af te handelen.

IRP-pendingsstatus van stuurprogramma's beheren

Het stuurprogramma moet de IRP markeren die in behandeling is voordat het IRP wordt opgeslagen en moet overwegen om zowel de aanroep naar IoMarkIrpPending- als de toewijzing in een onderling vergrendelde volgorde op te nemen. Voor meer informatie, zie Het niet controleren van de status van een stuurprogramma en Binnenkomende IRPs vasthouden wanneer een apparaat is gepauzeerd.

IRP-annuleringsbewerkingen correct verwerken

Annuleringsbewerkingen kunnen lastig zijn om correct te coderen, omdat ze meestal asynchroon worden uitgevoerd. Problemen in de code waarmee annuleringsbewerkingen worden verwerkt, kunnen lange tijd onopgemerkt blijven, omdat deze code doorgaans niet vaak wordt uitgevoerd in een actief systeem. Lees en begrijp alle informatie die onder Annuleren van IRPswordt gegeven. Let vooral op Het synchroniseren van IRP-annuleringen en punten ter overweging bij het annuleren van IRPs.

Een aanbevolen manier om de synchronisatieproblemen die zijn gekoppeld aan annuleringsbewerkingen te minimaliseren, is door een IRP-wachtrij te implementeren.

IRP-opschonings- en sluitbewerkingen correct verwerken

Zorg ervoor dat u het verschil tussen IRP_MJ_CLEANUP en IRP_MJ_CLOSE aanvragen begrijpt. Opschoningsaanvragen komen binnen nadat een toepassing alle ingangen voor een bestandsobject sluit, maar soms voordat alle I/O-aanvragen zijn voltooid. Sluitverzoeken komen binnen nadat alle I/O-aanvragen voor het bestandsobject zijn voltooid of geannuleerd. Zie het volgende voor meer informatie:

DispatchCreate, DispatchClose en DispatchCreateClose Routines

DispatchCleanup-routines

Fouten bij het afhandelen van opschonings- en afsluitingsbewerkingen

Zie Aanvullende fouten bij het afhandelen van IR'svoor meer informatie over het correct verwerken van IR's.

Veilige functies gebruiken

• Gebruik veilige tekenreeksfuncties. Voor meer informatie, zie Veilige tekenreeksfuncties gebruiken.

• Gebruik veilige rekenkundige functies. Zie Safe Integer Library Routinesvoor meer informatie.

• Veilige conversiefuncties gebruiken. Zie Samenvatting van Kernel-Mode veilige integerfunctiesvoor meer informatie.

Andere beveiligingsproblemen

• Gebruik een vergrendeling of een geblokkeerde reeks om racevoorwaarden te voorkomen. Zie fouten in een multiprocessoromgevingvoor meer informatie.

• Zorg ervoor dat er geen TDI-filters (Network Transport Driver Interface) of Layered Service Providers (LSP's) zijn geïnstalleerd door het stuurprogramma of de bijbehorende softwarepakketten tijdens de installatie of het gebruik. Gebruik in plaats daarvan moderne API's, zoals de WFP -(Windows Filtering Platform).

Aanvullende beveiligingsproblemen met code

Naast de mogelijke beveiligingsproblemen die hier worden behandeld, biedt dit artikel aanvullende informatie over het verbeteren van de beveiliging van stuurprogrammacode voor kernelmodus: Het maken van betrouwbare Kernel-Mode Stuurprogramma's.

Zie Beveiligde coderingsbronnen aan het einde van dit artikel voor meer informatie over C- en C++-codering.

HVCI-compatibele code implementeren

controlelijstitem #6:Controleer of uw stuurprogramma geheugen gebruikt, zodat het compatibel is met HVCI.

Geheugenintegriteit en HVCI-compatibiliteit

Geheugenintegriteit, ook wel bekend als HVCI (Hypervisor-protected Code Integrity) maakt gebruik van hardwaretechnologie en virtualisatie om de beslissingsfunctie code-integriteit (CI) te isoleren van de rest van het besturingssysteem. Wanneer u beveiliging op basis van virtualisatie gebruikt om CI te isoleren, kan kernelgeheugen alleen uitvoerbaar worden via een CI-verificatie. Dit betekent dat kernelgeheugenpagina's nooit schrijfbaar en uitvoerbaar (W+X) kunnen zijn en uitvoerbare code niet rechtstreeks kan worden gewijzigd.

Als u hvCI-compatibele code wilt implementeren, moet u ervoor zorgen dat uw stuurprogrammacode het volgende doet:

• Meldt zich standaard aan bij NX
• Gebruikt NX API's/vlaggen voor geheugentoewijzing (NonPagedPoolNx)
• Maakt geen gebruik van secties die zowel beschrijfbaar als uitvoerbaar zijn
• Probeert het uitvoerbare systeemgeheugen niet rechtstreeks te wijzigen
• Gebruikt geen dynamische code in kernel
• Laadt gegevensbestanden niet als uitvoerbaar bestand
• Sectie-uitlijning is een veelvoud van 0x1000 (PAGE_SIZE). Bijvoorbeeld DRIVER_ALIGNMENT=0x1000

Zie HVCI-compatibele code implementerenvoor meer informatie over het gebruik van het hulpprogramma en een lijst met incompatibele geheugenoproepen.

Zie HyperVisor Code Integrity Readiness Test en Hypervisor-Protected HVCI (Code Integrity)voor meer informatie over de gerelateerde beveiligingstest voor systeembasisbeginselen.

Beveiliging van apparaatinstallatie verbeteren

Controlelijstitem #7:Beoordeel de richtlijnen voor het creëren en installeren van stuurprogramma's om ervoor te zorgen dat u de aanbevolen procedures volgt.

Wanneer u de code maakt waarmee het stuurprogrammapakket wordt geïnstalleerd, moet u ervoor zorgen dat de installatie van uw apparaat altijd op een veilige manier wordt uitgevoerd. Een beveiligde apparaatinstallatie is een installatie die het volgende doet:

• Hiermee beperkt u de toegang tot het apparaat en de apparaatinterfaceklassen
• Beperkt de toegang tot de stuurprogrammaservices die zijn gemaakt voor het apparaat
• Beveiligt stuurprogrammabestanden tegen wijziging of verwijdering
• De toegang tot de registervermeldingen van het apparaat beperken
• Beperkt de toegang tot de WMI-klassen van het apparaat
• Maakt correct gebruik van SetupAPI-functies

Zie het volgende voor meer informatie:

Beveiligde apparaatinstallaties maken

Richtlijnen voor het gebruik van SetupAPI

Apparaatinstallatiefuncties gebruiken

Geavanceerde onderwerpen over installatie van apparaten en stuurprogramma's

De best practices voor technologiespecifieke code volgen

Beveiligingschecklijst item #8:Bekijk de volgende specifieke richtlijnen voor technologie voor uw stuurprogramma.

Bestandssystemen

Zie het volgende voor meer informatie over de beveiliging van bestandssysteemstuurprogramma's:

Inleiding tot File Systems Security

bestandssysteembeveiligingsproblemen

beveiligingsfuncties voor bestandssystemen

co-existentie met andere stuurprogramma's voor bestandssysteemfilters

Microsoft Virus Initiative

Het Microsoft Virus Initiative (MVI) helpt organisaties bij het verbeteren van de beveiligingsoplossingen waarop onze klanten vertrouwen om ze veilig te houden. Microsoft biedt hulpprogramma's, resources en kennis ter ondersteuning van betere ervaringen met geweldige prestaties, betrouwbaarheid en compatibiliteit. Microsoft werkt samen met MVI-partners om veilige implementatieprocedures (SDP) te definiëren en te volgen ter ondersteuning van de veiligheid en tolerantie van onze wederzijdse klanten.

Als u een antivirusleverancier bent, raadpleegt u Microsoft Virus Initiative voor meer informatie over het toevoegen van MVI voor meer hulp bij software-implementatie. Zie aanbevolen procedures voor Windows-beveiliging voor het integreren en beheren van beveiligingshulpprogramma'svoor meer informatie over hoe beveiligingsleveranciers de geïntegreerde beveiligingsmogelijkheden van Windows beter kunnen benutten voor betere beveiliging en betrouwbaarheid.

NDIS - Netwerken

Zie Beveiligingsproblemen voor netwerkstuurprogramma'svoor informatie over de beveiliging van NDIS-stuurprogramma's.

Printers

Zie V4 Printer Driver Security Considerationsvoor informatie over beveiliging van printerstuurprogramma's.

Beveiligingsproblemen voor WIA-stuurprogramma's (Windows Image Acquisition)

Zie Beveiligingsproblemen voor WIA-stuurprogramma's (Windows Image Acquisition)voor informatie over WIA-beveiliging.

SAL-aantekeningen toevoegen aan uw stuurprogrammacode

Item op de beveiligingscontrolelijst #9:Voeg SAL-aantekeningen toe aan uw stuurprogrammacode.

De broncode-annotatietaal (SAL) biedt een set aantekeningen die u kunt gebruiken om te beschrijven hoe een functie de parameters gebruikt, de veronderstellingen die er over worden gemaakt en de garanties die deze biedt wanneer deze klaar is. De aantekeningen worden gedefinieerd in het headerbestand sal.h. Visual Studio-codeanalyse voor C++ maakt gebruik van SAL-aantekeningen om de analyse van functies te wijzigen. Voor meer informatie over SAL 2.0 voor de ontwikkeling van Windows-stuurprogramma's, zie SAL 2.0 Annotaties voor Windows Drivers en SAL Annotaties gebruiken om C/C++ Code Fouten te Verminderen.

Raadpleeg dit artikel dat beschikbaar is via OSR voor algemene informatie over SAL. SAL Annotations: Haat me niet omdat ik mooi ben

Peercodebeoordeling uitvoeren

beveiligingscontrolelijst item #10:Voer een peercodereview uit om problemen op te sporen die niet door de andere tools en processen worden gevonden

Zoek naar deskundige coderevisoren om te zoeken naar problemen die u mogelijk hebt gemist. Een tweede reeks ogen ziet vaak problemen die u mogelijk over het hoofd hebt gezien.

Als u geen geschikt personeel hebt om uw code intern te controleren, kunt u overwegen externe hulp in te schakelen voor dit doel.

Bedreigingsanalyse uitvoeren

beveiligingscontrolelijstitem #11:wijzig een bestaand bedreigingsmodel van het stuurprogramma of maak een aangepast bedreigingsmodel voor uw stuurprogramma aan.

Bij het overwegen van beveiliging is een algemene methodologie om specifieke bedreigingsmodellen te maken die proberen de typen aanvallen te beschrijven die mogelijk zijn. Deze techniek is handig bij het ontwerpen van een stuurprogramma, omdat de ontwikkelaar de potentiële aanvalsvectoren vooraf moet overwegen tegen een stuurprogramma. Als u potentiële bedreigingen hebt geïdentificeerd, kan een ontwikkelaar van stuurprogramma's vervolgens de middelen overwegen om deze bedreigingen te beschermen om de algehele beveiliging van het stuurprogrammaonderdeel te versterken.

Dit artikel bevat specifieke richtlijnen voor stuurprogramma's voor het aanmaken van een lichtgewicht dreigingsmodel: Dreigingsmodellering voor stuurprogramma's. Het artikel bevat een voorbeeld van een bedreigingsmodeldiagram voor stuurprogramma's dat kan worden gebruikt als uitgangspunt voor uw stuurprogramma.

Aanbevolen procedures en bijbehorende hulpprogramma's (Security Development Lifecycle) kunnen worden gebruikt door IHD's en OEM's om de beveiliging van hun producten te verbeteren. Zie SDL-aanbevelingen voor OEM'svoor meer informatie.

CodeQL gebruiken om uw stuurprogrammacode te controleren

controlelijstitem voor beveiliging #12:CodeQL gebruiken om te controleren op beveiligingsproblemen in uw stuurprogrammacode.

CodeQL, door GitHub, is een semantische codeanalyse-engine en de combinatie van een uitgebreide suite beveiligingsquery's samen met een robuust platform maken het een waardevol hulpprogramma voor het beveiligen van stuurprogrammacode. Zie CodeQL en de Static Tools Logo Testvoor meer informatie.

Stuurprogrammacontrole gebruiken om te controleren op beveiligingsproblemen

controlelijstitem #13:Stuurprogrammacontrole gebruiken om te controleren op beveiligingsproblemen in uw stuurprogrammacode.

Stuurprogrammaverifier maakt gebruik van een set interfaceregels en een model van het besturingssysteem om te bepalen of het stuurprogramma correct communiceert met het Windows-besturingssysteem. Stuurprogrammacontrole vindt defecten in stuurprogrammacode die kunnen verwijzen naar mogelijke fouten in stuurprogramma's.

Driver Verifier maakt live testen van het stuurprogramma mogelijk. Stuurprogrammaverificator bewaakt Stuurprogramma's in de kernelmodus van Windows en grafische stuurprogramma's om illegale functie-aanroepen of acties te detecteren die het systeem kunnen beschadigen. Met een gekoppeld foutopsporingsprogramma kunt u in realtime de uitvoering van besturingssysteem- en stuurprogrammacode bekijken. Stuurprogrammaverificator kan de Windows-stuurprogramma's aan verschillende stress en tests onderwerpen om onjuist gedrag te vinden. Zie Driver Verifiervoor meer informatie.

Stuurprogramma Verifer werkt met zowel WDM- als KMDF-stuurprogramma's. Zie de volgende onderwerpen voor de details van wat het kan controleren.

• Regels voor WDM-stuurprogramma's
• Regels voor KMDF-stuurprogramma's

Zie DDI-nalevingsregels en ondersteunde stuurprogramma'svoor meer informatie over de stuurprogramma's waarmee Stuurprogrammaverifier kan werken. Zie voor de aanvullende verificatorregels voor specifieke typen stuurprogramma's:

• Regels voor NDIS-stuurprogramma's
• Regels voor Storport-stuurprogramma's
• Regels voor audiostuurprogramma's
• Regels voor AVStream-stuurprogramma's

Als u vertrouwd wilt raken met DV, kunt u een van de voorbeeldstuurprogramma's gebruiken (bijvoorbeeld het aanbevolen broodroostervoorbeeld: https://github.com/Microsoft/Windows-driver-samples/tree/main/general/toaster/toastDrv/kmdf/func/featured).

Code controleren met de tests van het hardwarecompatibiliteitsprogramma

controlelijstitem beveiliging #14:Gebruik de beveiligingsgerelateerde hardwarecompatibiliteitsprogrammatests om te controleren op beveiligingsproblemen.

Het hardwarecompatibiliteitsprogramma bevat beveiligingsgerelateerde tests die kunnen worden gebruikt om te zoeken naar beveiligingsproblemen in code. Het Windows Hardware Compatibility Program maakt gebruik van de tests in de Windows Hardware Lab Kit (HLK). De HLK Device Fundamentals-tests kunnen op de opdrachtregel worden uitgevoerd om de stuurprogrammacode te testen en op zwakheden te onderzoeken. Zie Windows Hardware Lab Kitvoor algemene informatie over de grondbeginselen van het apparaat en het hardwarecompatibiliteitsprogramma.

De volgende tests zijn voorbeelden van tests die nuttig kunnen zijn om stuurprogrammacode te controleren op bepaalde gedragingen die zijn gekoppeld aan codeproblemen:

DF - Fuzz willekeurige IOCTL-test (betrouwbaarheid)

DF - Fuzz sub-opens test (betrouwbaarheid)

DF - Fuzz nul-lengte buffer FSCTL-test (Betrouwbaarheid)

DF - Fuzz random FSCTL-test (betrouwbaarheid)

DF - Fuzz Misc API-test (betrouwbaarheid)

U kunt ook de kernelsynchronisatievertraging gebruiken die is opgenomen in Driver Verifier.

De CHAOS-tests (Gelijktijdige hardware en besturingssysteem) voeren verschillende PnP-stuurprogrammatests, fuzztests van het apparaatstuurprogramma en stroomsysteemtests gelijktijdig uit. Zie voor meer informatie CHAOS Tests (apparaatfundamentals).

De penetratietests van device fundamentals voeren verschillende vormen van invoeraanvallen uit. Dit is een essentieel onderdeel van beveiligingstests. Aanvallen en penetratietests kunnen helpen bij het identificeren van beveiligingsproblemen in software-interfaces. Voor meer informatie, zie Penetratietests (Apparaatprincipes).

Gebruik de Device Guard - Compliancetest, samen met de andere hulpprogramma's die in dit artikel worden beschreven, om te controleren of uw stuurprogramma compatibel is met HVCI.

Aangepaste en domeinspecifieke testhulpprogramma's

Overweeg de ontwikkeling van aangepaste domeinspecifieke beveiligingstests. Als u aanvullende tests wilt ontwikkelen, verzamelt u input van de oorspronkelijke ontwerpers van de software, evenals niet-gerelateerde ontwikkelresources die bekend zijn met het specifieke type stuurprogramma dat wordt ontwikkeld, en een of meer personen die bekend zijn met beveiligingsinbraakanalyse en -preventie.

Controleer gereed om stuurprogramma's te verzenden met hulpprogramma's zoals BinSkim en SignTool

beveiligingscontrolelijstitem #15:Controleer gecompileerde code met de hulpprogramma's zoals BinSkim en SignTool voordat deze wordt geüpload naar het partnercentrum.

Gebruik hulpprogramma's zoals BinSkim en SignTool om binaire bestanden te onderzoeken om gecompileerde code te controleren voordat deze naar het partnercentrum wordt geüpload om te worden gedistribueerd met Windows Update. Hulpprogramma's die gecompileerde binaire bestanden controleren voordat ze voor distributie worden verzonden, bieden een extra beveiligingslaag.

BinSkim

BinSkim kan coderings- en bouwprocedures identificeren die mogelijk het binaire kwetsbaar maken. BinSkim controleert op:

• Gebruik van verouderde compilerhulpprogrammasets: binaire bestanden moeten waar mogelijk worden gecompileerd op basis van de meest recente compilerhulpprogrammasets om het gebruik van huidige beveiligingsbeperking op compilerniveau en door het besturingssysteem geleverde beveiligingsbeperking te maximaliseren.
• Onveilige compilatie-instellingen: binaire bestanden moeten worden gecompileerd met de veiligste instellingen die mogelijk zijn om door het besturingssysteem geleverde beveiligingsbeperking mogelijk te maken, compilerfouten en waarschuwingen te maximaliseren die onder andere moeten worden gerapporteerd.
• Ondertekeningsproblemen: ondertekende binaire bestanden moeten worden ondertekend met cryptografische sterke algoritmen.

BinSkim is een open-source-hulpmiddel en genereert uitvoerbestanden die het formaat Static Analysis Results Interchange (SARIF) gebruiken. BinSkim vervangt het voormalige hulpprogramma BinScope.

Voor meer informatie over BinSkim, zie BinSkim gebruiken om binaire bestanden te controleren en de BinSkim-gebruikershandleiding.

SignTool

Gebruik SignTool om release-ondertekende stuurprogrammabestanden te controleren. Voor meer informatie, zie de handtekening van een Release-Signed stuurprogrammabestand controleren en de handtekening van een catalogusbestand dat is ondertekend met een certificaat voor commerciële release controleren.

Voer geen productietekens op testcode uit

beveiligingscontrolelijstitem #16:Ontwikkelings-, test- en productiecode voor kernelstuurprogramma's niet ondertekenen voor productie.

Kernelstuurprogrammacode die wordt gebruikt voor ontwikkeling, testen of productie kan gevaarlijke mogelijkheden bevatten die een beveiligingsrisico vormen. Deze gevaarlijke code mag nooit worden ondertekend met een certificaat dat wordt vertrouwd door Windows. Het juiste mechanisme voor het uitvoeren van gevaarlijke stuurprogrammacode is het uitschakelen van UEFI Secure Boot, het inschakelen van de BCD 'TESTSIGNING', en het ondertekenen van de ontwikkeling, test en productiecode met behulp van een niet-vertrouwd certificaat (bijvoorbeeld één gegenereerd door makecert.exe).

Code die is ondertekend door een vertrouwde Software Publishers Certificate (SPC) of WHQL-handtekening (Windows Hardware Quality Labs), mag het overslaan van windows-codeintegriteit en beveiligingstechnologieën niet vergemakkelijken. Voordat code wordt ondertekend door een vertrouwde SPC- of WHQL-handtekening, moet u eerst controleren of deze voldoet aan de richtlijnen voor het maken van betrouwbare driversKernel-Mode. Bovendien mag de code geen gevaarlijk gedrag bevatten, zoals hieronder wordt beschreven.

Voorbeelden van gevaarlijk gedrag zijn:

• Biedt de mogelijkheid om willekeurig kernel-, fysiek- of apparaatgeheugen toe te wijzen aan gebruikersmodus.
• Dit biedt de mogelijkheid om willekeurige kernel, fysiek of apparaatgeheugen te lezen of schrijven, inclusief poortinvoer/uitvoer (I/O).
• Toegang bieden tot opslag waarmee Toegangsbeheer van Windows wordt overgeslagen.
• Het bieden van de mogelijkheid om hardware of firmware te wijzigen die het stuurprogramma niet is ontworpen om te beheren.

Zorg voor de correcte ondertekening van het release-stuurprogramma en distribueer uw stuurprogrammapakket via Windows Update.

beveiligingscontrolelijstitem #17:Gebruik de Windows-partnerportal om uw stuurprogrammapakket te verzenden dat moet worden ondertekend en gedistribueerd via Windows Update.

Voordat u een stuurprogrammapakket voor het publiek vrijgeeft, dient u het pakket in voor certificering. Zie Test voor prestaties en compatibiliteit en Aan de slag met het hardwareprogrammavoor meer informatie.

Het gebruik van Windows Update wordt sterk aanbevolen voor de distributie van stuurprogrammapakketten. Windows Update biedt een robuust, veilig, wereldwijd geschaald distributiesysteem dat compatibel is met regelgeving die moet worden gebruikt om stuurprogramma-updates te leveren. Zie Een stuurprogrammapakket distribuerenvoor meer informatie.

Gebruik geleidelijke implementatie en Driver flighting in het Partner Center for Windows Hardware om uw stuurprogrammapakket te distribueren binnen gedefinieerde Windows Insider-ringen, terwijl automatische bewaking en evaluatie worden geboden. Bewaak de implementatie van het stuurprogramma met behulp van de Microsoft-stuurprogrammametingen, zoals percentage machines zonder een crash van de kernelmodus om de kwaliteit te behouden.

Voor een beschrijving van veilige software-implementatieprocedures raadpleegt u de CISA-Veilige software-implementatie: hoe softwarefabrikanten betrouwbaarheid kunnen garanderen voor klanten.

Meer informatie over hoe stuurprogramma's worden gerapporteerd met behulp van het Rapportagecentrum voor kwetsbare en schadelijke stuurprogramma's van Microsoft

beveiligingscontrolelijstitem #18: Begrijpen hoe stuurprogramma's worden gerapporteerd met behulp van het Microsoft-rapportagecentrum voor kwetsbare en schadelijke stuurprogramma's

Iedereen kan een twijfelachtige driver indienen met behulp van het Microsoft-rapportagecentrum voor kwetsbare en schadelijke stuurprogramma's. Raadpleeg dit blogbericht voor informatie over hoe stuurprogramma's worden verzonden voor analyse- Kernelbeveiliging verbeteren met het nieuwe Microsoft-rapportagecentrum voor kwetsbare en schadelijke stuurprogramma's

Het Reporting Center kan Windows-stuurprogramma's scannen en analyseren die zijn gebouwd voor x86- en x64-architecturen. Kwetsbare en kwaadwillende gescande stuurprogramma's worden gemarkeerd voor analyse en onderzoek door het microsoft-team kwetsbare stuurprogramma's. Nadat kwetsbare drivers zijn bevestigd, wordt er een passende melding uitgevoerd en worden ze toegevoegd aan de blocklist voor kwetsbare drivers. Voor meer informatie daarover, zie de door Microsoft aanbevolen blokkeringsregels voor stuurprogramma's. Deze regels worden standaard toegepast op apparaten met hypervisor beveiligde code-integriteit (HVCI) en Windows 10 in de S-modus.

Beveiligde coderingsbronnen controleren

beveiligingscontrolelijstitem #19:Bekijk deze bronnen om uw inzicht in de aanbevolen procedures voor veilige codering die van toepassing zijn op stuurprogrammaontwikkelaars uit te breiden.

Richtlijnen voor Microsoft NISTIR 8397

De amerikaanse overheidspublicatie NISTIR 8397: Richtlijnen voor minimumstandaarden voor de verificatie van software door het National Institute of Standards and Technology (NIST) bevat richtlijnen voor het bouwen van betrouwbare en veilige software in elke programmeertaal.

Betrouwbare en veilige C++-programma's bouwen geeft een overzicht van het gebruik van Microsoft-ontwikkelaarsproducten voor C++ en andere talen om de NISTIR 8397-richtlijnen te volgen.

NIST bekende database voor beveiligingsproblemen met software

De National Vulnerability Database (NVD) is een doorzoekbare opslagplaats met beveiligingsgerelateerde softwarefouten, waaronder Windows-stuurprogramma's.

NIST-database voor beveiligingsproblemen zoeken

Overzicht van Nationale database voor beveiligingsproblemen

Beveiligingscodeerstandaarden

Carnegie Mellon University SEI CERT - C Coding Standard: Regels voor het ontwikkelen van veilige, betrouwbare en beveiligde systemen (PDF).

MITRE - Zwakheden die worden aangepakt door de CERT C Secure Coding Standard

Microsoft Visual Studio - De C++-kernrichtlijnencontrole gebruiken

Veilige coderingsorganisaties

Cybersecurity and Infrastructure Security Agency (CISA)

CISA-bronnen

Carnegie Mellon University SEI CERT

SAFECode

OSR

OSR biedt ontwikkelings- en adviesdiensten voor stuurprogramma's. In deze artikelen uit de OSR-nieuwsbrief worden beveiligingsproblemen met stuurprogramma's uitgelicht.

Namen, beveiligingsdescriptors en apparaatklassen - Apparaatobjecten toegankelijk maken... en VEILIG

Je moet bescherming gebruiken: binnen in driver & Apparaatbeveiliging

Vergrendelen van stuurprogramma's - Een onderzoek naar technieken

Meltdown en Spectre: Hoe zit het met stuurprogramma's?

Casestudy voor beveiligingsproblemen van stuurprogramma's

nl-NL: Van waarschuwing tot kwetsbaarheid in stuurprogramma's: Microsoft Defender ATP-onderzoek onthult een kwetsbaarheid in privilege-escalatie

Beveiliging van softwaretoeleveringsketens en softwarestukkenlijst (SBOMs)

SBOM's bieden een lijst met ingrediënten die worden gebruikt bij het maken van een stukje software, zoals opensource-software, onderdelen en mogelijk zelfs bouwhulpprogramma's. Hierdoor kunnen producenten en consumenten beter inventariseren en licentie- en beveiligingsrisico's evalueren. Microsoft gebruikt de SPDX (Software Package Data Exchange) als de SBOM-documentindeling. Zie voor meer informatie Software Bills of Materials (SBOMs) genereren met SPDX bij Microsoft en Microsoft maakt zijn software bill of materials (SBOM) generatietool open source.

Het Supply Chain Integrity, Transparency and Trust (SCITT)-initiatief is een set van IETF-internetstandaarden voor het beheren van de naleving van goederen en diensten in end-to-end toeleveringsketens. SCITT ondersteunt de doorlopende verificatie van goederen en services waarbij de echtheid van entiteiten, bewijs, beleid en artefacten kan worden gegarandeerd en de acties van entiteiten kunnen worden gegarandeerd, niet-weerlegbaar, onveranderbaar en controleerbaar zijn.

Boeken

24 dodelijke zonden van softwarebeveiliging: Programmeerfouten en hoe ze te herstellen door Michael Howard, David LeBlanc en John Viega

Writing Secure Software Second Edition, Michael Howard en David LeBlanc

The Art of Software Security Assessment: Identificeren en voorkomen van beveiligingsproblemen van software, Mark Dowd, John McDonald en Justin Schuh

Secure Coding in C en C++ (SEI-reeks in Software Engineering) 2e Editie, Robert C. Seacord

Programmeren van het Microsoft Windows-stuurprogrammamodel (2e editie), Walter Oney

Ontwikkelen van stuurprogramma's met de Windows Driver Foundation (Developer Reference), Penny Orwick en Guy Smith

Opleiding

Leslokaaltraining voor Windows-stuurprogramma's is beschikbaar bij leveranciers zoals:

• OSR
• Winsider

Onlinetraining voor veilig coderen is beschikbaar vanuit verschillende bronnen. Deze cursus is bijvoorbeeld beschikbaar vanuit coursera op:

Beveiligingsproblemen identificeren in C/C++ Programmeren.

SAFECode biedt ook gratis training:

SAFECode.org/training

Professionele certificering

CERT biedt een Secure Coding Professional Certification.

Overzicht van belangrijke punten

Beveiliging van bestuurders is een complexe onderneming die veel elementen bevat, maar hier zijn enkele belangrijke punten om rekening mee te houden:

• Stuurprogramma's leven in de Windows-kernel en een probleem bij het uitvoeren in de kernel kan het hele besturingssysteem blootstellen. Daarom moet u goed letten op de beveiliging van drivers en ontwerpen met het oog op beveiliging.

• Pas het principe van minimale bevoegdheden toe:

  een. Een strikte SDDL-tekenreeks gebruiken om de toegang tot het stuurprogramma te beperken

  b. Afzonderlijke IOCTL's verder beperken

• Maak een bedreigingsmodel om aanvalsvectoren te identificeren en overweeg of iets verder kan worden beperkt.

• Wees voorzichtig voor geïntegreerde pointers die worden doorgegeven vanuit de gebruikersmodus. Ze moeten worden gecontroleerd, benaderd binnen een try-except-blok, en ze zijn gevoelig voor problemen met tijd van controle tijd van gebruik (ToCToU), tenzij de waarde van de buffer wordt vastgelegd en vergeleken.

• Als u het niet zeker weet, gebruikt u METHOD_BUFFERED als een IOCTL-buffermethode.

• Gebruik hulpprogramma's voor het scannen van code, zoals CodeQL, om te zoeken naar bekende codeproblemen en identificeer eventuele geïdentificeerde problemen op te lossen.

• Zoek naar deskundige coderevisoren om te zoeken naar problemen die u mogelijk hebt gemist.

• Gebruik Driver Verifier en test uw stuurprogramma met meerdere invoer, inclusief randgevallen.