Elenco di controllo per la sicurezza dei driver

Questo articolo fornisce un elenco di controllo per la sicurezza dei driver che consente agli sviluppatori di driver di ridurre il rischio di compromissione dei driver.

Panoramica della sicurezza dei driver

Un difetto di sicurezza è qualsiasi difetto che consente a un utente malintenzionato di causare un malfunzionamento di un driver in modo tale che causa l'arresto anomalo del sistema o diventa inutilizzabile. Inoltre, le vulnerabilità nel codice del driver possono consentire a un utente malintenzionato di accedere al kernel, creando una possibilità di compromettere l'intero sistema operativo. Quando la maggior parte degli sviluppatori lavora sul driver, il loro obiettivo è quello di fare in modo che il driver funzioni correttamente e non sul fatto che un utente malintenzionato tenti di sfruttare le vulnerabilità all'interno del codice.

Dopo il rilascio di un driver, tuttavia, gli utenti malintenzionati possono tentare di eseguire il probe e identificare i difetti di sicurezza. Gli sviluppatori devono considerare questi problemi durante la fase di progettazione e implementazione per ridurre al minimo la probabilità di tali vulnerabilità. L'obiettivo è eliminare tutti i difetti di sicurezza noti prima del rilascio del driver.

La creazione di driver più sicuri richiede la collaborazione dell'architetto di sistema (consapevolemente pensando a potenziali minacce al driver), lo sviluppatore implementa il codice (codificando in modo difensivo le operazioni comuni che possono essere l'origine degli exploit) e il team di test (cercando in modo proattivo di individuare vulnerabilità e vulnerabilità). Coordinando correttamente tutte queste attività, la sicurezza del conducente è notevolmente migliorata.

Oltre a evitare i problemi associati a un driver che viene attaccato, molti dei passaggi descritti, ad esempio l'uso più preciso della memoria del kernel, aumentano l'affidabilità del driver. Ciò ridurrà i costi di supporto e aumenterà la soddisfazione dei clienti con il prodotto. Il completamento delle attività nell'elenco di controllo seguente consentirà di raggiungere tutti questi obiettivi.

Elenco di controllo perla sicurezza: completare l'attività di sicurezza descritta in ognuno di questi argomenti.

Verificare che sia necessario un driver del kernel

Usare i framework driver

Controllare l'accesso solo ai driver software

Non firmare il codice del driver di test di produzione

Eseguire l'analisi delle minacce

Seguire le linee guida per la codifica sicura dei driver

Implementare codice compatibile con HVCI

Seguire le procedure consigliate per il codice specifico della tecnologia

Eseguire la revisione del codice peer

Gestire il controllo di accesso del driver

Migliorare la sicurezza dell'installazione dei dispositivi

Eseguire la firma corretta del driver di versione

Usare l'analisi del codice in Visual Studio per analizzare la sicurezza dei driver

Usare Static Driver Verifier per verificare la presenza di vulnerabilità

Controllare il codice con BinSkim Binary Analyzer

Usare gli strumenti di convalida del codice

Esaminare le tecniche e le estensioni del debugger

Informazioni sul modo in cui i driver vengono segnalati tramite Microsoft Vulnerable and Malicious Driver Reporting Center

Esaminare le risorse di codifica sicure

Esaminare il riepilogo delle considerazioni chiave

Verificare che sia necessario un driver del kernel

Elemento dell'elenco di controllo di sicurezza n. 1:Verificare che sia necessario un driver del kernel e che un approccio a rischio inferiore, ad esempio il servizio o l'app di Windows, non sia un'opzione migliore.

I driver si trovano nel kernel Di Windows e si verificano problemi durante l'esecuzione nel kernel espongono l'intero sistema operativo. Se è disponibile un'altra opzione, è probabile che il costo sia inferiore e abbia meno rischi associati rispetto alla creazione di un nuovo driver del kernel. Per altre informazioni sull'uso dei driver windows predefiniti, vedere Scrivere un driver?

Per informazioni sull'uso delle attività in background, vedi Supportare l'app con le attività in background.

Per informazioni sull'uso dei servizi Windows, vedere Servizi.

Usare i framework driver

Elemento dell'elenco di controllo di sicurezza n. 2:Usare i framework driver per ridurre le dimensioni del codice e aumentarne l'affidabilità e la sicurezza.

Usare Windows Driver Frameworks per ridurre le dimensioni del codice e aumentarne l'affidabilità e la sicurezza. Per iniziare, vedere Uso di WDF per sviluppare un driver. Per informazioni sull'uso del driver UMDF (User Mode Framework Driver) a basso rischio, vedere Scelta di un modello di driver.

La scrittura di un driver WINDOWS Driver Model (WDM) di vecchia moda richiede più tempo, costoso e quasi sempre comporta la ricreazione del codice disponibile nei framework driver.

Il codice sorgente di Windows Driver Framework è open source e disponibile in GitHub. Si tratta dello stesso codice sorgente da cui viene compilata la libreria di runtime WDF inclusa in Windows 10. È possibile eseguire il debug del driver in modo più efficace quando è possibile seguire le interazioni tra il driver e WDF. Scaricarlo da https://github.com/Microsoft/Windows-Driver-Frameworks.

Controllare l'accesso solo ai driver software

Elemento dell'elenco di controllo di sicurezza n. 3:Se verrà creato un driver solo software, è necessario implementare un controllo di accesso aggiuntivo.

I driver kernel solo software non usano plug-and-play (PnP) per diventare associati a ID hardware specifici e possono essere eseguiti in qualsiasi PC. Tale driver può essere usato per scopi diversi da quello originariamente previsto, creando un vettore di attacco.

Poiché i driver del kernel solo software contengono rischi aggiuntivi, devono essere limitati all'esecuzione su hardware specifico (ad esempio, usando un ID PnP univoco per abilitare la creazione di un driver PnP o controllando la tabella SMBIOS per la presenza di hardware specifico).

Si supponga, ad esempio, che OEM Fabrikam voglia distribuire un driver che consenta un'utilità di overclocking per i propri sistemi. Se questo driver solo software doveva essere eseguito su un sistema da un OEM diverso, l'instabilità del sistema o il danno potrebbe causare. I sistemi di Fabrikam devono includere un ID PnP univoco per consentire la creazione di un driver PnP aggiornabile anche tramite Windows Update. Se questo non è possibile e Fabrikam autori un driver legacy, tale driver deve trovare un altro metodo per verificare che sia in esecuzione in un sistema Fabrikam (ad esempio, esaminando la tabella SMBIOS prima di abilitare qualsiasi funzionalità).

Non firmare il codice di test di produzione

Elemento dell'elenco di controllo di sicurezza n. 4:Non firmare il codice di produzione per lo sviluppo, il test e il codice del driver del kernel di produzione.

