Windows 10 S: Google rende pubblica una falla di sicurezza

Il team di Google ProjectZero costituito da ingegneri software esperti nel campo della sicurezza informatica, da un lato è molto utile per segnalare eventuali falle nei sistemi ma dall’altro è a volte eccessivamente severo causando più problemi che soluzioni.

Sebbene Windows 10 S sia a tutti gli effetti la versione di Windows più sicura nella storia grazie alle sue particolari “limitazioni” come non poter installare software dal web che potrebbero rivelarsi malevoli ma soltanto dallo store ufficiale dove vengono effettuati numerosi controlli, non è comunque proprio un sistema operativo sicuro al 100% e non mancano alcune vulnerabilità.

I dipendenti di Google Project Zero hanno scovato una falla che consente l’esecuzione di codice arbitrario su un sistema con UMCI abilitato, come Device Guard, attivo per impostazione predefinita su Windows 10 S mettendo a rischio la privacy degli utenti. Tuttavia viene comunque classificata come vulnerabilità media in quanto non può essere applicata in remoto; un eventuale malintenzionato dovrebbe già avere infatti il codice in esecuzione sul dispositivo per modificare le voci del Registro di sistema, il che riduce notevolmente la gravità del problema.

La scoperta della falla risale al 19 gennaio e Google ha dato, come di consuetudine, 90 giorni di tempo a Microsoft per risolvere affermando che se la scadenza non fosse stata rispettata tutti i dettagli dell’exploit sarebbero stati resi pubblici immediatamente. Il Colosso di Redmond, però, non ha fatto in tempo per apportare le dovute modifiche e ha chiesto pertanto un ulteriore estensione di 14 giorni in modo tale da rilasciare la patch con Redstone 4. Purtroppo Google non ha accettato la proposta ed ecco che di conseguenza ha pubblicato tutte le informazioni tecniche in merito:

The WLDP COM Class lockdown policy contains a hardcoded list of 8 to 50 COM objects which enlightened scripting engines can instantiate. Excluding issues related to the looking up of the correct CLSID (such as previously reported abuse of TreatAs case 40189). This shouldn’t be a major issue even if you can write to the registry to register an existing DLL under one of the allowed COM CLSIDs as a well behaved COM implementation should compare the CLSID passed to DllGetObject against its internal list of known objects.

Turns out .NET is not one of these well behaved COM implementations. When a .NET COM object is instantiated the CLSID passed to mscoree’s DllGetClassObject is only used to look up the registration information in HKCR. At this point, at least based on testing, the CLSID is thrown away and the .NET object created. This has a direct impact on the class policy as it allows an attacker to add registry keys (including to HKCU) that would load an arbitrary COM visible class under one of the allowed CLSIDs. As .NET then doesn’t care about whether the .NET Type has that specific GUID you can use this to bootstrap arbitrary code execution by abusing something like DotNetToJScript.

Per restare sempre aggiornato sulle ultime novità scarica la nostra APP ufficiale oppure iscriviti alle nostre notifiche istantanee oppure seguici su Facebook, Twitter, Telegram e Instagram!

Fonte