På trods af Microsofts indvendinger frigiver Google et jailbreak til Windows 10 S

Ikon for læsetid 3 min. Læs


Læsere hjælper med at understøtte MSpoweruser. Vi får muligvis en kommission, hvis du køber via vores links. Værktøjstip-ikon

Læs vores oplysningsside for at finde ud af, hvordan du kan hjælpe MSPoweruser med at opretholde redaktionen Læs mere

Googles Project Zero-team har gjort det igen og har frigivet en "Medium Severity"-udnyttelse til Windows 10 S, hvilket betyder, at brugere vil være i stand til at køre vilkårlig kode på Microsofts låste operativsystem, Windows 10 S.

Fejlen skyldes, hvordan Windows 10 S verificerer identiteten af ​​en liste over højprivilegerede komponenter, hvilket vil sige meget dårligt.

I detaljer beskriver Google det sådan:

WLDP COM Class lockdown-politikken indeholder en hårdkodet liste med 8 til 50 COM-objekter, som oplyste script-motorer kan instansiere. Ekskluderer problemer relateret til søgningen af ​​det korrekte CLSID (såsom tidligere rapporteret misbrug af TreatAs-sag 40189). Dette burde ikke være et stort problem, selvom du kan skrive til registreringsdatabasen for at registrere en eksisterende DLL under en af ​​de tilladte COM CLSID'er, da en velopdragen COM-implementering bør sammenligne CLSID'et, der er sendt til DllGetObject, med dets interne liste over kendte objekter.

Det viser sig, at .NET ikke er en af ​​disse velopdragne COM-implementeringer. Når et .NET COM-objekt instantieres, bruges CLSID'et, der sendes til mscorees DllGetClassObject, kun til at slå registreringsoplysningerne op i HKCR. På dette tidspunkt, i det mindste baseret på test, bliver CLSID'et smidt væk og .NET-objektet oprettet. Dette har en direkte indvirkning på klassepolitikken, da det tillader en angriber at tilføje registreringsdatabasenøgler (inklusive til HKCU), der ville indlæse en vilkårlig COM-synlig klasse under et af de tilladte CLSID'er. Da .NET så er ligeglad med, om .NET Type har den specifikke GUID, kan du bruge denne til at bootstrap vilkårlig kodeudførelse ved at misbruge noget som DotNetToJScript.

Windows 10 S er det primære OS, der er berørt, og i mangel af en fjernkode, ville udnyttelsen betyde, at hackere skulle have fysisk adgang til pc'en for at køre den indledende kode. Da Windows 10 S ofte bruges i situationer, hvor brugeren ikke er tillid til (såsom skoler), kan dette dog betyde, at smarte brugere vil være i stand til at hacke operativsystemet og køre vilkårlig kode, hvilket kan være et skridt til at låse op operativ system.

Microsoft blev underrettet om fejlen den 19. januar, men planlagde at frigive rettelsen som en del af Redstone 4. Dette var dog langt ud over Googles 90-dages offentliggørelsesvindue og på trods af Microsofts gentagne anmodning om en forlængelse Google har nu udgivet detaljerede oplysninger om udnyttelsen.

I betragtning af, at Windows 10 S ikke er udbredt i øjeblikket, formoder jeg, at der ikke vil komme meget fra denne lille spat, men det er interessant, at Microsoft undlod at forudse dette problem, hvilket tyder på, at Microsoft skal arbejde hårdere på at revidere deres software og metoder til sikkerhedsimplementeringsproblemer .

Via Neowin

Mere om emnerne: Google, google projekt nul, microsoft, sikkerhed, Windows 10 S

Giv en kommentar

Din e-mail adresse vil ikke blive offentliggjort. Krævede felter er markeret *