Il codice del driver kernel usato per lo sviluppo, il test o la produzione può includere funzionalità pericolose che rappresentano un rischio per la sicurezza. Questo codice pericoloso non deve mai essere firmato con un certificato considerato attendibile da Windows. Il meccanismo corretto per l'esecuzione di codice driver pericoloso consiste nel disabilitare l'avvio protetto UEFI, abilitare il BCD "TESTSIGNING" e firmare il codice di sviluppo, test e produzione usando un certificato non attendibile (ad esempio, uno generato da makecert.exe).

Il codice firmato da una firma SPC (Software Publishers Certificate) attendibile o da una firma WHQL (Hardware Quality Labs) di Windows non deve facilitare il bypass dell'integrità del codice e delle tecnologie di sicurezza di Windows. Prima che il codice venga firmato da una firma SPC o WHQL attendibile, assicurarsi prima di tutto che sia conforme alle linee guida della creazione di driver reliable Kernel-Mode. Inoltre, il codice non deve contenere comportamenti pericolosi, descritti di seguito. Per altre informazioni sulla firma del driver, vedere Firma del driver di versione più avanti in questo articolo.

Di seguito sono riportati alcuni esempi di comportamenti pericolosi:

• Possibilità di eseguire il mapping di kernel, memoria fisica o dispositivo arbitraria alla modalità utente.
• Possibilità di leggere o scrivere kernel arbitrario, memoria fisica o del dispositivo, tra cui input/output della porta (I/O).
• Fornire l'accesso all'archiviazione che ignora il controllo di accesso di Windows.
• Possibilità di modificare l'hardware o il firmware che il driver non è stato progettato per la gestione.

Eseguire l'analisi delle minacce

Elemento dell'elenco di controllo di sicurezza n. 5:modificare un modello di minaccia driver esistente o creare un modello di minaccia personalizzato per il driver.

In considerazione della sicurezza, una metodologia comune consiste nel creare modelli di minaccia specifici che tentano di descrivere i tipi di attacchi possibili. Questa tecnica è utile quando si progetta un driver perché impone allo sviluppatore di considerare in anticipo i potenziali vettori di attacco contro un driver. Dopo aver identificato potenziali minacce, uno sviluppatore di driver può quindi prendere in considerazione mezzi di difesa contro queste minacce per rafforzare la sicurezza complessiva del componente driver.

Questo articolo fornisce indicazioni specifiche per il driver per la creazione di un modello di minaccia leggero: modellazione delle minacce per i driver. L'articolo fornisce un diagramma del modello di minaccia del driver di esempio che può essere usato come punto di partenza per il driver.

Le procedure consigliate per il ciclo di vita dello sviluppo della sicurezza (SDL) e gli strumenti associati possono essere usati da IHD e OEM per migliorare la sicurezza dei propri prodotti. Per altre informazioni, vedere Suggerimenti sdl per gli OEM.

Seguire le linee guida per la codifica sicura dei driver

Elemento dell'elenco di controllo di sicurezza n. 6:Esaminare il codice e rimuovere eventuali vulnerabilità del codice note.

L'attività principale della creazione di driver sicuri consiste nell'identificare le aree nel codice che devono essere modificate per evitare vulnerabilità software note. Molte di queste vulnerabilità software note gestiscono un monitoraggio rigoroso dell'uso della memoria per evitare problemi con altri utenti sovrascrivendo o comprendendo in altro modo i percorsi di memoria usati dal driver.

La sezione Strumenti di convalida del codice di questo articolo descrive gli strumenti software che possono essere usati per individuare le vulnerabilità software note.

Buffer di memoria

• Controllare sempre le dimensioni dei buffer di input e output per assicurarsi che i buffer possano contenere tutti i dati richiesti. Per altre informazioni, vedere Errore di controllo delle dimensioni dei buffer.

• Inizializzare correttamente tutti i buffer di output con zeri prima di restituirli al chiamante. Per altre informazioni, vedere Errore di inizializzazione dei buffer di output.

• Convalidare i buffer a lunghezza variabile. Per altre informazioni, vedere Failure to Validate Variable-Length Buffers.For more information, see Failure to Validate Variable-Length Buffers. Per altre informazioni sull'uso dei buffer e sull'uso di ProbeForRead e ProbeForWrite per convalidare l'indirizzo di un buffer, vedere Gestione dei buffer.

Usare il metodo appropriato per accedere ai buffer di dati con IOCTLs

Una delle principali responsabilità di un driver di Windows è il trasferimento dei dati tra le applicazioni in modalità utente e i dispositivi di un sistema. I tre metodi per l'accesso ai buffer di dati sono illustrati nella tabella seguente.

Tipo di buffer IOCTL	Riepilogo	Per ulteriori informazioni
METHOD_BUFFERED	Consigliato per la maggior parte delle situazioni	Uso dell'I/O memorizzato nel buffer
METHOD_IN_DIRECT o METHOD_OUT_DIRECT	Usato in alcune operazioni di I/O HW ad alta velocità	Uso di I/O diretto
METHOD_NEITHER	Evitare, se possibile,	Uso né di I/O con buffering né diretto

In generale, le operazioni di I/O memorizzate nel buffer sono consigliate perché forniscono i metodi di buffering più sicuri. Ma anche quando si usano operazioni di I/O memorizzate nel buffer esistono rischi, ad esempio puntatori incorporati che devono essere mitigati.

Per altre informazioni sull'uso dei buffer in IOCTLs, vedere Metodi per l'accesso ai buffer di dati.

Errori nell'uso di I/O memorizzati nel buffer IOCTL

• Controllare le dimensioni dei buffer correlati a IOCTL. Per altre informazioni, vedere Errore di controllo delle dimensioni dei buffer.

• Inizializzare correttamente i buffer di output. Per altre informazioni, vedere Errore di inizializzazione dei buffer di output.

• Convalidare correttamente i buffer a lunghezza variabile. Per altre informazioni, vedere Failure to Validate Variable-Length Buffers.For more information, see Failure to Validate Variable-Length Buffers.

• Quando si usa l'I/O memorizzato nel buffer, assicurarsi e restituire la lunghezza corretta per OutputBuffer nel campo Informazioni struttura IO_STATUS_BLOCK . Non restituire direttamente la lunghezza direttamente da una richiesta READ. Si consideri ad esempio una situazione in cui i dati restituiti dallo spazio utente indicano che è presente un buffer 4K. Se il driver deve restituire effettivamente solo 200 byte, ma restituisce invece solo 4K nel campo Informazioni si è verificata una vulnerabilità di divulgazione di informazioni. Questo problema si verifica perché nelle versioni precedenti di Windows il buffer usato da Gestione I/O per I/O memorizzato nel buffer non è zero. Di conseguenza, l'app utente recupera i 200 byte originali di dati più 4K-200 byte di qualsiasi elemento nel buffer (contenuto del pool non di paging). Questo scenario può verificarsi con tutti gli usi di I/O memorizzati nel buffer e non solo con IOCTL.

