Amministrazione di Windows

Il kernel di Windows Vista: parte 3

Mark Russinovich

 

Panoramica:

• Affidabilità
• Ripristino
• Protezione

Con questa serie di articoli si sono analizzati i miglioramenti del kernel di Windows Vista relativi a processi, I/O, gestione della memoria, avvio del sistema, arresto del sistema e risparmio di energia. In questa terza e ultima puntata

vengono illustrati i miglioramenti apportati alle funzionalità nelle aree di affidabilità, ripristino e protezione.

Una funzionalità che non verrà esaminata in questa serie è il controllo dell'account utente, che comprende alcune tecnologie, tra cui la virtualizzazione di file system e Registro di sistema per le applicazioni legacy, il consenso all'elevazione per accedere ai diritti amministrativi e il meccanismo dei livelli di integrità di Windows® per isolare i processi in esecuzione con i diritti amministrativi dai processi meno-privilegiati in esecuzione nello stesso account. In uno dei prossimi numeri di TechNet Magazine sarà pubblicato un articolo interamente dedicato al controllo dell'account utente.

Windows Vista™ migliora l'affidabilità del sistema e la capacità di diagnosticare i problemi di sistema e applicazioni grazie a numerosi miglioramenti e nuove funzionalità. Traccia eventi per Windows (ETW) del kernel, ad esempio, è sempre attivo e genera eventi traccia per file, Registro di sistema, interrupt e altri tipi di attività in un buffer circolare. Quando si verifica un problema, la nuova Infrastruttura diagnostica Windows (WDI) cattura un'istantanea del buffer e l'analizza localmente oppure la invia al supporto Microsoft per la risoluzione del problema.

Il nuovo monitoraggio di affidabilità e prestazioni di Windows consente agli utenti di mettere in correlazione gli errori, come arresti anomali o blocchi del sistema, con le modifiche apportate alla configurazione del sistema. Lo strumento di riparazione del sistema (SRT) sostituisce la Console di ripristino di emergenza per il ripristino non in linea di sistemi che non si avviano.

Esistono tre ulteriori aree che hanno beneficiato delle modifiche a livello di kernel e quindi meritano un'attenzione particolare: Gestione transazioni kernel, la migliore gestione degli arresti anomali del sistema e Versioni precedenti.

Gestione transazioni kernel

Uno degli aspetti più noiosi dello sviluppo di software è la gestione delle condizioni di errore. Questo è soprattutto vero se, nel corso dell'esecuzione di un'operazione ad alto livello, un'applicazione completa uno o più sottoprocessi che apportano modifiche al file system o al Registro di sistema. Un servizio di aggiornamento software di un'applicazione, ad esempio, potrebbe apportare diverse modifiche al Registro di sistema, sostituire uno degli eseguibili dell'applicazione e non riuscire più a ottenere l'accesso per l'aggiornamento di un secondo eseguibile. Per non lasciare l'applicazione in uno stato incoerente, il servizio deve tenere traccia di tutte le modifiche eseguite ed essere in grado di annullarle. La verifica del codice di ripristino dall'errore è complessa e, di conseguenza, spesso ignorata. Gli errori nel codice di ripristino rendono quindi vano lo sforzo.

Le applicazioni scritte per Windows Vista sono in grado, con un minimo sforzo, di garantire funzionalità di ripristino dall'errore in modo automatico utilizzando il nuovo supporto transazionale in NTFS e il Registro di sistema con Gestione transazioni kernel. Quando un'applicazione deve eseguire numerose modifiche correlate, è possibile creare una transazione di Distributed Transaction Coordinator (DTC) e un handle di transazione di Gestione transazioni kernel oppure creare direttamente un handle di Gestione transazioni kernel e associare le modifiche dei file e delle chiavi del Registro di sistema alla transazione. Se tutte le modifiche riescono, l'applicazione esegue il commit della transazione e le modifiche vengono applicate, ma l'applicazione può revocare in qualsiasi momento la transazione e annullare le modifiche.

Un ulteriore vantaggio è costituito dal fatto che le altre applicazioni non rilevano le modifiche apportate in una transazione finché non viene eseguito il commit della transazione. Le applicazioni che utilizzano il DTC in Windows Vista e nel nuovo Windows Server® con nome in codice "Longhorn" potranno coordinare le transazioni con SQL Server™, Microsoft® Message Queue Server (MSMQ) e altri database. Un servizio di aggiornamento dell'applicazione che utilizza le transazioni di Gestione transazioni kernel non lascerà mai l'applicazione in uno stato incoerente. È per questo che in Windows Update e in Ripristino configurazione di sistema si utilizzano le transazioni.

In qualità di nucleo del supporto delle transazioni, Gestione transazioni kernel consente ai gestori delle risorse di transazione come NTFS e il Registro di sistema di coordinare i rispettivi aggiornamenti per una serie specifica di modifiche apportate da un'applicazione. In Windows Vista, NTFS utilizza un'estensione denominata TxF per il supporto delle transazioni. Il Registro di sistema utilizza un'estensione simile denominata TxR. Questi gestori delle risorse in modalità kernel collaborano con Gestione transazioni kernel per coordinare lo stato della transazione, proprio come i gestori delle risorse in modalità utente utilizzano DTC per coordinare lo stato della transazione in più gestori delle risorse in modalità utente. Anche le terze parti possono utilizzare Gestione transazioni kernel per implementare i propri gestori delle risorse.

