Google vs Microsoft; Il team di ricerca di Google rende pubbliche due ulteriori vulnerabilità di Windows 7/8

La guerra tra Google e Microsoft si intensifica mentre Google rivela due ulteriori vulnerabilità di Windows 7 e Windows 8.

Il team di ricerca di Google ha reso pubbliche due ulteriori vulnerabilità di Windows non corrette giovedì dopo la scadenza del periodo di attesa di 90 giorni autoimposto da Google Project Zero prima di divulgare i dettagli del bug.

Microsoft, che non ha preso bene questo tipo di divulgazioni pubbliche, ha dichiarato che correggerà una delle due vulnerabilità nel suo prossimo rilascio del bollettino di sicurezza di Patch Tuesday di febbraio. La seconda vulnerabilità sembra non essere un grande problema di sicurezza.

I lettori potrebbero ricordare che il team di ricerca di Google aveva reso pubblica una vulnerabilità di escalation dei privilegi in Windows 7 dopo la scadenza del periodo di attesa autoimposto di 90 giorni. La divulgazione di Google del 29 dicembre ha riacceso i dibattiti sulla divulgazione tra gli appassionati di sicurezza e ha acceso acrimonia e posizioni pubbliche da entrambe le aziende.

Microsoft desidera che Google segua un programma di divulgazione coordinata delle vulnerabilità e ha chiesto a Google di trattenere la divulgazione della vulnerabilità fino ai bollettini di sicurezza di gennaio, che sono stati rilasciati questa settimana. Google, d’altra parte, si basa sul suo periodo di moratoria autoimposto di 90 giorni, quindi ha rifiutato e ha proceduto con la sua divulgazione.

Chris Betz di Microsoft ha dichiarato che: “Sebbene seguire il programma rispetti la tempistica annunciata da Google per la divulgazione, la decisione sembra meno una questione di principi e più un ‘gotcha’, con i clienti che potrebbero soffrire come risultato. Ciò che è giusto per Google non è sempre giusto per i clienti. Esortiamo Google a fare della protezione dei clienti il nostro obiettivo primario collettivo.”

La guerra tra i giganti della tecnologia è tutt’altro che finita, poiché il team di ricerca di Google ha reso pubbliche altre due vulnerabilità di Windows. Entrambe le vulnerabilità sono riportate di seguito:

Problema n. 127 segnalato a Microsoft il 17 ottobre 2013 reso pubblico il 15 gennaio 2014

Piattaforma: Windows 7 32/64 bit, Windows 8+ non vulnerabile
Classe: Bypass di Sicurezza La chiamata di sistema NtPowerInformation esegue un controllo che il chiamante sia un amministratore prima di eseguire alcune funzioni di potenza specifiche. Il controllo viene eseguito nella funzione PopUserIsAdmin. L’implementazione approssimativa è: BOOLEAN PopUserIsAdmin() {
SECURITY_SUBJECT_CONTEXT ctx; SeCaptureSecurityContext(&ctx); return SeTokenIsAdmin(SeQuerySubjectContextToken(&ctx));
} Su Windows 7 questo controllo è eludibile perché la funzione SeTokenIsAdmin non tiene conto del livello di impersonificazione del token e il resto del codice non lo tiene in considerazione. Pertanto, puoi impersonare un token di amministratore come utente normale (attraverso un token collegato o il rapimento di un token di sistema) e chiamare le funzioni protette. Su Windows 8+ il metodo SeTokenIsAdmin è stato modificato per controllare il livello di impersonificazione, quindi non è vulnerabile. Non è chiaro se questo abbia un serio impatto sulla sicurezza o meno, quindi viene divulgato così com’è. Alcune funzioni sono anche controllate da un controllo di privilegi, tuttavia il contesto del soggetto viene catturato separatamente, quindi esiste una finestra TOCTOU tra i controlli che potrebbe essere sfruttata. Per scopi di PoC ho scelto di utilizzare la funzione 45 “PopRequestPowerListInfo” (che non richiede trucchi speciali. Inoltre, questa funzione ha una vulnerabilità teorica di overflow intero a seconda di quanto puoi spingere la dimensione di PopPowerRequestObjectCount. Allegato è un semplice PoC che dimostra il problema per l’esecuzione su Windows 7. Per riprodurre seguire i passaggi. 1) Assicurati di eseguire come amministratore con token separato, questo perché il PoC utilizza il token collegato per ottenere un token di amministratore. Per un utente normale potresti semplicemente catturare un token da un servizio.

2. Esegui il PoC, dovrebbe effettuare chiamate, una senza impersonificazione e una con. Risultato atteso:
   Entrambe le chiamate dovrebbero restituire STATUS_ACCESS_DENIED (0xC0000022) Risultato osservato:
   Il primo controllo fallisce con STATUS_ACCESS_DENIED mentre il secondo ha successo con STATUS_SUCCESS. PoC per il download => 1 2

Problema n.128 segnalato a Microsoft il 17 ottobre 2013 reso pubblico il 15 gennaio 2014

Piattaforma: Windows 7, 8.1 Aggiornamento 32/64 bit
Classe: Bypass di Sicurezza/Divulgazione di Informazioni La funzione CryptProtectMemory consente a un’applicazione di crittografare la memoria per uno dei tre scenari, processo, sessione di accesso e computer. Quando si utilizza l’opzione della sessione di accesso (flag CRYPTPROTECTMEMORY_SAME_LOGON), la chiave di crittografia viene generata in base all’identificatore della sessione di accesso, questo è per condividere la memoria tra i processi in esecuzione all’interno della stessa sessione di accesso. Poiché questo potrebbe anche essere utilizzato per inviare dati da un processo a un altro, supporta l’estrazione dell’id della sessione di accesso dal token di impersonificazione. Il problema è che l’implementazione in CNG.sys non controlla il livello di impersonificazione del token quando cattura l’id della sessione di accesso (utilizzando SeQueryAuthenticationIdToken), quindi un utente normale può impersonare a livello di identificazione e decrittografare o crittografare dati per quella sessione di accesso. Questo potrebbe essere un problema se c’è un servizio vulnerabile a un attacco di piantagione di pipe denominate o che memorizza dati crittografati in una sezione di memoria condivisa leggibile da tutti. Questo comportamento potrebbe ovviamente essere progettato, tuttavia non essendo stato parte del design è difficile dirlo. La documentazione afferma che l’utente deve impersonare il client, che interpreto come significare che dovrebbe essere in grado di agire per conto del client piuttosto che identificarsi come il client. Allegato è un semplice PoC che dimostra il problema. Per riprodurre seguire i passaggi. 1) Esegui Poc_CNGLogonSessionImpersonation.exe dalla riga di comando

2. Il programma dovrebbe stampare “La crittografia non corrisponde” per indicare che le due crittografie dello stesso dato non erano corrispondenti, implicando che la chiave era diversa tra di esse. Risultato atteso:
   Entrambe le chiamate dovrebbero restituire gli stessi dati crittografati, oppure la seconda chiamata dovrebbe fallire Risultato osservato:
   Entrambe le chiamate hanno successo e restituiscono dati crittografati diversi PoC download => Zip File

Microsoft correggerà solo una delle vulnerabilità nel suo Patch Tuesday di febbraio, dicendo che l’altra vulnerabilità non rappresenta un rischio per la sicurezza. Sia Microsoft che Google hanno dichiarato di non avere prove che nessuna delle tre vulnerabilità rese pubbliche sia stata sfruttata in natura.