Errori nell'I/O diretto I/O IOCTL

Gestire correttamente i buffer di lunghezza zero. Per altre informazioni, vedere Errori nell'I/O diretto.

Errori nel riferimento agli indirizzi dello spazio utente

• Convalidare i puntatori incorporati nelle richieste di I/O memorizzate nel buffer. Per altre informazioni, vedere Errori in Riferimento User-Space indirizzi.

• Convalidare qualsiasi indirizzo nello spazio utente prima di provare a usarlo, usando API come ProbeForRead e ProbeForWrite quando appropriato.

Letture e scritture specifiche del modello MSR

Gli intrinseci del compilatore, ad esempio __readmsr e __writemsr , possono essere usati per accedere ai registri specifici del modello. Se questo accesso è obbligatorio, il driver deve sempre verificare che il registro in lettura o scrittura sia vincolato all'indice o all'intervallo previsto.

Per altre informazioni ed esempi di codice, vedere Fornire la possibilità di leggere/scrivere richieste pull nelle procedure consigliate per la sicurezza dello sviluppo per gli sviluppatori di driver Windows.

Vulnerabilità TOCTOU

Esiste un potenziale tempo di verifica dell'ora di utilizzo (TOCTOU) vulnerabilità quando si usano operazioni di I/O dirette (per IOCTLs o per lettura/scrittura). Tenere presente che il driver accede al buffer dei dati utente, l'utente può accedervi contemporaneamente.

Per gestire questo rischio, copiare tutti i parametri che devono essere convalidati dal buffer dei dati utente alla memoria accessibile esclusivamente dalla modalità kernel,ad esempio lo stack o il pool. Dopo aver eseguito l'accesso ai dati dall'applicazione utente, convalidare e quindi operare sui dati passati.

Il codice del driver deve usare correttamente la memoria

• Tutte le allocazioni del pool di driver devono trovarsi nel pool non eseguibile (NX). L'uso di pool di memoria NX è intrinsecamente più sicuro rispetto all'uso di pool eseguibili non di paging (NP) e offre una migliore protezione dagli attacchi di overflow.

• I driver di dispositivo devono gestire correttamente varie modalità utente, nonché il kernel per le richieste di I/O del kernel.

Per consentire ai driver di supportare la virtualizzazione HVCI, sono previsti requisiti di memoria aggiuntivi. Per altre informazioni, vedere Implementare codice compatibile con HVCI più avanti in questo articolo.

Selettori

• Convalidare gli handle passati tra la memoria in modalità utente e quella in modalità kernel. Per altre informazioni, vedere Gestire la gestione e la mancata convalida degli handle di oggetti.

Oggetti dispositivo

• Proteggere gli oggetti dispositivo. Per altre informazioni, vedere Protezione degli oggetti dispositivo.

• Convalidare gli oggetti dispositivo. Per altre informazioni, vedere Errore di convalida degli oggetti dispositivo.

IrP

WDF e IRP

Un vantaggio dell'uso di WDF è che i driver WDF in genere non accedono direttamente ai runtime di integrazione. Ad esempio, il framework converte i runtime di integrazione WDM che rappresentano operazioni di lettura, scrittura e controllo di I/O del dispositivo in oggetti richiesta dal framework che KMDF/UMDF riceve nelle code di I/O.

Se si scrive un driver WDM, esaminare le indicazioni seguenti.

Gestire correttamente i buffer di I/O IRP

Gli articoli seguenti forniscono informazioni sulla convalida dei valori di input IRP:

DispatchReadWrite con I/O memorizzato nel buffer

Errori nell'I/O memorizzato nel buffer

DispatchReadWrite con I/O diretto

Errori nell'I/O diretto

Problemi di sicurezza per i codici di controllo di I/O

Valutare la possibilità di convalidare i valori associati a un provider di identità, ad esempio indirizzi e lunghezze del buffer.

Se si sceglie di usare Nessuno dei due I/O, tenere presente che, a differenza di Lettura e scrittura, e diversamente da I/O memorizzati nel buffer e I/O diretto, quando si usano I/O IOCTL, i puntatori e le lunghezze del buffer non vengono convalidati da Gestione I/O.

Gestire correttamente le operazioni di completamento di IRP

Un driver non deve mai completare un IRP con un valore di stato di STATUS_SUCCESS a meno che non supporti e non elabori effettivamente l'IRP. Per informazioni sui modi corretti per gestire le operazioni di completamento di IRP, vedere Completamento dei runtime di integrazione.

Gestire lo stato di IRP del driver in sospeso

Il driver deve contrassegnare l'IRP in sospeso prima di salvare l'IRP e deve considerare la possibilità di includere sia la chiamata a IoMarkIrpPending che l'assegnazione in una sequenza interlocked. Per altre informazioni, vedere Errore di controllo dello stato di un driver e mantenimento di irP in ingresso quando un dispositivo viene sospeso.

Gestire correttamente le operazioni di annullamento di IRP

Le operazioni di annullamento possono essere difficili da scrivere correttamente perché in genere vengono eseguite in modo asincrono. I problemi nel codice che gestisce le operazioni di annullamento possono passare inosservati per molto tempo, perché questo codice in genere non viene eseguito frequentemente in un sistema in esecuzione. Assicurarsi di leggere e comprendere tutte le informazioni fornite in Annullamento dei runtime di integrazione. Prestare particolare attenzione alla sincronizzazione dell'annullamento di IRP e dei punti da considerare durante l'annullamento dei runtime di integrazione.

Un modo consigliato per ridurre al minimo i problemi di sincronizzazione associati alle operazioni di annullamento consiste nell'implementare una coda IRP sicura per l'annullamento.

Gestire correttamente le operazioni di pulizia e chiusura di IRP

Assicurarsi di comprendere la differenza tra IRP_MJ_CLEANUP e IRP_MJ_CLOSE richieste. Le richieste di pulizia arrivano dopo che un'applicazione chiude tutti gli handle in un oggetto file, ma a volte prima che tutte le richieste di I/O siano state completate. Le richieste di chiusura arrivano dopo il completamento o l'annullamento di tutte le richieste di I/O per l'oggetto file. Per altre informazioni, vedere gli articoli seguenti:

Routine DispatchCreate, DispatchClose e DispatchCreateClose

Routine DispatchCleanup

Errori nella gestione delle operazioni di pulizia e chiusura

Per altre informazioni sulla gestione corretta dei runtime di integrazione, vedere Errori aggiuntivi nella gestione dei runtime di integrazione.

Altri problemi di sicurezza

• Usare un blocco o una sequenza interlocked per impedire le race condition. Per altre informazioni, vedere Errori in un ambiente multiprocessore.

• Assicurarsi che i driver di dispositivo gestiscono correttamente varie modalità utente e kernel per le richieste di I/O del kernel.

