Delen via

Controlelijst voor driverbeveiliging

  • Artikel

Dit artikel bevat een controlelijst voor stuurprogrammabeveiliging voor ontwikkelaars van stuurprogramma's om het risico te verminderen dat stuurprogramma's worden aangetast.

Overzicht van driverbeveiliging

Een beveiligingsfout is een fout die een aanvaller in staat stelt een stuurprogramma zodanig te laten functioneren dat 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.

Ongemarkeerd selectievakje dat een item in de beveiligingschecklist vertegenwoordigt. Bevestigen dat een kernelstuurprogramma nodig is

Niet-aangevinkt selectievakje dat een item in de beveiligingschecklist vertegenwoordigt. Gebruik de stuurprogrammaframeworks

Niet-aangevinkt selectievakje dat een item in de beveiligingscontrolelijst vertegenwoordigt. Beperk toegang tot alleen softwarestuurprogramma's

ongemarkeerd selectievakje dat een item in de veiligheidscontrolelijst vertegenwoordigt. Test-stuurprogrammacode niet voor productie ondertekenen

Ongemarkeerd selectievakje dat een item vertegenwoordigt in de beveiligingscontrolelijst. Uitvoeren van bedreigingsanalyse

niet gemarkeerd selectievakje dat een item in de beveiligingschecklist vertegenwoordigt. Volg de richtlijnen voor veilig coderen van stuurprogramma's

niet-gemarkeerd selectievakje dat een item op de beveiligingscontrolelijst vertegenwoordigt. HVCI-compatibele code implementeren

Niet-gemarkeerd selectievakje dat een item in de beveiligingscontrolelijst vertegenwoordigt. Volg de beste praktijken voor technologiespecifieke code

een niet-gemarkeerd selectievakje dat een item op de beveiligingschecklist vertegenwoordigt. Peer Code Controleren

niet-gemarkeerd selectievakje dat onderdeel is van de beveiligingscontrolelijst. Stuurprogramma-toegangsbeheer beheren

Niet-aangevinkt selectievakje dat een item in de beveiligingschecklist vertegenwoordigt. De beveiliging van apparaatinstallaties verbeteren

niet-gemarkeerd selectievakje dat een item in de beveiligingscontrolelijst vertegenwoordigt. het releasestuurprogramma correct ondertekenen

Ongemarkeerd selectievakje dat een item in de veiligheidscontrolelijst vertegenwoordigt. Gebruik CodeQL om uw stuurprogrammacode te controleren

Niet-geselecteerd selectievakje dat een item in de beveiligingscontrolelijst vertegenwoordigt. SAL-aantekeningen toevoegen aan de stuurprogrammacode

uitgeschakeld selectievakje dat een item in de beveiligingscontrolelijst vertegenwoordigt. Stuurprogrammacontrole gebruiken om te controleren op beveiligingsproblemen

niet-gemarkeerd selectievakje dat een item vertegenwoordigt in de beveiligingschecklist. code controleren met BinSkim Binary Analyzer

Ongemarkeerd selectievakje dat een item in de beveiligingschecklist vertegenwoordigt. Code controleren met tests van het hardwarecompatibiliteitsprogramma

niet-gemarkeerd selectievakje dat een item in de beveiligingschecklist vertegenwoordigt. Begrijpen hoe stuurprogramma's worden gerapporteerd met het Rapportagecentrum voor kwetsbare en schadelijke stuurprogramma's van Microsoft

niet-aangevinkt selectievakje dat een item in de beveiligingscontrolelijst vertegenwoordigt. Beveiligingscoderingsbronnen bekijken

Niet-gemarkeerd selectievakje dat een item in de beveiligingschecklist vertegenwoordigt. Bekijk de samenvatting van de belangrijkste punten

Controleer of een kernelstuurprogramma is vereist

Beveiligingscontrolelijstitem #1:Bevestig dat een kernelstuurprogramma vereist is en dat een benadering met een lager risico, zoals een Windows-service of een app, geen betere optie is.

Stuurprogramma's werken binnen de Windows-kernel, en 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 gebruikersmodusstuurprogramma met een lager risico (UMDF).

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

De broncode van Windows Driver Framework is open source en beschikbaar op GitHub. Dit is dezelfde broncode waaruit de WDF-runtimebibliotheek die wordt geleverd in Windows 10 is gebouwd. 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.

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

beveiligingscontrolelijstitem #3: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 onderzoek van de SMBIOS-tabel voordat u mogelijkheden inschakelt).