TxF e TxR definiscono entrambi una nuova serie di API del file system e del Registro di sistema simili a quelli esistenti, con la differenza che questi contengono un parametro di transazione. Se un'applicazione deve creare un file all'interno di una transazione, viene dapprima utilizzato Gestione transazioni kernel per creare la transazione, quindi l'handle che ne risulta viene passato all'API della creazione del nuovo-file.

TxF e TxR si basano entrambi sulla funzionalità di registrazione del file system ad alta velocità del Common Log File System o CLFS (%SystemRoot%\System32\Clfs.sys) introdotto con Windows Server 2003 R2. TxR e TxF utilizzano CLFS per memorizzare in modo durevole le modifiche dello stato delle transazioni prima di eseguirne il commit. In tal modo le estensioni sono in grado di garantire ripristino transazionale e protezione anche in caso di interruzione dell'alimentazione. Oltre al registro di CLFS, TxR crea una serie di file di registro correlati per tenere traccia delle modifiche apportate dalle transazioni al file di Registro di sistema in %Systemroot%\System32\Config\Txr, come illustrato nella Figura 1, oltre a ulteriori serie di file di registro per ciascun hive del Registro di sistema dell'utente. TxF memorizza i dati di transazione per ciascun volume in una directory nascosta del volume denominata $Extend\$RmMetadata.