• Assicurarsi che non siano installati filtri o LSP TDI dal driver o dai pacchetti software associati durante l'installazione o l'utilizzo.

Usare funzioni sicure

• Usare funzioni stringa sicure. Per altre informazioni, vedere Uso di funzioni stringa sicure.

• Usare funzioni aritmetice sicure. Per altre informazioni, vedere Routine di libreria integer sicura

• Usare funzioni di conversione sicure.

Vulnerabilità di codice aggiuntive

Oltre alle possibili vulnerabilità descritte in questo articolo, questo articolo fornisce informazioni aggiuntive sul miglioramento della sicurezza del codice del driver in modalità kernel: Creazione di driver reliable Kernel-Mode.

Per altre informazioni sulla codifica sicura C e C++, vedere Proteggere le risorse di codifica alla fine di questo articolo.

Gestire il controllo di accesso del driver

Elemento elenco di controllo di sicurezza #7:Esaminare il driver per assicurarsi di controllare correttamente l'accesso.

Gestione del controllo di accesso del driver - WDF

I driver devono funzionare per impedire agli utenti di accedere in modo inappropriato ai dispositivi e ai file di un computer. Per impedire l'accesso non autorizzato ai dispositivi e ai file, è necessario:

• Assegnare un nome agli oggetti dispositivo solo quando necessario. Gli oggetti dispositivo denominati sono in genere necessari solo per motivi legacy, ad esempio se si dispone di un'applicazione che prevede di aprire il dispositivo usando un nome specifico o se si usa un dispositivo/controllo non PNP. Si noti che i driver WDF non devono assegnare un nome all'oggetto FDO del dispositivo PnP per creare un collegamento simbolico usando WdfDeviceCreateSymbolicLink.

• Proteggere l'accesso agli oggetti e alle interfacce del dispositivo.

Per consentire alle applicazioni o ad altri driver WDF di accedere al PDO del dispositivo PnP, è consigliabile usare le interfacce del dispositivo. Per altre informazioni, vedere Uso di interfacce dispositivo. Un'interfaccia del dispositivo funge da collegamento simbolico al PDO dello stack di dispositivi.

Uno dei modi migliori per controllare l'accesso al PDO è specificando una stringa SDDL nel file INF. Se la stringa SDDL non è nel file INF, Windows applicherà un descrittore di sicurezza predefinito. Per altre informazioni, vedere Protezione di oggetti dispositivo e SDDL per oggetti dispositivo.

Per altre informazioni sul controllo dell'accesso, vedere gli articoli seguenti:

Controllo dell'accesso ai dispositivi nei driver KMDF

Nomi, descrittori di sicurezza e classi di dispositivo - Rendere accessibili gli oggetti dispositivo... e SAFE da gennaio 2017 La newsletter NT Insider pubblicata da OSR.

Gestione del controllo di accesso del driver - WDM

Se si usa un driver WDM e si usa un oggetto dispositivo denominato, è possibile usare IoCreateDeviceSecure e specificare uno SDDL per proteggerlo. Quando si implementa IoCreateDeviceSecure specifica sempre un GUID di classe personalizzato per DeviceClassGuid. Non è consigliabile specificare qui un GUID di classe esistente. In questo modo è possibile interrompere le impostazioni di sicurezza o la compatibilità per altri dispositivi appartenenti a tale classe. Per altre informazioni, vedere WdmlibIoCreateDeviceSecure.

Per altre informazioni, vedere gli articoli seguenti:

Controllo dell'accesso ai dispositivi

Controllo dell'accesso dello spazio dei nomi dei dispositivi

Modello di sicurezza di Windows per sviluppatori di driver

Gerarchia di rischi (SID) degli identificatori di sicurezza

La sezione seguente descrive la gerarchia di rischi dei SID comuni usati nel codice driver. Per informazioni generali su SDDL, vedere SDDL per oggetti dispositivo, stringhe SID e sintassi di stringa SDDL.

È importante comprendere che se i chiamanti con privilegi inferiori possono accedere al kernel, il rischio di codice è aumentato. In questo diagramma di riepilogo il rischio aumenta man mano che si consentono l'accesso ai SID con privilegi inferiori alla funzionalità del driver.

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

Seguendo il principio di sicurezza dei privilegi minimi generale, configurare solo il livello minimo di accesso necessario per la funzione del driver.

Controllo di sicurezza IOCTL granulare WDM

Per gestire ulteriormente la sicurezza quando gli IOCTLs vengono inviati dai chiamanti in modalità utente, il codice driver può includere la funzione IoValidateDeviceIoControlAccess . Questa funzione consente a un driver di controllare i diritti di accesso. Dopo aver ricevuto un IOCTL, un driver può chiamare IoValidateDeviceIoControlAccess, specificando FILE_READ_ACCESS, FILE_WRITE_ACCESS o entrambi.

L'implementazione di un controllo di sicurezza IOCTL granulare non sostituisce la necessità di gestire l'accesso ai driver usando le tecniche descritte in precedenza.

Per altre informazioni, vedere gli articoli seguenti:

Definizione dei codici di controllo di I/O

Implementare il codice compatibile con HVCI

Elemento dell'elenco di controllo di sicurezza #8:Convalidare che il driver usi memoria in modo che sia compatibile con HVCI.

Compatibilità con l'utilizzo della memoria e HVCI

HVCI usa la tecnologia hardware e la virtualizzazione per isolare la funzione decisionale di Integrità del codice (CI) dal resto del sistema operativo. Quando si usa la sicurezza basata su virtualizzazione per isolare l'ci, l'unico modo in cui la memoria del kernel può diventare eseguibile è tramite una verifica CI. Ciò significa che le pagine di memoria del kernel non possono mai essere scrivibili e eseguibili (W+X) e il codice eseguibile non può essere modificato direttamente.

Per implementare il codice compatibile con HVCI, assicurarsi che il codice del driver sia il seguente:

• Opta per NX per impostazione predefinita
• Usa API/flag NX per l'allocazione della memoria (NonPagedPoolNx)
• Non usa sezioni sia scrivibili che eseguibili
• Non tenta di modificare direttamente la memoria del sistema eseguibile
• Non usa codice dinamico nel kernel
• Non carica i file di dati come eseguibile
• L'allineamento della sezione è un multiplo di 0x1000 (PAGE_SIZE). Ad esempio DRIVER_ALIGNMENT=0x1000

Per altre informazioni sull'uso dello strumento e un elenco di chiamate di memoria incompatibili, vedere Implementare il codice compatibile con HVCI.

Per altre informazioni sul test di sicurezza dei concetti fondamentali del sistema correlato, vedere Test di conformità all'integrità del codice HyperVisor e Integrità del codice protetto da Hypervisor.For more information about the related system fundamentals security test, see HyperVisor Code Integrity Test and Hypervisor-Protected Code Integrity (HVCI).For more information about the related system fundamentals security test, see HyperVisor Code Readiness Test and Hypervisor-Protected Code Integrity (HVCI).