Voer geen productietekens op testcode uit

Beveiligingscontrolelijstitem #4:Onderteken ontwikkelings-, test- en productiekernelstuurprogrammabestanden niet 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. Voor meer informatie over het ondertekenen van stuurprogramma's, zie Release driver signing verderop in dit artikel.

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.

Bedreigingsanalyse uitvoeren

item van de beveiligingscontrolelijst 5:ofwel een bestaand bedreigingsmodel voor een driver wijzigen of een aangepast bedreigingsmodel voor uw driver maken.

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.

voorbeeldgegevensstroomdiagram dat een hypothetisch stuurprogramma voor kernelmodus illustreert.

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.

Richtlijnen voor veilig coderen van stuurprogramma's volgen

controlelijstitem #6: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 van software hebben betrekking op het strikt bijhouden van het geheugengebruik om te voorkomen dat anderen het geheugen dat uw stuurprogramma gebruikt overschrijven of op andere wijze aantasten.

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

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 situtaties Buffered I/O gebruiken
METHOD_IN_DIRECT of METHOD_OUT_DIRECT Gebruikt in sommige hoge-snelheids hardware I/O Direct I/O gebruiken
METHOD_NEITHER Vermijd indien mogelijk geen gebufferde of directe I/O- gebruiken

In het algemeen wordt gebufferde I/O aanbevolen omdat het 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

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 het stuurprogramma altijd controleren of het register waarnaar moet worden 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.

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 het stuurprogramma toegang heeft tot de gegevensbuffer van de gebruiker, de gebruiker kan er tegelijkertijd toegang toe hebben.

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). Wanneer de gegevens niet toegankelijk zijn voor de gebruikersapplicatie, valideer en bewerk vervolgens de gegevens die zijn doorgegeven.

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.

  • Apparaatstuurprogramma's moeten verschillende gebruikersmodus en kernel-I/O-aanvragen correct verwerken.

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.

Handgrepen

Apparaatobjecten

IRP's

WDF en IRPs

Een voordeel van het gebruik van WDF is dat WDF-stuurprogramma's typisch geen directe toegang krijgen tot IRPs. 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.

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

IRP I/O-buffers correct beheren

De volgende artikelen bevatten informatie 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

beveiligingsproblemen voor I/O-besturingscodes

Overweeg waarden te valideren 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 met een statuswaarde van STATUS_SUCCESS voltooien, tenzij het de IRP daadwerkelijk 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 de volgende artikelen 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.

Andere beveiligingsproblemen

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

  • Zorg ervoor dat apparaatstuurprogramma's zowel gebruikersmodus- als kernel-naar-kernel-I/O-verzoeken correct verwerken.

  • Zorg ervoor dat er geen TDI-filters of LSP's zijn geïnstalleerd door het stuurprogramma of de bijbehorende softwarepakketten tijdens de installatie of het gebruik.

Veilige functies gebruiken

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.

Toegangsbeheer voor stuurprogramma's beheren

controlelijstitem #7:Controleer uw stuurprogramma 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 FDO van het PnP-apparaat niet een naam te geven 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 de volgende artikelen voor meer informatie over het beheren van 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 de volgende artikelen 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

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 toegang tot stuurprogramma's te beheren met behulp van de hierboven besproken technieken.

Zie de volgende artikelen voor meer informatie:

Definiëring van I/O-besturingscodes

HVCI-compatibele code implementeren

controlelijstpunt #8:Controleer of uw stuurprogramma geheugen gebruikt dat compatibel is met HVCI.

Geheugengebruik en HVCI-compatibiliteit