Figura 1** File di registrazione di TxR degli hive del Registro di sistema  **(Fare clic sull'immagine per ingrandirla)

Miglior supporto in caso di arresto anomalo

Quando si verifica un errore in modalità kernel irreversibile, causato da un driver di dispositivo difettoso, da hardware guasto o dal sistema operativo, Windows tenta di evitare il danneggiamento dei dati memorizzati su disco arrestando il sistema dopo la famigerata "schermata blu" e, se così configurato, scrivendo il contenuto di parte o dell'intera memoria fisica in un file dei dettagli dell'arresto anomalo. I file con i dettagli dell'arresto anomalo sono utili perché, quando si riavvia il sistema dopo un arresto anomalo, il servizio Microsoft di analisi dell'arresto anomalo (OCA) può analizzarli alla ricerca della causa principale del problema. È possibile analizzare i file personalmente utilizzando gli strumenti di debug per Windows.

Nelle versioni precedenti di Windows, tuttavia, il supporto per il file con i dettagli dell'arresto anomalo non veniva attivato fino a che il processo Gestione sessione (%Systemroot%\System32\Smss.exe) non inizializzava i file di paging. Dunque un qualsiasi errore critico che si verificava prima di tale momento provocava una schermata blu senza però alcun file con i dettagli dell'arresto anomalo. Poiché l'inizializzazione dei driver di dispositivo viene eseguita prima dell'avvio di Smss.exe, gli arresti anomali che si verificavano prima di tale avvio non producevano file con i dettagli dell'arresto anomalo, rendendo così molto complessa la diagnosi della causa del problema.

Con Windows Vista il periodo di tempo in cui è possibile che si verifichino arresti anomali senza la generazione di un file con i dettagli si è ridotto in modo notevole. Ora il supporto del file con i dettagli dell'arresto anomalo viene inizializzato dopo l'avvio di tutti i driver di dispositivo, ma prima del caricamento dei driver di avvio del sistema. Grazie a questa modifica, quando si verifica un arresto anomalo durante la prima parte del processo di avvio, il sistema riesce a catturare i dettagli dell'arresto, consentendo a OCA di aiutare gli utenti a risolvere il problema. Inoltre, in Windows Vista i dati vengono salvati in un file di dump in blocchi di 64 KB, mentre nelle versioni precedenti di Windows il file veniva scritto utilizzando blocchi di 4 KB. Ne consegue che i file di dump di grandi dimensioni vengono scritti con velocità fino a 10 volte maggiori.

In Windows Vista è migliorata anche la gestione dei blocchi delle applicazioni. Quando un'applicazione si bloccava nelle versioni precedenti di Windows, eseguiva un gestore di eccezioni non gestite. Il gestore avviava il processo Segnalazione errori applicazioni Microsoft (AER) (%Systemroot%\System32\Dwwin.exe) e veniva visualizzata una finestra di dialogo con cui si informava l'utente del blocco di un'applicazione e si richiedeva di inviare una segnalazione di errore a Microsoft. Tuttavia, se lo stack del thread principale del processo veniva danneggiato durante il blocco, anche il gestore di eccezioni non gestite si bloccava durante l'esecuzione. Ne risultavano l'interruzione del processo da parte del kernel, la scomparsa immediata delle finestre del programma e l'assenza della finestra di dialogo di segnalazione errori.

In Windows Vista la gestione degli errori viene sottratta al contesto del processo bloccato grazie a un nuovo servizio, Segnalazione errori Windows (WER). Il servizio è implementato da una DLL (%Systemroot%\System32\Wersvc.dll) all'interno di un processo di hosting di servizi. Quando si blocca, l'applicazione esegue ancora un gestore di eccezioni non gestite, ma il gestore invia un messaggio al servizio WER e il servizio avvia il processo Segnalazione problemi di WER (%Systemroot%\System32\Werfault.exe) visualizzando una finestra di dialogo di segnalazione degli errori. Se lo stack è danneggiato e il gestore di eccezioni non gestite si blocca, il gestore viene eseguito e si blocca di nuovo occupando alla fine tutto lo stack del thread (spazio della memoria di lavoro), interviene il kernel che invia il messaggio di notifica del blocco al servizio.

È possibile apprezzare la differenza fra questi due approcci nelle figure 2 e 3, che illustrano il rapporto tra i processi di Accvio.exe, un programma di test che si blocca, e i processi di segnalazione degli errori evidenziati in verde, in Windows XP e Windows Vista. La nuova architettura di Windows Vista per la gestione degli errori prevede che i programmi non vengano più interrotti in modo invisibile all'utente, senza offrire a Microsoft la possibilità di ottenere un resoconto e agli sviluppatori di software l'opportunità di migliorare le applicazioni.

Figura 2a** Gestione degli errori delle applicazioni in Windows XP **(Fare clic sull'immagine per ingrandirla)

Figura 2b(Fare clic sull'immagine per ingrandirla)

Figura 3a** Gestione degli errori delle applicazioni in Windows Vista **(Fare clic sull'immagine per ingrandirla)

Figura 3b

Copia Shadow del volume

Con Windows XP è stata introdotta una tecnologia denominata Copia Shadow del volume per creare istantanee temporizzate dei volumi di un disco. Le applicazioni di backup possono utilizzare queste istantanee per ottenere immagini di backup coerenti, ma le istantanee restano altrimenti nascoste e conservate solo per la durata del processo di backup.

Le istantanee non sono delle copie complete dei volumi. Sono piuttosto delle viste di un volume da un punto precedente che comprende i dati del volume sostituiti dalle copie di settori di volume modificati dopo lo scatto dell'istantanea. Il driver del provider di istantanee di volume (%Systemroot\%System32\Drivers\Volsnap.sys) controlla le operazioni eseguite con i volumi ed esegue copie di backup dei settori prima di consentirne la modifica, memorizzando i dati originali in un file associato all'istantanea nella directory delle informazioni del volume di sistema del volume.

In Windows Server 2003 la gestione delle istantanee era disponibile agli amministratori sul server e agli utenti sui sistemi client grazie alle copie shadow per cartelle condivise. Questa funzionalità consentiva di scattare istantanee persistenti, a cui gli utenti potevano accedere tramite la scheda Versioni precedenti delle finestre di dialogo delle proprietà di Esplora risorse relative alle cartelle e ai file archiviati nelle condivisioni del server.

Con la funzionalità Versioni precedenti di Windows Vista il supporto è stato esteso a tutti i sistemi client, con la creazione automatica di istantanee di volume, in genere una volta al giorno, a cui è possibile accedere tramite le finestre di dialogo delle proprietà di Esplora risorse, utilizzando la stessa interfaccia utilizzata dalle copie shadow per cartelle condivise. È quindi possibile visualizzare, ripristinare o copiare le versioni precedenti di file e directory modificati o eliminati accidentalmente. L'implementazione di Versioni precedenti della funzionalità Copia Shadow del volume di Windows Vista, sebbene non sia una tecnologia del tutto nuova, ottimizza la funzionalità omologa di Windows Server 2003 per l'uso negli ambienti dei desktop client.

In Windows Vista si sfruttano inoltre le istantanee di volume per unificare i meccanismi di protezione dei dati di utente e sistema ed evitare il salvataggio di dati di backup ridondanti. Quando una modifica apportata all'installazione o configurazione di un'applicazione causa dei comportamenti errati o non desiderati, è possibile utilizzare Ripristino configurazione di sistema, una funzionalità introdotta nella linea di sistemi operativi Windows NT ® con Windows XP, per ripristinare lo stato di file di sistema e dati esistente al momento della creazione del punto di ripristino.

In Windows XP la funzionalità Ripristino configurazione di sistema utilizza un driver di filtro del file system, un tipo di driver in grado di rilevare le modifiche a livello di file, per eseguire copie di backup dei file di sistema subito prima della modifica. In Windows Vista la funzionalità Ripristino configurazione di sistema utilizza le istantanee di volume. Quando si utilizza l'interfaccia utente di Ripristino configurazione di sistema in Windows Vista per tornare a un punto di ripristino, si copiano le versioni precedenti dei file di sistema modificati dall'istantanea associata al punto di ripristino nel volume corrente.

BitLocker

Windows Vista è la versione di Windows meglio protetta mai prodotta. Oltre al motore antispyware di Windows Defender, in Windows Vista sono state implementate molte funzionalità di protezione e difesa, tra cui la crittografia di un intero volume con BitLocker™, la firma del codice per il codice in modalità kernel, i processi protetti, la sequenza casuale di caricamento nello spazio degli indirizzi e i miglioramenti della protezione del servizio Windows e del controllo degli account utente.

Un sistema operativo può applicare i propri criteri di protezione solo quando è attivo, quindi è necessario adottare misure aggiuntive per proteggere i dati quando la protezione fisica di un sistema può essere compromessa con un accesso non autorizzato ai dati dall'esterno del sistema operativo. I meccanismi basati sull'hardware come le password del BIOS e la crittografia sono due delle tecnologie più diffuse per impedire l'accesso non autorizzato, soprattutto nei computer portatili, che sono più soggetti a smarrimento o furto.

In Windows 2000 è stata introdotta la Crittografia file system (EFS) e, nella rispettiva incarnazione di Windows Vista, all'EFS sono stati apportati numerosi miglioramenti rispetto alle implementazioni precedenti, con miglioramento delle prestazioni, supporto per la codifica del file di paging e archiviazione delle chiavi EFS dell'utente su smart card. Non è tuttavia possibile utilizzare EFS per proteggere l'accesso ad aree sensibili del sistema, come i file di hive del Registro di sistema. Se, ad esempio, Criteri di gruppo consente di accedere al computer portatile anche quando non si è connessi a un dominio, i sistemi di verifica delle credenziali di dominio vengono memorizzati nella cache del Registro di sistema, in modo che un utente malintenzionato possa utilizzare degli strumenti per ottenere l'hash della password dell'account di dominio da impiegare per tentare di ottenere la password con uno strumento apposito. La password consentirebbe agli utenti malintenzionati di accedere all'account e ai file EFS (se non si è memorizzata la chiave EFS su una smart card).

Per facilitare la crittografia completa del volume di avvio (il volume con la directory di Windows), compresi tutti i file di sistema e i dati, in Windows Vista è stata aggiunta una funzionalità per la crittografia dell'intero volume denominata Crittografia unità BitLocker di Windows. A differenza di EFS, che viene implementato dal driver del file system NTFS e opera a livello di file, BitLocker esegue la crittografia a livello di volume utilizzando il driver FVE (Full Volume Encryption) (%Systemroot%\System32\Drivers\Fvevol.sys) come illustrato nella Figura 4.

Figura 4** Driver di filtro FVE di BitLocker **(Fare clic sull'immagine per ingrandirla)

FVE è un driver di filtro ed è in grado di rilevare automaticamente tutte le richieste di I/O inviate da NTFS al volume, crittografando i blocchi alla scrittura e decrittografandoli quando vengono letti utilizzando la chiave FVEK assegnata al volume durante la configurazione iniziale per BitLocker. Per impostazione predefinita, i volumi vengono crittografati utilizzando una chiave AES a 128 bit e una chiave di diffusione a 128 bit. Poiché crittografia e decrittografia avvengono sotto NTFS nel sistema di I/O, il volume appare a NTFS come se fosse decrittografato e non è nemmeno necessario che NTFS rilevi l'attivazione di BitLocker. Se di tenta di leggere i dati del volume dall'esterno di Windows, tuttavia, i dati sembrano essere casuali.

La FVEK viene crittografata con una chiave master del volume (VMK) e viene memorizzata in un'area di metadati speciale del volume. Quando si configura BitLocker, è possibile scegliere tra alcune opzioni per la protezione della VMK, a seconda dell'hardware del sistema. Se nel sistema è disponibile un TPM (Trusted Platform Module) conforme alla v1.2 delle specifiche TPM con il supporto del BIOS associato, sarà possibile crittografare la VMK con il TPM, impostare il sistema in modo che la VMK venga crittografata utilizzando una chiave memorizzata nel TPM e un'altra memorizzata su un dispositivo flash USB oppure crittografare la chiave utilizzando una chiave memorizzata nel TPM e un PIN immesso all'avvio del sistema. Per i sistemi che non dispongono di un TPM, BitLocker consente di crittografare la VMK utilizzando una chiave memorizzata su un dispositivo flash USB esterno. In tutti i casi sarà necessario un volume di sistema NTFS da 1,5 GB non crittografato, il volume in cui memorizzare Boot Manager e dati di configurazione di avvio (BCD).

Il vantaggio dell'utilizzo di un TPM consiste nella possibilità di utilizzare le funzionalità del TPM con BitLocker per garantire che la VMK non venga decrittografata e il volume di avvio sbloccato se il BIOS o i file di avvio del sistema risultano modificati rispetto al momento dell'attivazione di BitLocker. Quando si crittografa il volume di sistema per la prima volta, e ogni volta che si esegue l'aggiornamento di uno dei componenti menzionati, BitLocker calcola l'hash SHA-1 di tale componente e memorizza ciascun hash, definito misura, in registri di configurazione di piattaforma (PCR) diversi del TPM con l'aiuto del driver di dispositivo TPM (%Systemroot%\System32\Drivers\Tpm.sys). BitLocker utilizza quindi il TPM per eseguire il sealing della VMK, un'operazione che prevede l'impiego di una chiave privata memorizzata nel TPM per crittografare la VMK e i valori memorizzati nei PCR, insieme agli altri dati che BitLocker passa al TPM. BitLocker memorizza quindi la VMK sottoposta a sealing e la FVEK crittografata nella regione di metadati del volume.

Quando viene avviato, il sistema misura il proprio hash e il codice di caricamento del PCR e scrive l'hash nel primo PCR del TPM. Quindi viene eseguito l'hash del BIOS e tale misura viene memorizzata nel PCR appropriato. Il BIOS esegue invece l'hash del componente successivo nella sequenza di avvio, ovvero il Record di avvio principale (MBR) del volume di avvio, e questo processo continua fino a quando non viene misurato il caricatore del sistema operativo. Ciascuna porzione successiva di codice eseguita è responsabile della misurazione del codice caricato e della memorizzazione della misurazione nel registro del TPM appropriato. Quando, infine, l'utente sceglie il sistema operativo da avviare, il Boot Manager (Bootmgr) legge la VMK crittografata dal volume e chiede al TPM di rimuovere il sealing. Il TPM eseguirà la decrittografia corretta della VMK solo se tutte le misurazioni sono rimaste identiche rispetto al momento del sealing della VMK, compreso il PIN facoltativo.

È possibile immaginare questo schema come una catena di verifica, dove ciascun componente della sequenza di avvio descrive al TPM il componente successivo. Il TPM divulgherà il segreto solo se tutte le descrizioni corrispondono a quelle originali. BitLocker quindi protegge i dati crittografati anche quando il disco viene rimosso e collocato in un altro sistema, il sistema viene avviato utilizzando un sistema operativo diverso oppure i file non decrittografati del volume di avvio sono danneggiati.

Verifica dell'integrità del codice

Il malware implementato come driver di dispositivo in modalità kernel, compresi i rootkit, viene eseguito allo stesso livello di privilegio del kernel ed è quindi il più difficile da individuare e rimuovere. Il malware di questo tipo può modificare il comportamento del kernel e degli altri driver in modo da diventare praticamente invisibile. L'integrità del codice di Windows Vista per la funzionalità del codice in modalità kernel, anche definita firma codice in modalità kernel (KMCS), consente il caricamento dei driver di dispositivo solo se questi sono pubblicati e firmati in modo digitale da sviluppatori vagliati da una delle poche autorità di certificazione (CA). KMCS viene applicato per impostazione predefinita a Windows Vista per i sistemi a 64 bit.

Poiché le autorità di certificazione richiedono il versamento di una tariffa per i servizi forniti ed eseguono verifiche di base in background, come l'identità dell'azienda, è molto difficile produrre malware anonimo in modalità kernel che possa essere eseguito in Windows Vista a 64 bit. È inoltre possibile che il malware che riesce a superare i processi di verifica lasci degli indizi che consentano di risalire all'autore, quando il malware viene scoperto su un sistema attaccato. Sono previsti anche usi secondari di KMCS, come l'invio delle informazioni sul contatto al team OCA di Windows quando si sospetta che un driver difettoso provochi l'arresto anomalo dei sistemi del cliente e lo sblocco del contenuto multimediale ad alta definizione.

KMCS utilizza le tecnologie di crittografia a chiave pubblica impiegate per oltre un decennio da Windows e richiede che nel codice in modalità kernel sia presente una firma digitale generata da una delle autorità di certificazione attendibili. Se un produttore di software presenta un driver al laboratorio per la qualità dell'hardware Windows (WHQL) di Microsoft e il driver supera i test di affidabilità, Microsoft diventa l'autorità di certificazione che firma il codice. La maggior parte dei produttori otterrà le firme da WHQL, ma quando un driver non partecipa al programma di test di WHQL, il produttore non intende sottoporre il driver ai test di WHQL o il driver è un driver di avvio che viene caricato nella fase iniziale dell'avvio di sistema, i produttori devono firmare direttamente il proprio codice. A tal fine, i produttori devono dapprima ottenere un certificato di firma del codice rilasciato da una delle autorità di certificazione che Microsoft riconosce come attendibile per firmare il proprio codice in modalità kernel. Il produttore quindi esegue l'hash digitale del codice, firma l'hash crittografandolo con una chiave privata e inserisce certificato e hash crittografato nel codice.

Quando viene tentato il caricamento di un driver, Windows decrittografa l'hash contenuto nel codice utilizzando la chiave pubblica memorizzata nel certificato, quindi verifica che l'hash corrisponda a quello contenuto nel codice. L'autenticità del certificato viene verificata allo stesso modo, ma con l'utilizzo della chiave pubblica dell'autorità di certificazione, che è contenuta in Windows.

Windows verifica anche i concatenamenti di certificati associati fino a una delle autorità principali incorporate nel caricatore di avvio di Windows e nel kernel del sistema operativo. È preferibile non tentare mai di caricare un driver a 64 bit non firmato su un sistema di produzione. A differenza della gestione dei componenti Plug and Play, che prevede la visualizzazione di una finestra di dialogo di avviso quando viene richiesto il caricamento di un driver non firmato con la conferma che è stato testato da WQHL, in Windows Vista a 64 bit viene scritto un evento nel registro eventi dell'applicazione di controllo dell'integrità del codice in modo invisibile all'utente, come quello visualizzato nella Figura 5, ogni volta che viene bloccato il caricamento di un driver non firmato. Anche in Windows Vista a 32 bit vengono controllate le firme dei driver, ma viene consentito il caricamento dei driver non firmati. Il blocco di tali driver comporterebbe problemi con i sistemi Windows XP aggiornati che richiedono i driver caricati in Windows XP e che consentono il supporto per l'hardware per cui esistono solo driver di Windows XP. Tuttavia, anche in Windows Vista a 32 bit vengono scritti degli eventi nel registro eventi dell'applicazione di controllo dell'integrità del codice quando viene caricato un driver non firmato.

Figura 5** Eventi di tentativo di caricamento di driver non firmati **(Fare clic sull'immagine per ingrandirla)

Poiché la firma del codice viene comunemente utilizzata per etichettare il codice come una versione ufficiale rigorosamente verificata, in genere i produttori evitano di firmare il codice di prova. In Windows Vista è quindi disponibile una modalità di firma delle versioni di prova che è possibile attivare e disattivare con lo strumento Bcdedit (descritto nel mio su TechNet Magazine del marzo 2007), che prevede il caricamento di driver in modalità kernel firmati digitalmente con un certificato di prova generato da un'autorità di certificazione interna. Questa modalità è stata progettata per l'uso da parte dei programmatori durante lo sviluppo del codice. Quando Windows viene utilizzato in questa modalità, sul desktop vengono visualizzati dei contrassegni, come nella Figura 6.

Figura 6** Modalità con firma di prova di Windows Vista **

Processi protetti

Il contenuto multimediale di prossima generazione, come HD-DVD, BluRay e altri formati registrati sotto AACS (Advanced Access Content System), si diffonderà sempre più negli anni a venire. In Windows Vista sono state integrate alcune tecnologie, definite collettivamente PMP (Protected Media Path), richieste dallo standard AACS per la riproduzione di questo tipo di contenuto. PMP comprende PUMA (Protected User-Mode Audio) e PVP (Protected Video Path) che insieme forniscono i meccanismi per i driver audio e video, oltre alle applicazioni di riproduzione di contenuto multimediale, per evitare l'acquisizione nel formato ad alta definizione con software o hardware non autorizzato.

PUMA e PVP definiscono interfacce e supporto specifici per i riproduttori di audio e video, i driver di dispositivo e l'hardware, ma PMP è inoltre basato su un meccanismo kernel generico introdotto in Windows Vista e definito "processo protetto". I processi protetti si basano sul costrutto del processo Windows standard che incapsula un'immagine eseguibile in esecuzione, le DLL corrispondenti, il contesto di protezione (l'account in cui viene eseguito il processo e i relativi privilegi di protezione) e i thread che eseguono il codice all'interno del processo, ma impedisce determinati tipi di accesso.

I processi standard implementano un modello di controllo dell'accesso che consente l'accesso completo al proprietario del processo e agli account amministrativi con il privilegio Debug di programmi. L'accesso completo consente a un utente di visualizzare e modificare lo spazio degli indirizzi del processo, compreso il codice e i dati associati nel processo. Gli utenti possono anche inserire dei thread nel processo. Questi tipi di accesso non sono compatibili con i requisiti di PMP, perché consentirebbero l'accesso al contenuto ad alta definizione e alle chiavi DRM (Digital Rights Management) memorizzate in un processo che riproduce il contenuto da parte di codice non autorizzato.

I processi protetti limitano l'accesso a una serie ridotta di interfacce informative e di gestione dei processi, che comprendono le query per il nome immagine del processo e l'interruzione o sospensione del processo. Il kernel rende, tuttavia, disponibili le informazioni diagnostiche sui processi protetti tramite le funzioni generiche di query dei processi, che restituiscono dati relativi a tutti i processi di un sistema e non richiedono l'accesso diretto al processo. Gli accessi che potrebbero danneggiare dei supporti sono consentiti soltanto ad altri processi protetti.

Inoltre, per evitare attacchi dall'interno, tutto il codice eseguibile caricato in un processo protetto, comprese l'immagine eseguibile e le DLL corrispondenti, deve essere firmato da Microsoft (WHQL) con un flag di ambiente protetto (PE) oppure, se è un codec audio, firmato dallo sviluppatore con un certificato DRM ottenuto da Microsoft. Poiché il codice in modalità kernel può ottenere accesso completo a qualunque processo, compresi i processi protetti, e Windows a 32 bit consente il caricamento di codice in modalità kernel non firmato, il kernel fornisce un'API per i processi protetti che richiede la "pulizia" dell'ambiente in modalità kernel e utilizza il risultato per sbloccare il contenuto solo se non viene caricato codice non firmato.

Individuazione di un processo protetto

Non esistono API che identifichino in modo specifico i processi protetti, ma è possibile individuarli in modo indiretto in base alla quantità ridotta di informazioni disponibili e all'impossibilità di eseguirne il debug anche da un account amministrativo. Il processo Isolamento grafico dispositivo audio (%Systemroot%\System32\Audiodg.exe) viene utilizzato per riprodurre i DVD codificati con il sistema CSS (Content Scramble System) ed è identificabile come processo protetto nel riquadro di Gestione attività per il fatto che in Gestione attività non è possibile ottenere la riga di comando, la virtualizzazione e lo stato di Protezione esecuzione programmi corrispondenti, anche quando il processo viene eseguito con diritti amministrativi.

Visualizzazione in Gestione attività del processo protetto audiodg(Fare clic sull'immagine per ingrandirla)

Sequenza casuale di caricamento nello spazio degli indirizzi

Malgrado le contromisure come Protezione esecuzione programmi e la verifica avanzata degli errori del compilatore, gli autori di malware continuano a trovare vulnerabilità di overflow del buffer che consentono di contagiare i processi aperti alla rete, come Internet Explorer®, i servizi Windows e le applicazioni di terze parti, per stabilire delle teste di ponte in un sistema. Una volta attaccato un processo, tuttavia, gli utenti malintenzionati devono utilizzare le API Windows per raggiungere lo scopo di leggere i dati dell'utente o stabilire una presenza permanente, modificando le impostazioni della configurazione di utente o sistema.

La connessione di un'applicazione con i punti di ingresso dell'API esportati da DLL viene di solito gestita dal caricatore del sistema operativo, ma questi tipi di attacchi da malware non ottengono i vantaggi dei servizi del caricatore. Questo non rappresentava un problema per il malware nelle versioni precedenti di Windows, perché in tutte le versioni di Windows, immagini eseguibili di sistema e DLL venivano sempre caricate nella stessa posizione, consentendo al malware di presupporre gli indirizzi fissi di residenza delle API.

La funzione di sequenza casuale di caricamento nello spazio degli indirizzi (ASLR) di Windows Vista rende impossibile per il malware indovinare gli indirizzi delle API, caricando DLL di sistema ed eseguibili in una posizione diversa a ogni avvio del sistema. Nelle prime fasi del processo di avvio, Memory Manager sceglie a caso una modalità di caricamento dell'immagine DLL dai 256 diversi indirizzi allineati a 64 KB nell'area di 16 MB nella parte superiore dello spazio degli indirizzi in modalità utente. Non appena delle DLL con il nuovo flag di rilocazione dinamica nell'intestazione dell'immagine vengono caricate in un processo, Memory Manager le inserisce in memoria a partire dall'indirizzo di caricamento immagine scelto in modo casuale.

Gli eseguibili con il flag vengono trattati in modo simile, con il caricamento in un punto allineato a 64 KB casuale all'interno dei 16 MB dell'indirizzo di caricamento di base memorizzato nell'intestazione dell'immagine corrispondente. Inoltre, se una DLL o un eseguibile viene caricato di nuovo dopo essere stato scaricato da tutti i processi che lo utilizzano, Memory Manager seleziona un'altra posizione casuale per il caricamento. Nella Figura 7 viene illustrato un esempio di disposizione dello spazio degli indirizzi per un sistema Windows Vista a 32 bit, che comprende le aree da cui ASLR sceglie la modalità di caricamento immagini e l'indirizzo di caricamento dell'eseguibile.

Figura 7** Effetto di ASLR sugli indirizzi di caricamento di eseguibile e DLL **(Fare clic sull'immagine per ingrandirla)

Vengono rilocate solo le immagini con un flag di rilocazione dinamica, tra cui tutti gli eseguibili e le DLL di Windows Vista, poiché lo spostamento di immagini legacy potrebbe influire sulla logica interna utilizzata dagli sviluppatori per il caricamento delle immagini corrispondenti. Visual Studio® 2005 SP1 supporta l'impostazione del flag, in modo che gli sviluppatori di terze parti possano sfruttare i vantaggi offerti da ASLR.

La sequenza casuale di scelta degli indirizzi di caricamento delle DLL tra le 256 posizioni disponibili non rende impossibile l'individuazione della posizione effettiva di un'API da parte del malware, ma riduce in modo significativo la velocità con cui si propaga un worm di rete ed evita il malware che può contare su una sola possibilità per attaccare il sistema. Inoltre, la strategia di rilocazione di ASLR ha l'ulteriore vantaggio rappresentato da spazi degli indirizzi più densi rispetto alle versioni precedenti di Windows, con la creazione di aree più ampie di memoria libera per allocazioni di memoria contigue, la riduzione del numero di tabelle pagine allocate da Memory Manager per tenere traccia della disposizione dello spazio degli indirizzi e la riduzione al minimo degli errori del TLB (Translation Lookaside Buffer).

Miglioramento della protezione dei servizi

I servizi windows sono i bersagli ideali del malware. Molti dei servizi offrono accesso in rete alle funzionalità dei malware, esponendo a volte in modalità remota un accesso al sistema, mentre la maggior parte dei servizi viene eseguito con un privilegio superiore al semplice account utente standard, offrendo la possibilità di elevare i privilegi su un sistema locale nei casi in cui si dimostrino attaccabili da un malware. Per questo motivo, è iniziata un'evoluzione di Windows a partire dalle modifiche apportate a Windows XP SP2, con cui si sono ridotti al minimo necessario per i rispettivi ruoli i privilegi e gli accessi assegnati ai servizi. In Windows XP SP2, ad esempio, sono stati introdotti gli account Servizio locale e Servizio di rete, che prevedono solo un sottoinsieme dei privilegi disponibili per l'account in cui venivano sempre eseguiti i servizi in precedenza, ovvero Sistema locale. In tal modo si riduce al minimo l'accesso che un utente malintenzionato riesce a ottenere sfruttando un servizio.

ASLR in azione

È possibile notare gli effetti di ASLR paragonando gli indirizzi di caricamento delle DLL per un processo in due diverse sessioni di avvio, utilizzando uno strumento come Process Explorer di Sysinternals. In queste due schermate, acquisite in due sessioni diverse, Ntdll.dll è stato caricato prima all'indirizzo 0x77A30000, quindi all'indirizzo 0x77750000.

Indirizzi di base diversi per ntdll.dll(Fare clic sull'immagine per ingrandirla)

Indirizzi di base diversi per ntdll.dll(Fare clic sull'immagine per ingrandirla)

Nell'articolo precedente si è descritto come i servizi vengano eseguiti isolati dagli account utente nella rispettiva sessione, ma in Windows Vista viene esteso l'utilizzo del principio dei privilegi minimi, in modo da ridurre ulteriormente i privilegi e l'accesso ai file, alle chiavi del Registro di sistema e alle porte del firewall a cui viene assegnata la maggior parte dei servizi. In Windows Vista viene definito un nuovo account di gruppo, denominato Identificatore di protezione (SID), univoco per ciascun servizio. Il servizio può impostare le autorizzazioni per le proprie risorse in modo da consentire l'accesso solo al proprio SID, impedendo ai servizi eseguiti sotto lo stesso account utente di accedere quando un servizio viene attaccato. È possibile visualizzare il SID di un servizio utilizzando il comando sc showsid seguito dal nome del servizio, come nella Figura 8.

Figura 8** Visualizzazione di un SID di servizio **(Fare clic sull'immagine per ingrandirla)

I SID di servizio proteggono l'accesso alle risorse di proprietà di un determinato servizio, ma per impostazione predefinita i servizi possono comunque accedere a tutti gli oggetti a cui è autorizzato ad accedere l'account utente sotto cui vengono eseguiti. Un servizio eseguito, ad esempio, sotto l'account Servizio locale potrebbe non essere in grado di accedere alle risorse create da un altro servizio, eseguito come Servizio locale in un altro processo, che ha protetto i propri oggetti con autorizzazioni che fanno riferimento a un SID di servizio. Tuttavia, lo stesso servizio può leggere e può scrivere in qualsiasi oggetto a cui Servizio locale è autorizzato ad accedere (eventuali gruppi di cui fa parte Servizio locale, come il gruppo Servizio).

Con Windows Vista viene quindi introdotto un nuovo tipo di servizio limitato, definito come servizio limitato in scrittura, che consente l'accesso in scrittura a un servizio solo per gli oggetti accessibili al SID di servizio corrispondente, al gruppo Everyone e al SID assegnato alla sessione di accesso. A tal fine, si utilizzano i SID limitati, un tipo di SID già implementato in Windows 2000. Quando il processo che apre un oggetto è un servizio limitato in scrittura, l'algoritmo di controllo dell'accesso viene modificato in modo che non sia possibile utilizzare un SID non assegnato a un processo, in entrambi i formati limitato e non limitato, per concedere al processo l'accesso in scrittura a un oggetto. È possibile individuare un servizio limitato con il comando seguente:

sc qsidtype [service]

Un'altra modifica consente a un servizio di impedire agli altri servizi in esecuzione sotto lo stesso account di accedere agli oggetti creati. Nelle versioni precedenti di Windows il creatore di un oggetto diventava anche il proprietario dell'oggetto e i proprietari potevano leggere e modificare le autorizzazioni dei propri oggetti, con un accesso completo ai propri oggetti. In Windows Vista è stato adottato il nuovo SID Diritti proprietario che, se presente nelle autorizzazioni di un oggetto, può limitare gli accessi garantiti a un proprietario per il proprio oggetto, eliminando addirittura i diritti di impostazione e query delle autorizzazioni.

Un ulteriore miglioramento al modello di protezione dei servizi in Windows Vista consente a uno sviluppatore di servizi di specificare con precisione i privilegi di protezione necessari al servizio per operare quando il servizio si registra in un sistema. Se, ad esempio, il servizio deve generare degli eventi di controllo, necessiterà del privilegio Controllo.

Quando avvia un processo che ospita uno o più servizi Windows, Gestione controllo servizi crea un token di protezione (l'oggetto kernel in cui sono riportati un account utente di processo, le appartenenze al gruppo e i privilegi di protezione) per il processo che comprende solo i privilegi richiesti dai servizi inclusi nel processo. Se un servizio specifica un privilegio che non è disponibile per l'account in cui viene eseguito, il servizio non verrà avviato. Quando nessuno dei servizi in esecuzione in un processo di un account Servizio locale necessita del privilegio Debug di programmi, ad esempio, Gestione controllo servizi elimina il privilegio dal token di protezione del processo. In tal modo, se il processo del servizio viene attaccato, il codice dannoso non potrà sfruttare privilegi che non siano stati esplicitamente richiesti dai servizi in esecuzione nel processo. Il comando sc qprivs consente di visualizzare i privilegi richiesti da un servizio.

Conclusioni

Con questo articolo si conclude l'analisi in tre parti delle modifiche apportate al kernel di Windows Vista. Esistono altri miglioramenti e funzionalità che non sono stati descritti o menzionati, come un nuovo un pool dei thread di lavoro per gli sviluppatori di applicazioni, nuovi meccanismi di sincronizzazione come i blocchi in lettura/scrittura condivisi, la codifica dei thread dei servizi, il supporto per il controllo del disco e il ridimensionamento del volume NTFS in linea e un nuovo meccanismo IPC del kernel denominato di ALPC (Advanced Local Procedure Call). Ulteriori informazioni su queste e altre funzionalità saranno riportate nella prossima edizione di Windows Internals prevista per la fine del 2007.

Visualizzazione del servizio limitato in scrittura

Un solo processo che ospita servizi di Windows Vista contiene servizi limitati ed è possibile identificarlo come il processo con la riga di comando con uno strumento di visualizzazione dei processi come Process Explorer:

svchost -k LocalServiceNoNetwork

I servizi configurati per l'esecuzione in questo processo sono Base Filtering Engine, Servizio Criteri di diagnostica, Windows Firewall, Avvisi e registri di prestazioni e l'avviatore del servizio Windows Media® Center.

In questa schermata viene illustrato il formato testuale del SID di servizio di Base Filtering Engine, NT SERVICE\BFE, riportato una volta con il flag Con restrizioni e una volta senza, dunque il processo può accedere alle risorse accessibili per l'account. Non è tuttavia detto che possa accedere ad altri oggetti in genere accessibili per l'account Servizio locale. Poiché, ad esempio, l'account NT AUTHORITY\SERVICE non è riportato nel token di processo con il flag Con restrizioni, il processo non può modificare gli oggetti che concedono l'accesso in scrittura solo a tale account ma non agli altri account del token con il flag Con restrizioni.

Anche i servizi che vengono eseguiti in questo processo dispongono di privilegi limitati, perché i privilegi elencati nella parte inferiore della finestra di dialogo delle proprietà sono un sottoinsieme dei privilegi disponibili per l'account Servizio locale.

Flag SID su un servizio(Fare clic sull'immagine per ingrandirla)

Mark Russinovich è un Technical Fellow di Microsoft nella Platform and Services Division. È coautore di Microsoft Windows Internals (Microsoft Press, 2004) e spesso partecipa come oratore a conferenze su IT e sviluppo, tra cui Microsoft Tech•Ed e PDC. Si è unito a Microsoft dopo l'acquisizione dell'azienda che ha cofondato, Winternals Software. Ha inoltre creato Sysinternals, dove ha pubblicato molte diffuse utilità, tra cui Process Explorer, Filemon e Regmon.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.