Seguire le procedure consigliate per il codice specifico della tecnologia

Elemento elenco di controllo di sicurezza #9:Esaminare le indicazioni specifiche per la tecnologia seguenti per il driver.

File system

Per altre informazioni sulla sicurezza dei driver di file system, vedere gli articoli seguenti:

Introduzione alla sicurezza dei file system

Problemi di sicurezza del file system

Funzionalità di sicurezza per i file system

Coesistenza con altri driver di filtro file system

NDIS - Rete

Per informazioni sulla sicurezza dei driver NDIS, vedere Problemi di sicurezza per i driver di rete.

Visualizza

Per informazioni sulla sicurezza del driver visualizzato, vedere <Contenuto in sospeso>.

Stampanti

Per informazioni sulla sicurezza dei driver della stampante, vedere Considerazioni sulla sicurezza del driver della stampante V4.

Problemi di sicurezza per i driver windows di acquisizione immagini (WIA)

Per informazioni sulla sicurezza WIA, vedere Problemi di sicurezza per i driver WIA (Windows Image Acquisition).

Migliorare la sicurezza dell'installazione dei dispositivi

Elemento dell'elenco di controllo di sicurezza #10:Esaminare le linee guida per la creazione e l'installazione dei driver per assicurarsi di seguire le procedure consigliate.

Quando si crea il codice che installa il driver, è necessario assicurarsi che l'installazione del dispositivo venga sempre eseguita in modo sicuro. Un'installazione sicura del dispositivo è una delle operazioni seguenti:

• Limita l'accesso al dispositivo e alle relative classi di interfaccia del dispositivo
• Limita l'accesso ai servizi driver creati per il dispositivo
• Protegge i file del driver dalla modifica o dall'eliminazione
• Limita l'accesso alle voci del Registro di sistema del dispositivo
• Limita l'accesso alle classi WMI del dispositivo
• Usa le funzioni SetupAPI correttamente

Per altre informazioni, vedere gli articoli seguenti:

Creazione di installazioni di dispositivi sicure

Linee guida per l'uso di SetupAPI

Uso delle funzioni di installazione del dispositivo

Argomenti avanzati sull'installazione di dispositivi e driver

Eseguire la revisione del codice peer

Elemento dell'elenco di controllo di sicurezza n. 11:Eseguire la revisione del codice peer, per cercare i problemi non rilevati dagli altri strumenti e processi

Cercare revisori esperti del codice per cercare problemi che potrebbero non essere stati rilevati. Un secondo set di occhi spesso noterà problemi che potresti aver trascurato.

Se non si dispone di personale adatto per esaminare il codice internamente, prendere in considerazione l'impegno esterno per questo scopo.

Eseguire la firma corretta del driver di versione

Elemento dell'elenco di controllo di sicurezza n. 12:Usare il portale per i partner Windows per firmare correttamente il driver per la distribuzione.

Prima di rilasciare un pacchetto driver al pubblico, è consigliabile inviare il pacchetto per la certificazione. Per altre informazioni, vedere Testare le prestazioni e la compatibilità, Introduzione al programma hardware, ai servizi dashboard hardware e all'attestazione firmando un driver kernel per la versione pubblica.

Usare l'analisi del codice in Visual Studio per analizzare la sicurezza dei driver

Elemento dell'elenco di controllo di sicurezza n. 13:Seguire questa procedura per usare la funzionalità di analisi del codice in Visual Studio per verificare la presenza di vulnerabilità nel codice del driver.

Usare la funzionalità di analisi del codice in Visual Studio per verificare la presenza di vulnerabilità di sicurezza nel codice. Windows Driver Kit (WDK) installa i set di regole progettati per verificare la presenza di problemi nel codice del driver nativo.

Per altre informazioni, vedere Come eseguire l'analisi del codice per i driver.

Per altre informazioni, vedere Panoramica dell'analisi del codice per i driver. Per altre informazioni sull'analisi del codice, vedere Visual Studio 2013 analisi approfondita del codice statico.

Per acquisire familiarità con l'analisi del codice, è possibile usare uno dei driver di esempio, ad esempio l'esempio https://github.com/Microsoft/Windows-driver-samples/tree/main/general/toaster/toastDrv/kmdf/func/featured di tostapane in primo piano o l'esempio https://github.com/Microsoft/Windows-driver-samples/tree/main/security/elamantimalware per il lancio anticipato ELAM .

1. Aprire la soluzione driver in Visual Studio.

2. In Visual Studio, per ogni progetto nella soluzione modificare le proprietà del progetto in modo da usare il set di regole desiderato. Ad esempio: Proprietà progetto >>>> Analisi >> codice Generale, selezionare Regole driver consigliate. Oltre a usare le regole del driver iniziate, usare il set di regole native consigliate .

3. Selezionare Compila >> esegui analisi del codice nella soluzione.

4. Visualizzare gli avvisi nella scheda Elenco errori della finestra di output della compilazione in Visual Studio.

Selezionare la descrizione per ogni avviso per visualizzare l'area problematica nel codice.

Selezionare il codice di avviso collegato per visualizzare informazioni aggiuntive.

Determinare se è necessario modificare il codice o se è necessario aggiungere un'annotazione per consentire al motore di analisi del codice di seguire correttamente la finalità del codice. Per altre informazioni sull'annotazione del codice, vedere Using SAL Annotations to Reduce C/C++ Code Defects and SAL 2.0 Annotations for Windows Drivers.For more information on code annotations, see Using SAL Annotations to Reduce C/C++ Code Defects and SAL 2.0 Annotations for Windows Drivers.

Per informazioni generali su SAL, vedere questo articolo disponibile in OSR. https://www.osr.com/blog/2015/02/23/sal-annotations-dont-hate-im-beautiful/

Usare Static Driver Verifier per verificare la presenza di vulnerabilità

Elemento dell'elenco di controllo di sicurezza n. 14:Seguire questa procedura per usare l'sdk (Static Driver Verifier) in Visual Studio per verificare la presenza di vulnerabilità nel codice del driver.

Static Driver Verifier (SDV) usa un set di regole di interfaccia e un modello del sistema operativo per determinare se il driver interagisce correttamente con il sistema operativo Windows. SDV rileva i difetti nel codice del driver che potrebbero puntare a potenziali bug nei driver.

Per altre informazioni, vedere Introducing Static Driver Verifier and Static Driver Verifier.For more information, see Introducing Static Driver Verifier and Static Driver Verifier.

Si noti che solo alcuni tipi di driver sono supportati da SDV. Per altre informazioni sui driver che SDV possono verificare, vedere Driver supportati. Per informazioni sui test SDV disponibili per il tipo di driver in uso, vedere le pagine seguenti.