HVCI maakt gebruik van hardwaretechnologie en virtualisatie om de beslissingsfunctie Code Integrity (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.

De best practices voor technologiespecifieke code volgen

beveiligingscontrole-lijstitem #9:raadpleeg de volgende technologie-specifieke richtlijnen voor uw driver.

Bestandssystemen

Zie de volgende artikelen 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

NDIS - Netwerken

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

Beeldscherm

Voor informatie over de beveiliging van beeldschermstuurprogramma's, zie <Inhoud in behandeling>.

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.

Beveiliging van apparaatinstallatie verbeteren

beveiligingscontrolelijstitem #10:Richtlijnen voor het maken en installeren van stuurprogramma's controleren om ervoor te zorgen dat u de aanbevolen procedures volgt.

Wanneer u de code maakt waarmee uw stuurprogramma 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 de volgende artikelen voor meer informatie:

Beveiligde apparaatinstallaties maken

Richtlijnen voor het gebruik van SetupAPI

Apparaatinstallatiefuncties gebruiken

Geavanceerde onderwerpen over installatie van apparaten en stuurprogramma's

Peercodebeoordeling uitvoeren

Beveiligingscontrolelijstpunt #11:Peer code controleren om te zoeken naar problemen die niet door de andere hulpprogramma's en processen aan het licht komen

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.

De juiste ondertekening uitvoeren voor de release drivers

controlelijstitem voor beveiliging #12:Gebruik de Windows-partnerportal om uw stuurprogramma goed te ondertekenen voor distributie.

Voordat u een stuurprogrammapakket voor het publiek vrijgeeft, raden we u aan het pakket voor certificering in te dienen. Zie Test voor prestaties en compatibiliteit, Aan de slag met het Hardware-programma, Hardware Dashboard Servicesen Attestation-ondertekening van een kernelstuurprogramma voor openbare release.

CodeQL gebruiken om uw stuurprogrammacode te controleren

item #13 van de beveiligingscontrolelijst: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 hulpmiddel voor het beveiligen van stuurprogrammacode. Zie CodeQL en de Static Tools Logo Testvoor meer informatie.

SAL-aantekeningen toevoegen aan uw stuurprogrammacode

Controlelijstitem voor beveiliging #14:SAL-aantekeningen toevoegen aan in 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. https://www.osr.com/blog/2015/02/23/sal-annotations-dont-hate-im-beautiful/

Stuurprogrammacontrole gebruiken om te controleren op beveiligingsproblemen

item van de beveiligingscontrolelijst #15:Gebruik de Driver Verifier-tool om te controleren op kwetsbaarheden 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. DV vindt defecten in stuurprogrammacode die kan verwijzen naar mogelijke bugs 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. Stuurprogrammaverificator kan de Windows-stuurprogramma's aan verschillende stress en tests onderwerpen om onjuist gedrag te vinden. Zie Driver Verifiervoor meer informatie.

Houd er rekening mee dat alleen bepaalde typen stuurprogramma's worden ondersteund door DV. Zie Ondersteunde stuurprogramma'svoor meer informatie over de stuurprogramma's die dv kan verifiëren. Raadpleeg de volgende pagina's voor informatie over de DV-tests die beschikbaar zijn voor het type stuurprogramma waarmee u werkt.

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 BinSkim Binary Analyzer

beveiligingscontrolelijstitem #16:Volg deze stappen om BinSkim te gebruiken om te controleren of compileer- en buildopties zijn geconfigureerd om bekende beveiligingsproblemen te minimaliseren.

Gebruik BinSkim om binaire bestanden te onderzoeken om coderings- en bouwprocedures te identificeren die het binaire bestand mogelijk kwetsbaar kunnen 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.

Code controleren met de tests van het hardwarecompatibiliteitsprogramma

controlelijstitem beveiliging #17: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.

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

controlelijstitem voor beveiliging #18: Begrijpen hoe stuurprogramma's worden gerapporteerd met behulp van het Rapportagecentrum voor kwetsbare en schadelijke stuurprogramma's van Microsoft

Iedereen kan een twijfelachtige driver indienen met behulp van het Rapportagecentrum voor kwetsbare en schadelijke stuurprogramma's van Microsoft. 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 coderen van stuurprogramma's in kernelmodus beveiligen

Creëren van betrouwbare Kernel-Mode drivers

Veilige coderingsorganisaties

Carnegie Mellon University SEI CERT

Carnegie Mellon University SEI CERT C Coding Standard: Rules for Developing Safe, Reliable and Secure Systems (2016 Edition).

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

Building Security In Maturity Model (BSIMM) - https://www.bsimm.com/

SAFECode - https://safecode.org/

CISA-bronnen

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?

Case Study

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

Boeken

24 dodelijke zonden van softwarebeveiliging: programmeerfouten en hoe ze kunnen worden opgelost door Michael Howard, David LeBlanc en John Viega

De kunst van softwarebeveiligingsevaluatie: softwareproblemen identificeren en voorkomen, Mark Dowd, John McDonald en Justin Schuh

Writing Secure Software Second Edition, Michael Howard en David LeBlanc

De kunst van softwarebeveiligingsbeoordeling: Het identificeren en voorkomen van softwarekwetsbaarheden, Mark Dowd en John McDonald

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:

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 codescans om te zoeken naar bekende beveiligingsproblemen in code en om 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.