UAC In het kort: Voordelen van standaard gebruikersaccounts User Account Control sinds Windows Vista UAC-modi en gebruik van auto-elevation
Windows 7 User Account Control van binnenuit Mark Russinovich
Voordat Vista kwam, is er een lange periode geweest waarin Windowsgebruikers standaard onder beheerdersrechten werkten. Met de komst van UAC in Windows Vista kwam daar verandering in, maar dit systeem wekte ook de nodige irritatie op. In Windows 7 is het nodige gewijzigd aan UAC, om de gebruikerservaring te verbeteren. Standaard gebruikersaccounts leiden tot een betere beveiliging en lagere TCO in zowel thuis- als bedrijfsomgevingen. Als gebruikers werken met standaard gebruikersrechten in plaats van beheerdersrechten, ontstaat al een veel beter beschermde beveiligingsconfiguratie voor het hele systeem. Gebruikers kunnen zo in een veilig gebied werken waarin hun account en de rest van het systeem worden beschermd. In bedrijfsomge vingen is het beleid dat de beheerder heeft ingesteld, beschermd tegen overschrijven, terwijl in thuissituaties de verschillende gebruikersaccounts op een pc van elkaar worden afgeschermd.
Rechten in Windows Zoals bekend heeft Windows een lange geschiedenis van gebruikers die met beheerdersrechten werken. Als gevolg daarvan is er veel software ontwikkeld die met een beheerdersaccount wordt uitgevoerd en, vaak onbedoeld, afhankelijk is van beheerdersrechten. Met de introductie van UAC (User Account Control) in Windows Vista werden twee vliegen in één klap geslagen: er kon meer software met standaard28
juli 2009
gebruikersrechten worden uitgevoerd en onwikkelaars kregen de mogelijkheid om hun toepassingen geschikt te maken voor het uitvoeren met standaard gebruikersrechten. UAC is een verzameling technologieën bestaande uit een virtualisatie van het bestandssysteem en het register, PAaccount (Protected Administrator), UACprompts voor benodigde bevoegdheden en Windows-integriteitsniveaus. In Windows 7 wordt de ingeslagen weg met UAC vervolgd en zijn de technologieën min of meer in hun bestaande vorm gehandhaafd. Maar men heeft ook niet stilgezeten, want Windows 7 beschikt over twee nieuwe modi voor de PA-account van UAC, en een nieuw mechanisme voor het automatisch verhogen van bevoegdheden voor bepaalde ingebouwde Windows-onderdelen. In dit artikel ga ik dieper in op de beweegredenen achter de UAC-technologie, de r elatie tussen UAC en beveiliging, de twee nieuwe modi en de exacte werking van de automatische verhoging van bevoegdheden. Dit artikel heeft betrekking op gedrag in de release candidate van Windows 7, die in diverse opzichten afwijkt van de bètaversie. TechNet Magazine
UAC-technologieën
Ontwikkelaars
Het primaire doel van de UAC-technologie is simpel: we willen standaardgebruikers gemakkelijker laten werken in Windows. Dit wordt geïllustreerd door het verschil tussen Windows XP en Windows Vista als het gaat om de benodigde rechten voor het instellen van de tijdzone. In Windows XP is wijziging van de tijdzone niet mogelijk zonder beheerdersrechten, ook niet als de tijdzone wordt weergegeven met het onderdeel voor datum en tijd van het configuratiescherm. Dit komt doordat in Windows XP geen onderscheid wordt gemaakt tussen het wijzigen van de tijd, hetgeen een beveiligingsgevoelige systeemtaak is, en het wijzigen van de tijdzone, hetgeen alleen maar gevolgen heeft voor de wijze waarop de tijd wordt weergegeven. In Windows Vista (en Windows 7) is wijziging van de tijd zone geen beheerderstaak meer en worden in het datum- en tijdonderdeel beheerders taken gescheiden van standaardgebruikers taken. Deze wijziging alleen al biedt veel ondernemingen de mogelijkheid een standaardgebruikersaccount in te stellen voor hun reizende werknemers, die zo de tijd zone kunnen aanpassen aan hun huidige locatie. Windows 7 gaat een stapje verder en biedt standaardgebruikers ook de mogelijkheid om het IP-adres van het systeem te vernieuwen, Windows Update te gebruiken om eventuele updates en drivers te installeren, de schermresolutie te wijzigen en de huidige firewallinstellingen te bekijken. De virtualisatie van bestandssysteem en register is achter de schermen werkzaam om te zorgen dat allerlei toepassingen die onbedoeld met beheerdersrechten werken, ook zonder deze rechten kunnen worden uitgevoerd. Onnodig gebruik van beheerdersrechten treedt meestal op bij de opslag van toepassingsinstellingen of gebruikersdata in register- of filesystemgebieden die zijn gereserveerd voor het systeem. Zo worden de instellingen bij sommige oudere toepassingen opgeslagen in het systeemoverkoepelende deel van het register (HKEY_LOCAL_ MACHINE\Software) in plaats van in het gebruikersspecifieke deel (HKEY_ CURRENT_USER\Software). In zo’n geval kan de registervirtualisatie de gepoogde schrijfbewerking naar de systeemlocatie zonder gevolgen voor de toepassingscompatibiliteit ombuigen naar een locatie in HKEY_CURRENT_USER (HKCU).
Met de introductie van de PA-account hoopte men ontwikkelaars over te halen om toepassingen te schrijven die alleen nog standaardgebruikersrechten nodig hadden en dat toepassingen die onderdelen voor beheer en standaardgebruik d elen, zoveel mogelijk normaal konden blijven werken. In Windows Vista en Windows 7 wordt nu standaard een PA-account als eerste a ccount gebruikt, terwijl dit onder eerdere versies van Windows altijd een a ccount met volledige beheerdersrechten was. De programma’s die worden uitgevoerd door PAgebruikers, worden standaard uitgevoerd met standaardgebruikersrechten, tenzij de gebruiker de benodigde bevoegdheden voor de toepassing expliciet verhoogt naar het n iveau van beheerrechten. De prompts voor de verhoging van bevoegdheden worden geactiveerd door acties van gebruikers, zoals de installatie van toepassingen of wijziging van systeeminstellingen. Dergelijke prompts vormen het meest zichtbare deel van de UAC-technologie, met name doordat er dan een dialoogvenster voor het toestaan/ annuleren van de actie verschijnt en de desktop donkerder wordt en de desktopkleuren vervagen. Na de installatie worden voortaan a lleen nog standaardgebruikersaccounts g emaakt, waarbij op de achtergrond als het ware wordt ‘meegekeken’ en indien nodig naar inloggegevens van een beheerdersaccount wordt gevraagd om de benodigde bevoegdheden voor het beheer te kunnen verlenen. Door deze mogelijkheid hebben gezinsleden die één pc delen en andere veiligheidsbewuste gebruikers alleen een
TechNet Magazine
Het primaire doel van UAC: standaardgebruikers makkelijker laten werken in Windows standaardgebruikersaccount nodig voor het uitvoeren van toepassingen met beheerdersrechten (mits ze het wachtwoord van de beheerdersaccount kennen), en hoeven ze hiervoor niet meer handmatig over te schakelen naar een nieuwe gebruikerssessie. De installatie en configuratie van ouderlijk toezicht is hier een voorbeeld waarbij dit voor thuisgebruik wordt toegepast. Wanneer UAC is ingeschakeld, worjuli 2009
29
Beveiliging
Figuur 1 Weergave van de naam van het uitvoerbare bestand
den alle gebruikersaccounts, inclusief beheerdersaccounts, uitgevoerd met standaardgebruikersrechten. Ontwikkelaars van toepassingen moeten daarom voor ogen houden dat hun software standaard zonder beheerdersrechten kan worden uitgevoerd. Zo kunnen er steeds meer toepassingen komen die probleemloos onder standaardgebruikersrechten werken. Als een toepassing of onderdeel ervan beheerdersrechten nodig heeft, kan het mechanisme voor de verhoging van bevoegdheden worden i ngeschakeld om de gewenste functionaliteit toegankelijk te maken voor de gebruiker. Over het algemeen volstaat een kleine aanpassing van een toepassing om deze met standaardgebruikersrechten te laten werken. Op de W7-blog over UAC kunt u lezen dat developers bij het schrijven van toepassingen langzamerhand de voordelen van UAC inzien. Een aanvullend voordeel van de bevoegdhedenprompts is dat de gebruiker zo gewaarschuwd wordt voor software die een systeemwijziging wil doorvoeren. De gebruiker krijgt daarmee de gelegenheid de wijziging te voorkomen. Wanneer de gebruiker de wijziging niet wil doorvoeren of bijvoorbeeld vermoedt dat er sprake is van een onbetrouwbaar softwarepakket, kan hij de toewijzing van beheerdersrechten weigeren.
Verhoging van bevoegdheden Hoewel UAC primair bedoeld is om meer gebruikers in staat te stellen met standaardgebruikersrechten te werken, is er een UAC-technologie die veel weg lijkt hebben van een beveiligingsfunctie. Inderdaad, de prompts voor het verlenen van toestemming. Er wordt vaak verondersteld dat het feit dat gebruikers toestemming moeten 30
juli 2009
g even om software met beheerdersrechten uit te voeren tevens voorkomt dat malware beheerdersrechten kan krijgen. Deze gedachte wordt versterkt door het feit dat het verzoek om meer bevoegdheden resulteert in een zichtbare omschakeling van het scherm en de inzet van het mechanisme voor Windows-integriteit, inclusief UIPI (User Interface Privilege Isolation), terwijl het in feite alleen maar gaat om de toewijzing van beheerdersrechten voor de beschreven actie. Reeds voor de introductie van Windows Vista stelden we dat het verzoek om meer bevoegdheden vooral is gericht op gemak en niet zozeer op beveiliging. De functie was gestoeld op het feit dat gebruikers die een andere account nodig hadden om een beheertaak uit te voeren, doorgaans met de beheerdersaccount bleven doorwerken nadat ze met een nieuwe aanmelding of met Fast User Switching waren omgeschakeld. Een wijziging van de omgeving waarvoor ontwikkelaars hun toepassingen maken, leek daarmee weinig zin te hebben. Maar waarom dan toch een beveiligde desktop en een Windows-integriteitsmechanisme? De overschakeling naar een andere desktop tijdens de weergave van de prompt is met name geïntroduceerd om te voorkomen dat de software voor standaardgebruikers een valse prompt kan presenteren, waarmee kwaadwillenden de indruk willen wekken dat de software afkomstig is van bijvoorbeeld Microsoft of een andere betrouwbare leverancier. De alternatieve desktop wordt een ‘beveiligde desktop’ genoemd, omdat het om een weergave gaat die in eigendom is van het systeem en niet van de gebruiker, net als de desktop waarop het aanmeldingsvenster van Windows wordt weergegeven. Het gebruik van een andere desktop is ook van belang voor de toepassingscompatibiliteit. In tegenstelling tot de ingebouwde toegankelijkheidssoftware, zoals het On Screen Keyboard, is er software van derden die niet altijd goed werkt op een desktop waarop toepassingen van verschillende gebruikers worden uitgevoerd. Dergelijke software levert problemen op wanneer de bevoegdhedenprompt, die eigendom is van de lokale systeemaccount, wordt weergegeven op de desktop die eigendom is van een gebruiker. Het Windows Integrity Mechanism en de UIPI zijn ontwikkeld om een beschermingsring te leggen om toepassingen die om meer bevoegdheden kunnen vragen. Eén TechNet Magazine
van de oorspronkelijke doelstellingen was om te voorkomen dat softwaredevelopers zich er te gemakkelijk vanaf zouden maken en toepassingen die geen prompts krijgen, zouden misbruiken om de beheertaken te verrichten. Een toepassing met standaardgebruikersrechten kan geen synthetische muis- of toetsenbordinvoer verzenden naar een toepassing met verhoogde bevoegd heden om schermprompts te beantwoorden, dan wel code te injecteren ten behoeve van beheertaken. Het Windows Integrity Mechanism en UIPI werden in Windows Vista gebruikt voor de implementatie van Protected Mode van Internet Explorer. Hiermee werd het voor malware die IE infecteerde, moeilijker om de instellingen van een gebruikersaccount te wijzigen en de aanmelding van de gebruiker bijvoorbeeld te misbruiken om zichzelf te starten. Het gebruik van verhoogde bevoegdheden in combinatie met de beveiligde desktop, het Windows Integrity Mechanism en UIPI om een ondoordringbare beveiligingsdam te creëren tussen software met standaardgebruikersrechten en die met beheerdersrechten, was aanvankelijk een doelstelling bij het ontwerp van Windows Vista. Maar deze doelstelling werd geschrapt omdat deze niet haalbaar bleek omwille van bruikbaarheid en toepassingscompatibiliteit. Dit wordt duidelijk als we naar het dialoogvenster voor verhoogde bevoegdheden kijken. Hierin wordt de naam weergegeven van de uitgever van het uitvoerbare bestand waaraan beheerdersrechten worden verleend. Hoewel er steeds meer uitgevers van software zijn die hun code digitaal ondertekenen, is helaas nog niet iedereen van dit belang doordrongen en moeten ook veel oude toepassingen het zonder ondertekening stellen. Wanneer software niet is ondertekend, toont het dialoogvenster voor verhoogde bevoegdheden alleen de naam van het uitvoerbare bestand. Mocht een gebruikersaccount besmet zijn met malware, dan kan de malware een verhoging van de bevoegdheden van een niet-ondertekende Setup.exe misbruiken om dit bestand, zonder dat de gebruiker het in de gaten heeft, te vervangen door een schadelijke Setup.exe (zie Figuur 1). Bovendien kan de gebruiker uit dit dialoogvenster niet afleiden welke DLL’s uiteindelijk door het uitvoerbare bestand worden geladen. Als het uitvoerbare bestand zich TechNet Magazine
in een map bevindt die eigendom is van de gebruiker, kunnen de DLL’s voor de software op die locatie worden vervangen door malware die met de standaardrechten van de gebruiker wordt uitgevoerd. Ook zou de malware via side-by-side kunnen zorgen dat het uitvoerbare bestand schadelijke versies van toepassings- of systeem-DLL’s laadt. En tenzij een oplettende gebruiker op de detailknop klikt en het bestandspad van het uitvoerbare bestand controleert, is er eveneens het risico dat de malware het uitvoerbare bestand kopieert naar een locatie met een vrijwel identieke naam zoals \ProgramFiles\ Vendor\Application.exe (let op de ontbrekende spatie vergeleken met het origineel ‘Program Files’) en zo bepaalt welke DLL’s voor de toepassing worden geladen. In Figuur 2 is te zien dat ik een onderdeel van Microsoft Network Monitor naar de door een gebruiker gemaakte en beheerde map C:\ProgramFiles heb gekopieerd en gestart. Op het vlak van de toepassingscompatibiliteit hebben we te maken met het probleem dat toepassingen in de beheermodus een aanzienlijke overlap hebben met de standaardgebruikersomgeving. Dit kan door schadelijke software worden misbruikt om het gedrag van een toepassing te beïnvloeden. Het duidelijkste voorbeeld hiervan vormt het registerprofiel voor gebruikers HKEY_CURRENT_USER (HKCU). Dit is een gedeeld profiel omdat gebruikers ervan uitgaan dat de instellingen en uitbreidingen die ze als standaardgebruiker registreren ook beschikbaar zijn in een beheermodus. Via Shell-uitbreidingen die in HKCU zijn geregistreerd, kan malware worden geladen in toepassingen met verhoogde bevoegdheden die gebruikmaken van dialoogvensters met
Figuur 2 Gestarte versie van de Microsoft Network Monitor
juli 2009
31
Beveiliging
Figuur 3 In het nieuwe UACconfiguratievenster kunnen twee nieuwe UAC-modi worden ingesteld
32
juli 2009
een browser, zoals File Open en File Save. Ook op andere terreinen is er sprake van gedeeld gebruik. Dit geldt met name voor de namespace Base Named Object, waar de objecten voor synchronisatie worden aangemaakt en voorzien in gedeeld geheugen voor applicaties. Op dit raakvlak zou de malware de kans krijgen om bijvoorbeeld een object voor gedeeld geheugen te kapen met alle schadelijke gevolgen vandien voor de toepassing en het hele systeem. Het Windows Integrity Mechanism kan hierbij slechts een beperkte barrière opwerpen. Dit komt in de eerste plaats door de genoemde problemen voor verhoogde bevoegdheden, maar ook door restricties als gevolg van de toepassingscompatibiliteit. Om te beginnen legt UIPI toepassingen voor standaardgebruikers geen strobreed in de weg bij de weergave op de desktop. Dit biedt malware een uitgelezen kans om gebruikers te misleiden en beheerdersrechten te verwerven als een toepassing die om meer bevoegdheden vraagt. Het Windows Integrity Mechanism kent geen netwerk ondersteuning. Dit betekent dat een toepassing voor standaardgebruikers onder een
PA-account tevens toegang zal hebben tot resources op een extern systeem waarop die PA-account beheerdersrechten heeft. Een aanpak van dit soort problemen heeft negatieve gevolgen voor de toepassingscompatibiliteit. Dat wil niet zeggen dat we er niets aan doen. We proberen de systeembeveiliging constant te verbeteren, bijvoorbeeld door de Protected Mode IE te verbeteren, en proberen daarnaast problemen met de toepassingscompatibiliteit aan te pakken onder meer door een nauwe samenwerking met softwaredevelopers. Welke bescherming biedt een Windows Vista PA-account met UAC nu feitelijk tegen malware? Op de eerste plaats moet de malware de kans krijgen om het systeem binnen te dringen. Windows beschikt over een groot aantal grondige beveiligingsfuncties, zoals Data Execution Prevention (DEP), Address Space Load Randomization (ASLR), Protected Mode IE, het SmartScreen-filter van IE 8 en Windows Defender die voorkomen dat malware op het systeem kan worden geïnstalleerd. Mocht desondanks malware toch het sys teem weten binnen te dringen doordat malware-auteurs (maar ook legitieme ontwikkelaars) ervan uit gaan dat gebruikers in de beheerdersmodus werken, dan zal deze in de meeste gevallen weinig kans van slagen hebben. Dit alleen al is een beveiligingsvoordeel. Maar uiteraard kan een systeem ook geïnfecteerd raken met malware die loert op een kans om beheerdersrechten te verwerven zodra een gebruiker een verzoek krijgt en de benodigde toestemming verleent, of malware die niet op een echt verzoek hoeft te wachten maar dit zelf kan nabootsen en zo zelfs de meest veiligheidsbewuste gebruikers kan misleiden. In de presentaties UAC Internals en Windows Security Boundaries die ik in het verleden heb gepubliceerd, heb ik al laten zien hoe malware het verzoek om meer bevoegdheden kan kapen (te zien vanaf minuut 1:03 in het praatje over beveiligingsgrenzen). Mocht alles tegenzitten en heeft de malware zijn slag geslagen, dan zijn standaard gebruikersrechten toereikend voor praktisch al zijn schadelijk werk en kan de malware zich bijvoorbeeld automatisch laten uitvoeren bij elke aanmelding van de gebruiker, overgaan tot het stelen of verwijderen van alle gegevens van de gebruiker of zelfs als onderdeel van een botnet gaan f ungeren. TechNet Magazine
UAC in Windows 7 Hiervoor heb ik een aantal taken genoemd die nu ook beschikbaar zijn voor standaardgebruikers in Windows 7. We willen ons streven naar een betere gebruikerservaring voortzetten zonder dat het ten koste gaat van de UAC-doelstellingen. Veel gebruikers klaagden over het feit dat Windows Vista zelf bij het uitvoeren van gangbare systeembeheertaken vaak naar beheerdersrechten vraagt. Omdat het belang van onze klanten voorop staat, willen we zorgen dat Windows goed werkt in een omgeving voor standaardgebruikers. De prompts voor verhoogde bevoegdheid lijken daar geen bijdrage aan te leveren, omdat gebruikers slechts gedwongen worden tot een extra handeling in een dialoogvenster dat door praktisch niemand wordt gelezen. Windows 7 beoogt daarom dergelijke prompts in het dagelijks gebruik zoveel mogelijk achterwege te laten en dit zoveel mogelijk door gebruikers zelf te laten regelen in de beheerdersmodus. Om dit te bereiken hebben we het sys teem aangepast zodat mensen meer taken kunnen uitvoeren met standaardrechten en minder prompts te zien krijgen waar nu sprake is van meerdere opeenvolgende prompts (zoals bij de installatie van een ActiveX-besturingselement in IE). Windows 7 bevat tevens twee nieuwe UAC-modi die kunnen worden geselecteerd in een UACconfiguratievenster (zie Figuur 3). U kunt dit dialoogvenster openen door in het configuratiescherm achtereenvolgens te klikken op User Accounts, User Accounts en Change User Account Control Settings. Ook kunt u klikken op de koppeling Change When Notifications Appear in een prompt of vanuit het Action Center. De standaardinstelling (zie Figuur 3) is een van de nieuwe niveaus. Geheel bovenaan de schuifregelaar bevindt zich de instelling Always Notify, die in Windows Vista als standaardinstelling wordt gebruikt. In Windows 7 krijgt de gebruiker daarentegen alleen een prompt te zien wanneer een niet-Windows uitvoerbaar bestand om meer bevoegdheden vraagt. De toestemming zelf wordt vervolgens op dezelfde manier verleend als onder Windows Vista. Onder deze standaardinstelling op de schuifregelaar bevindt zich de tweede nieuwe instelling. Deze heeft dezelfde naam als de instelling erboven maar dan met de toevoeging ‘(do not dim my desktop)’. Het enige verschil tussen deze instelling en de stanTechNet Magazine
daardmodus is dat de prompts niet in de beveiligde desktop worden weergegeven, maar op die van de gebruiker. Het voordeel hiervan is dat de gebruiker de desktop g ewoon kan gebruiken als de prompt in beeld is. Maar er is dan wel het risico dat toegankelijkheidssoftware van derden mogelijk niet goed werkt in combinatie met de prompt. Met de onderste positie op de schuifregelaar wordt de UAC-technologie helemaal uitgeschakeld. In dat geval wordt alle software onder een PA-account met volledige beheerdersrechten uitgevoerd en zijn zowel de virtualisatie van het bestandssysteem en van het register, en de Protected Mode IE uitgeschakeld. Omdat er met deze instelling geen prompts worden weergegeven, betekent het verlies van de Protected Mode IE een aanzienlijke aderlating.
Auto-elevation De reden waarom er met de twee middelste instellingen voor de (meeste) uitvoerbare bestanden van Windows geen prompt wordt weergegeven voor verhoogde bevoegdheden, is dat de bevoegdheden voor dergelijke eigen uitvoerbare bestanden automatisch worden verleend. Wat beschouwt Windows in deze context als een uitvoerbaar bestand van Windows? Hoewel het antwoord op deze vraag afhankelijk is van verschillende factoren, moeten er twee zaken onomstotelijk vaststaan. Ten eerste moet het bestand digitaal ondertekend zijn door Windows Publisher, het certificaat waarmee alle code
Figuur 4 De eigenschap autoElevate
Figuur 5 Shell-registersleutel juli 2009
33
Beveiliging van Windows wordt ondertekend. Een Microsoft-ondertekening alleen is niet voldoende, omdat anders Microsoft-software die niet bij Windows wordt geleverd ook als Windows wordt beschouwd. En ten
Bij COM-objecten kunt u beheerdersrechten aanvragen met een registerwaarde in de registersleutel tweede moet het bestand zich bevinden in een map die het kenmerk ‘veilig’ heeft. Een veilige map is een map die niet door standaardgebruikers kan worden gewijzigd en voorzien is van het pad %SystemRoot%\ System32 (bijvoorbeeld \Windows\ System32). Ook veilig zijn de meeste hierin aanwezige submappen, %SystemRoot%\ Ehome, alsmede een handjevol mappen onder %ProgramFiles% zoals die van Windows Defender en Windows Journal. Verder gelden er afzonderlijke regels voor het automatisch verhogen van rechten, afhankelijk van of het uitvoerbaar bestand een normaal .exe, Mmc.exe of COM-object is. Bij de hierboven gedefinieerde uitvoerbare bestanden van Windows van het type .exe worden de bevoegdheden automatisch verhoogd als de eigenschap autoElevate is opgegeven in het manifest (tevens de plek waar toepassingen hun verzoek om beheerdersrechten duidelijk maken aan UAC.) Als we met de tool Sysinternals Sigcheck een dump willen maken van het manifest van Task Manager (Taskmgr.exe), gebruiken we het commando ‘sigcheck –m %systemroot%\ system32\taskmgr.exe’. In het resultaat in Figuur 4 is te zien dat de eigenschap autoElevate is ingesteld voor Task Manager. Als u in de mappenstructuur wilt zoeken naar uitvoerbare bestanden waarvoor de automatische toewijzing van bevoegdheden is ingeschakeld, gebruikt u de volgende commando van de tool Sysinternals Strings: strings ñs *.exe | findstr /i autoelevate
Er bestaat tevens een vaste lijst van uitvoerbare bestanden van Windows waarvoor een automatische verhoging van bevoegdheden geldt. Deze uitvoerbare bestanden van Windows worden ook los van Windows 7 geleverd en moeten dus ook g eschikt zijn voor downlevel systemen waarop een automatische verhoging een fout zou genereren. 34
juli 2009
De lijst bevat programma’s zoals de migratiewizard Migwiz.exe, de pakketmanager Pkgmgr.exe en Spinstall.exe, het installatieprogramma voor Service Packs. De MMC-module (Microsoft Management Console) Mmc.exe krijgt een speciale behandeling, omdat deze module als host fungeert voor allerlei snap-ins voor systeembeheer die als DLL’s worden geïmplementeerd. Mmc.exe wordt gestart met een opdrachtregel voorzien van een .MSC-bestand waarin wordt aangegeven welke snap-ins MMC moet laden. Wanneer Windows een verzoek om beheerdersrechten krijgt van Mmc.exe, hetgeen gebeurt wanneer MMC wordt uitgevoerd met een PA-account, wordt eerst vastgesteld of Mmc.exe een uitvoerbaar bestand van Windows is. Daarna wordt het .MSC-bestand getoetst. Om in aanmerking te komen voor een automatische verhoging van bevoegdheden, moet het .MSC-bestand voldoen aan de criteria voor uitvoerbare bestanden van Windows (ondertekend door Windows en opgeslagen op een veilige locatie), en moet het bestand opgenomen zijn in een interne lijst van .MSC’s die een automatische verhoging van bevoegdheden kennen. In die lijst zijn zo’n beetje alle .MSCbestanden opgenomen die bij Windows worden geleverd. Bij COM-objecten kan een verzoek om beheerdersrechten worden aangegeven met een registerwaarde in de registersleutel. Dit gebeurt door de subsleutel ‘Elevation’ te maken en de waarde ‘Enabled’ ervan op 1 in te stellen. Figuur 5 toont de registersleutel voor het Shell-object Copy/Move/Rename/ Delete/Link dat de verkenner gebruikt als een gebruiker een bewerking in het filesystem uitvoert op een locatie waarvoor zijn account onvoldoende toegangsrechten heeft. Bij de automatische verhoging van bevoegdheden voor COM-objecten geldt tevens dat ze een uitvoerbaar bestand van Windows moeten zijn en door een uitvoerbaar bestand van Windows moeten zijn geopend. (Daarbij is inschakeling van de automatische verhoging voor het uitvoerbare bestand dat het object opent, niet vereist.) Wanneer u met een PA-account werkt en in de Verkenner bijvoorbeeld een submap maakt in de map %ProgramFiles%, treedt een automatische verhoging van bevoegdheden in werking. Dit kan doordat het COMobject om bevoegdheden vraagt en zowel de DLL van het object als de Verkenner uitvoerbare Windows-bestanden zijn. TechNet Magazine
UAC-doelstellingen Wat gaat er precies schuil achter al die speciale regels voor de automatische verhoging van bevoegdheden? Kan een applicatieonwikkelaar onbedoeld of zijdelings te maken krijgen met beheerdersrechten als gevolg van auto-elevation? Deze vraag dient als leidraad bij de keuze wat wel en wat niet toekomt aan de automatische verhoging van bevoegdheden. Cmd.exe is uitgesloten van auto-elevation, omdat dit een programma is waarmee batchscripts worden uitgevoerd via argumenten op de opdrachtregel en de doorsneegebruiker over het algemeen geen opdrachtprompts met extra bevoegdheden uitvoert (vaak weet hij niet eens wat een opdrachtprompt is). Dezelfde keuze is gemaakt voor Rundll32. exe, dat als uitvoerbaar bestand plug-ins in het configuratiescherm host. In de definitieve release van Windows 7 is Rundll32. exe uitgesloten van auto-elevation, doordat er voor algemene beheertaken geen extra bevoegdheden nodig zijn en anders het risico zou ontstaan dat developers onbedoeld beheerdersrechten vragen voor de willekeurige DLL’s die op de bijbehorende opdrachtregel kunnen voorkomen.
Gebruikerswensen Sinds de bètaversie van Windows Vista hebben eindgebruikers gevraagd om Windows te voorzien van een mogelijkheid om willekeurige toepassingen toe te voegen aan de lijst voor automatische verhoging van bevoegdheden. Hierbij wordt meestal als reden aangevoerd dat een toepassing van derden wordt gebruikt die de gebruikers dagelijks dwingt om een prompt voor b evoegdheden te beantwoorden. In Windows 7 is deze mogelijkheid net als in Windows Vista niet opgenomen. We hebben begrip voor de ergernis van deze gebruikers en wellicht is het verzoek om beheerdersrechten van die toepassingen volstrekt legitiem, maar het risico dat developers hun code onvoldoende aanpassen voor standaardgebruikersrechten is nu eenmaal te groot. Zelfs als de lijst met toepassingen die automatische bevoegdheden krijgen, alleen toegankelijk zou zijn voor beheerders, zouden developers kunnen volstaan met een eenvoudige wijziging van het installatieprogramma (en een eenmalige toewijzing) om hun toepassing aan de lijst toe te voegen. In plaats daarvan willen we de nadruk legTechNet Magazine
gen op de samenwerking met developers van toepassingen, zodat zij hun programma’s goed kunnen laten werken voor standaardgebruikers.
DLL-injectie Verschillende mensen hebben opgemerkt dat software van derden die wordt uitgevoerd met een PA-account met standaardgebruikersrechten, het mechanisme van auto-elevation bevoegdheden kan gebruiken om beheerdersrechten te krijgen. De software kan bijvoorbeeld de API WriteProcessMemory gebruiken om code in de verkenner te injecteren en de API CreateRemoteThread om die code uit te voeren. Een dergelijke techniek wordt DLL-injectie genoemd. Aangezien die code wordt uitgevoerd in de verkenner (een uitvoerbaar bestand van Windows), kunnen COM-objecten met automatisch verhoogde bevoegdheden, zoals het object Copy/Move/ Rename/Delete/Link, worden gebruikt om registersleutels of systeemmappen aan te passen zodat de software beheerdersrechten krijgt. Hoewel het dus mogelijk is, kan het alleen op een doordachte en omslachtige manier. We denken daarom dat normale ontwikkelaars er eerder voor kiezen om hun software aan te passen voor uitvoering met standaardgebruikersrechten. We raden onwikkelaars zelfs af om zich te verlaten op het mechanisme voor het verhogen van bevoegdheden en raden hun in plaats daarvan aan hun software geschikt te maken voor uitvoering in de standaardgebruikersmodus. In het verlengde hiervan zou men kunnen veronderstellen dat malware langs dezelfde weg beheerdersrechten zou kunnen verwerven. Ook dat is waar, maar zoals gezegd kan malware het systeem ook via de prompts voor bevoegdheden binnendringen. Voor malware is de standaardmodus van Windows 7 niet meer of minder veilig dan de modus Always Notify (‘Vista-modus’) en bestaat er in die modus dus nog steeds de kans dat malware met beheerdersrechten inbreekt. }
Mark Russinovich is Technical Fellow bij Microsoft in de Platform en Services Divisie. juli 2009
35