• Regole per i driver WDM
• Regole per i driver KMDF
• Regole per i driver NDIS
• Regole per i driver Storport
• Regole per i driver audio
• Regole per i driver AVStream

Per acquisire familiarità con SDV, è possibile usare uno dei driver di esempio (ad esempio, l'esempio di tostapane in primo piano: https://github.com/Microsoft/Windows-driver-samples/tree/main/general/toaster/toastDrv/kmdf/func/featured).

1. Aprire la soluzione driver di destinazione in Visual Studio.

2. In Visual Studio modificare il tipo di compilazione in Rilascio. Static Driver Verifier richiede che il tipo di compilazione sia rilasciato, non di debug.

3. In Visual Studio selezionare Compila >> soluzione di compilazione.

4. In Visual Studio selezionare Driver Launch Static Driver Verifier (Avvia driver >> statico verifier).

5. In SDV, nella scheda Regole selezionare Predefinito in Set di regole.

   Anche se le regole predefinite trovano molti problemi comuni, prendere in considerazione anche l'esecuzione del set di regole del driver più esteso.

6. Nella scheda Principale di SDV selezionare Avvia.

7. Al termine dell'SDV, esaminare eventuali avvisi nell'output. Nella scheda Principale viene visualizzato il numero totale di difetti rilevati.

8. Selezionare ogni avviso per caricare la pagina del report SDV ed esaminare le informazioni associate alla possibile vulnerabilità del codice. Usare il report per analizzare il risultato della verifica e identificare i percorsi nel driver che non soddisfano una verifica SDV. Per altre informazioni, vedere Static Driver Verifier Report.For more information, see Static Driver Verifier Report.

Controllare il codice con l'analizzatore binario BinSkim

Elemento dell'elenco di controllo di sicurezza n. 15:Seguire questa procedura per usare BinSkim per verificare che le opzioni di compilazione e compilazione siano configurate per ridurre al minimo i problemi di sicurezza noti.

Usare BinSkim per esaminare i file binari per identificare la scrittura di codice e le procedure di compilazione che possono potenzialmente rendere vulnerabile il file binario.

BinSkim verifica la presenza di:

• Uso di set di strumenti del compilatore obsoleti: i file binari devono essere compilati in base ai set di strumenti del compilatore più recenti, laddove possibile, per ottimizzare l'uso delle mitigazioni di sicurezza correnti a livello di compilatore e del sistema operativo.
• Impostazioni di compilazione non sicure: i file binari devono essere compilati con le impostazioni più sicure possibili per abilitare le mitigazioni della sicurezza fornite dal sistema operativo, ottimizzare gli errori del compilatore e segnalare avvisi interattivi, tra le altre cose.
• Problemi di firma: i file binari firmati devono essere firmati con algoritmi con crittografia avanzata.

BinSkim è uno strumento open source e genera file di output che usano il formato SARIF (Static Analysis Results Interchange Format). BinSkim sostituisce l'ex strumento BinScope .

Per altre informazioni su BinSkim, vedere la Guida dell'utente binSkim.

Seguire questa procedura per verificare che le opzioni di compilazione della sicurezza siano configurate correttamente nel codice da spedire.

1. Scaricare e installare .NET Core SDK multipiattaforma.

2. Verificare che Visual Studio sia installato. Per informazioni sul download e l'installazione di Visual Studio, vedere Installare Visual Studio.

3. Sono disponibili diverse opzioni per scaricare BinSkim, ad esempio un pacchetto NuGet. In questo esempio si userà l'opzione git clone per scaricarla da qui: https://github.com/microsoft/binskim e installarla in un PC Windows a 64 bit.

4. Aprire una finestra del prompt dei comandi per gli sviluppatori di Visual Studio e creare una directory, ad esempio C:\binskim-master.

   C:\> Md \binskim-master
   

5. Passare alla directory appena creata.

   C:\> Cd \binskim-master
   

6. Usare il comando git clone per scaricare tutti i file necessari.

   C:\binskim-master> git clone --recurse-submodules https://github.com/microsoft/binskim.git
   

7. Passare alla nuova binskim dirctory creata dal comando clone.

   C:\> Cd \binskim-master\binskim
   

8. Eseguire BuildAndTest.cmd per assicurarsi che la build di versione abbia esito positivo e che tutti i test superino.

   C:\binskim-master\binskim> BuildAndTest.cmd
   
   Welcome to .NET Core 3.1!
   ---------------------
   SDK Version: 3.1.101
   
   ...
   
   C:\binskim-master\binskim\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\win-x64\BinSkim.Sdk.dll
   1 File(s) copied
   C:\binskim-master\binskim\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\linux-x64\BinSkim.Sdk.dll
   1 File(s) copied
   
   ...
   
   

9. Il processo di compilazione crea un set di directory con i file eseguibili BinSkim. Passare alla directory di output di compilazione win-x64.

   C:\binskim-master\binskim> Cd \binskim-master\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\win-x64>
   

10. Visualizzare la Guida per l'opzione di analisi.

C:\binskim-master\binskim\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\win-x64> BinSkim help analyze

BinSkim PE/MSIL Analysis Driver 1.6.0.0

--sympath                      Symbols path value, e.g., SRV*http://msdl.microsoft.com/download/symbols or Cache*d:\symbols;Srv*http://symweb. See
                              https://learn.microsoft.com/windows-hardware/drivers/debugger/advanced-symsrv-use for syntax information. Note that BinSkim will clear the
                              _NT_SYMBOL_PATH environment variable at runtime. Use this argument for symbol information instead.

--local-symbol-directories     A set of semicolon-delimited local directory paths that will be examined when attempting to locate PDBs.

-o, --output                   File path to which analysis output will be written.

--verbose                      Emit verbose output. The resulting comprehensive report is designed to provide appropriate evidence for compliance scenarios.

...

Impostazione del percorso del simbolo

Se si sta creando tutto il codice analizzato nello stesso computer in cui si esegue BinSkim, in genere non è necessario impostare il percorso del simbolo. Ciò è dovuto al fatto che i file di simboli sono disponibili nella casella locale in cui è stata compilata. Se si usa un sistema di compilazione più complesso o si reindirizzano i simboli in una posizione diversa (non insieme al file binario compilato), usare --local-symbol-directories per aggiungere questi percorsi alla ricerca di file di simboli. Se il codice fa riferimento a un file binario compilato che non fa parte del codice, il debugger window sympath può essere usato per recuperare i simboli per verificare la sicurezza di queste dipendenze del codice. Se si verifica un problema in queste dipendenze, potrebbe non essere possibile risolverli. Tuttavia, può essere utile essere consapevoli di eventuali rischi per la sicurezza accettati prendendo in considerazione tali dipendenze.

Suggerimento

Quando si aggiunge un percorso di simbolo (che fa riferimento a un server di simboli di rete), aggiungere un percorso della cache locale per specificare un percorso locale per memorizzare nella cache i simboli. Questa operazione non può compromettere notevolmente le prestazioni di BinSkim. Nell'esempio seguente viene specificata una cache locale in d:\symbols. --sympath Cache*d:\symbols;Srv*http://symweb Per altre informazioni su sympath, vedere Percorso dei simboli per i debugger Windows.

1. Eseguire il comando seguente per analizzare un file binario del driver compilato. Aggiornare il percorso di destinazione in modo che punti al file .sys driver conforme.

   C:\binskim-master\binskim\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\win-x64> BinSkim analyze "C:\Samples\KMDF_Echo_Driver\echo.sys"
   

2. Per altre informazioni, aggiungere l'opzione dettagliata in questo modo.

   C:\binskim-master\binskim\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\win-x64> BinSkim analyze "C:\Samples\KMDF_Echo_Driver\osrusbfx2.sys" --verbose
   

   Nota

   L'opzione --verbose produrrà risultati espliciti di superamento/esito negativo per ogni controllo. Se non fornisci dettagli, vedrai solo i difetti rilevati da BinSkim. L'opzione --verbose in genere non è consigliata per i sistemi di automazione effettivi a causa della maggiore dimensione dei file di log e perché rende più difficile raccogliere singoli errori quando si verificano, perché verranno incorporati in mezzo a un numero elevato di risultati "pass".

3. Esaminare l'output del comando per cercare i possibili problemi. Questo output di esempio mostra tre test superati. Altre informazioni sulle regole, ad esempio BA2002, sono disponibili nella Guida dell'utente di BinSkim.

   Analyzing...
   Analyzing 'osrusbfx2.sys'...
   ...
   
   C:\Samples\KMDF_Echo_Driver\osrusbfx2.sys\Debug\osrusbfx2.sys: pass BA2002: 'osrusbfx2.sys' does not incorporate any known vulnerable dependencies, as configured by current policy.
   C:\Samples\KMDF_Echo_Driver\Debug\osrusbfx2.sys: pass BA2005: 'osrusbfx2.sys' is not known to be an obsolete binary that is vulnerable to one or more security problems.
   C:\Samples\KMDF_Echo_Driver\osrusbfx2.sys: pass BA2006: All linked modules of 'osrusbfx2.sys' generated by the Microsoft front-end satisfy configured policy (compiler minimum version 17.0.65501.17013).
   

4. Questo output mostra che il test BA3001 non viene eseguito come lo strumento indica che il driver non è un file binario ELF.

   ...
   C:\Samples\KMDF_Echo_Driver\Debug\osrusbfx2.sys: notapplicable BA3001: 'osrusbfx2.sys' was not evaluated for check 'EnablePositionIndependentExecutable' as the analysis is not relevant based on observed metadata: image is not an ELF binary.
   

5. Questo output mostra un errore per il test BA2007.

   ...
   
   C:\Samples\KMDF_Echo_Driver\Debug\osrusbfx2.sys: error BA2007: 'osrusbfx2.sys' disables compiler warning(s) which are required by policy.
   A compiler warning is typically required if it has a high likelihood of flagging memory corruption, information disclosure, or double-free vulnerabilities.
   To resolve this issue, enable the indicated warning(s) by removing /Wxxxx switches (where xxxx is a warning id indicated here) from your command line, and resolve any warnings subsequently raised during compilation.
   

Per abilitare questi avvisi in Visual Studio, in C/C++ nelle pagine delle proprietà del progetto rimuovere i valori che non si desidera escludere in Disabilita avvisi specifici.

Le opzioni di compilazione predefinite in Visual Studio per i progetti driver possono disabilitare gli avvisi, ad esempio i seguenti. Questi avvisi verranno segnalati da BinSkim.

C4603 - 'name': la macro non è definita o la definizione è diversa dopo l'uso dell'intestazione precompilata

C4627 - 'description': ignorato quando si cerca l'uso dell'intestazione precompilata

C4986 - 'declaration': la specifica dell'eccezione non corrisponde alla dichiarazione precedente

Per altre informazioni sugli avvisi del compilatore, vedere Avvisi del compilatore per versione del compilatore.

Usare altri strumenti di convalida del codice

Elemento dell'elenco di controllo di sicurezza n. 16:Usare questi strumenti aggiuntivi per verificare che il codice segua le raccomandazioni sulla sicurezza e per verificare eventuali lacune mancanti nel processo di sviluppo.

Oltre all'analisi di Visual Studio Code, Static Driver Verifier e Binskim illustrati in precedenza, usare gli strumenti seguenti per verificare le lacune mancanti nel processo di sviluppo.

Driver Verifier

Driver Verifier consente il test in tempo reale del driver. Driver Verifier monitora driver e driver grafici in modalità kernel di Windows per rilevare chiamate o azioni di funzioni non valide che potrebbero danneggiare il sistema. Driver Verifier può sottoporre i driver di Windows a una serie di stress e test per trovare un comportamento non corretto. Per altre informazioni, vedere Driver Verifier.

Test del programma di compatibilità hardware

Il programma di compatibilità hardware include test correlati alla sicurezza che possono essere usati per cercare vulnerabilità del codice. Windows Hardware Compatibility Program sfrutta i test in Windows Hardware Lab Kit (HLK). I test dei concetti fondamentali del dispositivo HLK possono essere usati nella riga di comando per esercitare il codice del driver e verificare la debolezza. Per informazioni generali sui test dei concetti fondamentali del dispositivo e sul programma di compatibilità hardware, vedere Windows Hardware Lab Kit.

I test seguenti sono esempi di test che possono essere utili per controllare il codice driver per alcuni comportamenti associati alle vulnerabilità del codice:

DF - Test IOCTL casuale fuzz (affidabilità)

DF - Test con apertura secondaria fuzz (affidabilità)

DF - Buffer di lunghezza zero fuzz BUFFER (affidabilità)

DF - Test CASUALE CASUALE PFTL fuzz (affidabilità)

DF - Test dell'API Fuzz Misc (affidabilità)

È anche possibile usare il ritardo di sincronizzazione del kernel incluso in Driver Verifier.

I test chaos (hardware e sistema operativo simultanei) eseguono diversi test driver PnP, test fuzz del driver di dispositivo e test del sistema di alimentazione simultaneamente. Per altre informazioni, vedere Chaos Tests (Device Fundamentals).

I test di penetrazione dei concetti fondamentali del dispositivo eseguono varie forme di attacchi di input, che sono un componente fondamentale dei test di sicurezza. I test di attacco e penetrazione consentono di identificare le vulnerabilità nelle interfacce software. Per altre informazioni, vedere Test di penetrazione (Nozioni fondamentali sui dispositivi).For more information, see Penetration Tests (Device Fundamentals).

Usare Il test di conformità di Device Guard, insieme agli altri strumenti descritti in questo articolo, per verificare che il driver sia compatibile con HVCI.

Strumenti di test personalizzati e specifici del dominio

Prendere in considerazione lo sviluppo di test di sicurezza personalizzati specifici del dominio. Per sviluppare test aggiuntivi, raccogliere input dai progettisti originali del software, nonché risorse di sviluppo non correlate che hanno familiarità con il tipo specifico di driver in fase di sviluppo e una o più persone che hanno familiarità con l'analisi e la prevenzione delle intrusioni di sicurezza.

Esaminare le tecniche e le estensioni del debugger

Elemento dell'elenco di controllo per la sicurezza n. 17:Esaminare questi strumenti del debugger e prendere in considerazione l'uso nel flusso di lavoro di debug dello sviluppo.

Comandi del debugger correlati alla sicurezza

L'estensione !acl formatta e visualizza il contenuto di un elenco di controllo di accesso (ACL). Per altre informazioni, vedere Determinazione dell'ACL di un oggetto e di !acl.

L'estensione !token visualizza una visualizzazione formattata di un oggetto token di sicurezza. Per altre informazioni, vedere !token.

L'estensione !tokenfields visualizza i nomi e gli offset dei campi all'interno dell'oggetto token di accesso (struttura TOKEN). Per altre informazioni, vedere !tokenfields.

L'estensione !sid visualizza l'identificatore di sicurezza (SID) nell'indirizzo specificato. Per altre informazioni, vedere !sid.

L'estensione !sd visualizza il descrittore di sicurezza in corrispondenza dell'indirizzo specificato. Per altre informazioni, vedere !sd.

Centro segnalazioni di driver vulnerabili e dannosi Microsoft

Chiunque può inviare un driver discutibile usando Microsoft Vulnerable and Malicious Driver Reporting Center. Fare riferimento a questa voce di blog per informazioni su come vengono inviati i driver per l'analisi - Migliorare la sicurezza del kernel con il nuovo Microsoft Vulnerable and Malicious Driver Reporting Center

Reporting Center può analizzare e analizzare i driver di Windows creati per architetture x86 e x64. I driver vulnerabili e dannosi analizzati vengono contrassegnati per l'analisi e l'analisi da parte del team vulnerabile di Microsoft Driver. Dopo aver confermato i drivervulernable, viene generata una notifica appropriata, vengono aggiunti all'elenco di blocchi di driver vulnerabili. Per altre informazioni, vedere Regole di blocco dei driver consigliate da Microsoft. Queste regole sono abilitate per impostazione predefinita per i dispositivi abilitati per Hypervisor-protected code integrity (HVCI) e Windows 10 in modalità S.

Esaminare le risorse di codifica sicure

Elemento dell'elenco di controllo per la sicurezza n. 18:Esaminare queste risorse per espandere la comprensione delle procedure consigliate per la codifica sicura applicabili agli sviluppatori di driver.

Esaminare queste risorse per altre informazioni sulla sicurezza dei driver

Linee guida per la codifica del driver in modalità kernel sicure

Creazione di driver reliable Kernel-Mode

Proteggere le organizzazioni che codificano

Carnegie Mellon University SEI CERT

Carnegie Mellon University SEI CERT C Coding Standard: regole per lo sviluppo di sistemi sicuri, affidabili e sicuri (edizione 2016).

MITRE - Punti deboli risolti dallo standard di codifica sicura CERT C

Creazione di sicurezza nel modello di maturità (BSIMM) - https://www.bsimm.com/

SAFECode - https://safecode.org/

Risorse CISA

OSR

OSR offre servizi di formazione e consulenza per lo sviluppo di driver. Questi articoli della newsletter OSR evidenziano i problemi di sicurezza dei driver.

Nomi, descrittori di sicurezza e classi di dispositivo - Rendere accessibili gli oggetti dispositivo... e SAFE

È necessario usare la protezione: all'interno del driver & sicurezza dei dispositivi

Blocco dei driver - Un sondaggio sulle tecniche

Meltdown e Spectre: Che ne dici dei piloti?

Case study

Dall'avviso alla vulnerabilità del driver: Microsoft Defender'indagine ATP che annulla l'escalation dei privilegi

Libri

24 peccati mortali di sicurezza del software : difetti di programmazione e come risolverli da Michael Howard, David LeBlanc e John Viega

L'arte della valutazione della sicurezza software: identificazione e prevenzione delle vulnerabilità software, Mark Dowd, John McDonald e Justin Schuh

Scrittura di Secure Software Second Edition, Michael Howard e David LeBlanc

L'arte della valutazione della sicurezza software: identificazione e prevenzione delle vulnerabilità software, Mark Dowd e John McDonald

Codifica sicura in C e C++ (SEI Series in Software Engineering) seconda edizione, Robert C. Seacord

Programmazione del modello di driver di Microsoft Windows (seconda edizione), Walter Oney

Sviluppo di driver con Windows Driver Foundation (Riferimento per sviluppatori), Penny Orwick e Guy Smith

Formazione

La formazione per le classi dei driver di Windows è disponibile dai fornitori, ad esempio:

• OSR
• Winsider
• Azius

La formazione online per la codifica sicura è disponibile da un'ampia gamma di origini. Ad esempio, questo corso è disponibile da coursera on:

Identificazione delle vulnerabilità di sicurezza nella programmazione C/C++.

SAFECode offre anche formazione gratuita:

SAFECode.org/training

Certificazione professionale

CERT offre una certificazione Secure Coding Professional.

Riepilogo delle considerazioni chiave

La sicurezza dei driver è un'impresa complessa contenente molti elementi, ma ecco alcuni punti chiave da considerare:

• I driver si trovano nel kernel windows e si verificano problemi durante l'esecuzione nel kernel espongono l'intero sistema operativo. Per questo motivo, prestare particolare attenzione alla sicurezza dei driver e alla progettazione tenendo conto della sicurezza.

• Applicare il principio dei privilegi minimi:

  a. Usare una stringa SDDL strict per limitare l'accesso al driver

  b. Limitare ulteriormente i singoli IOCTL

• Creare un modello di minaccia per identificare i vettori di attacco e valutare se è possibile limitare ulteriormente qualsiasi elemento.

• Prestare attenzione per quanto riguarda i puntatori incorporati passati dalla modalità utente. È necessario eseguire il probe, accedere all'interno di try tranne e sono soggetti a tempi di controllo dell'ora di utilizzo (ToCToU), a meno che il valore del buffer non venga acquisito e confrontato.

• Se non si è certi, usare METHOD_BUFFERED come metodo di buffering IOCTL.

• Usare le utilità di analisi del codice per cercare vulnerabilità del codice note e correggere eventuali problemi identificati.

• Cercare revisori esperti del codice per cercare problemi che potrebbero non essere stati rilevati.

• Usare i verificatori del driver e testare il driver con più input, inclusi i case degli angoli.