Mellékleteink: HUP | Gamekapocs
Keres

Tíz tévhit a Windows Vista biztonságával kapcsolatban

TechNet, 2007. december 13. 08:22
Ez a cikk több évvel ezelőtt születetett, ezért előfordulhat, hogy a tartalma már elavult.
Frissebb anyagokat találhatsz a keresőnk segítségével:

Természetesen hosszabb időre lesz szükség ahhoz, hogy valamennyi Windows-felhasználó tisztában legyen a Windows Vista összes biztonsági újdonságával, változásaival. Az informatikai szakemberek számára még ennél is sokkal fontosabb, hogy ismerjék a leggyakoribb tévhiteket, amik a rendszerrel kapcsolatban élnek az emberek fejében.

A Microsoft 2002-ben jelentette be a Megbízható számítástechnika (Trustworthy Computing) kezdeményezését válaszlépésként a Windows platformot ért, mindennapivá vált támadások miatt. A kezdeményezés célja, hogy valamennyi megjelenő Microsoft termék tervezésénél (Secure by Design), alapértelmezett beállításainál (Secure by Default), telepítésénél (Secure by Default) és a kapcsolódó leírások, ismertetők készítésénél, visszajelzések gyűjtésénél (Communication) a biztonság folyamatosan szem előtt legyen tartva.

A Windows XP még két évvel e kezdeményezés előtt jelent meg, ezért nem tudott teljes mértékben profitálni ennek a paradigmaváltásnak az előnyeiből, noha a 2004-ben megjelent második javítócsomag jelentős lépést jelentett ebbe az irányba. A Windows Vista az első olyan Microsoft operációs rendszer, amely már a tervezésétől fogva a Megbízható számítástechnika filozófia figyelembevételével készülhetett. A Vista esetében sok rendszerkomponens teljes átalakításon esett át (például a teljes hálózatkezelés újraírásra került), ami az új funkciók bevezetésén és régi funkciók javításán túl lehetővé tette, hogy a rendszer biztonsága többé ne lehessen megkérdőjelezhető.

A Vista számos olyan biztonságot növelő újdonsággal rendelkezik, amelyek nem léteztek a korábbiakban. Gondoljunk csak a kernelt érintő változásokra, az Address Space Layout Randomization bevezetésére, a hitelesítési újdonságokra, Network Access Protection-ra, BitLocker-re, IPSec és Windows Firewall újdonságokra, és még hosszan folytathatnánk a sort.

Természetesen hosszabb időre lesz szükség ahhoz, hogy valamennyi Windows-felhasználó tisztában legyen a Windows Vista összes biztonsági újdonságával, változásaival. Az informatikai szakemberek számára még ennél is sokkal fontosabb, hogy ismerjék a leggyakoribb tévhiteket, amik a rendszerrel kapcsolatban élnek az emberek fejében -- hiszen egy rendszer tervezésekor, bevezetésekor és üzemeltetésekor ezek kulcsfontosságúak lehetnek.

Első tévhit: a rendszergazda fiók alapértelmezetten letiltásra kerül

Igaz, hogy a Vista letiltja az alapértelmezett Rendszergazda (Administrator) fiókot, de csak akkor, ha vannak más aktív Rendszergazdák (Administrators) csoport tagsággal rendelkező fiókok is rendszerünkben -- ezzel védi a Vista a rendszert a beépített Rendszergazda elleni támadásoktól -- hiszen ennek a fióknak a neve mindenki számára ismert, és a jelszava is gyakran egyszerű, vagy akár üres is lehet, így können törhető. Egy új Vista telepítésen az első -- telepítéskor -- felvett felhasználói fiók bekerül a Rendszergazdák csoportba (ugyanúgy, ahogy Windows 2000 és Windows XP esetén), de a továbbiak nem.

Amint a következő rendszergazda csoporttagságú felhasználó felvételre kerül, a Vista letiltja az alapértelmezett Rendszergazda fiókot. Fontos kiemelni, hogy a Rendszergazda (Administrator) alapértelmezetten létrejövő fióknak nincs jelszava. Ennek javasolt mindenképpen egy bonyolult jelszód adni, még akkor is, ha letiltásra kerül.

Második tévhit: a User Account Control sem csökkenti a szükséges rendszergazdák számát

A Windows platformon rengeteg biztonsági probléma abból adódik, hogy a felhasználók rendszergazdai jogokkal futtatják az alkalmazásokat, noha erre az esetek többségében nincs szükség. Már Windows XP esetében is jelentősen kisebb a rendszer támadási felülete, amennyiben a felhasználó nem rendszergazdai jogokkal jelentkezik be. A "standard" felhasználói jogokkal bejelentkező felhasználók nevében futtatott alkalmazások nem tudnak kárt tenni sem az operációs rendszerben, sem más felhasználók állományaiban. Azonban Windows platformra fejlesztett szoftverek sok esetben az ellátott funkciójukhoz képest indokolatlanul igényelik az adminisztrátori jogosultsággal való futtást.

A rendszergazda jogosultság teljes hozzáférést ad az operációs rendszerhez és a számítógép minden komponenséhez, lehetővé téve olyan módosításokat, amelyek a rendszert működésképtelenné tehetik, vagy kárt tehetnek más felhasználók adataiban. Vista előtt az elsődleges felhasználási modell az adminisztratív jogok meglétére épített, a szoftverfejlesztők többnyire feltételezték, hogy a programjuk elérhet és módosíthat akármilyen fájlt, regisztrációs adatbázis bejegyzést, vagy operációs rendszer beállítást.

További probléma, hogy a felhasználóknak időnként szükséges műveletek elvégzése, mint például programok telepítése, egyes rendszerbeállítások módosítása -- idő megváltoztatása, tűzfal port nyitása, stb. -- szintén rendszergazdai jogokat igényeltek.

A felhasználói fiókok felügyelete (User Account Control, UAC) ennek a problémakörnek a kezelésére született. A cél az volt, hogy a felhasználó "standard" jogokkal futtasson minden alkalmazást, viszont azokat az alkalmazásokat, amelyek rendszergazdai jogokat igényelnek, egyszerűen lehessen engedélyezni. Ez azt jelenti, hogy függetlenül attól, hogy a felhasználó rendelkezik-e rendszergazdai csoporttagsággal, a nevében elindított alkalmazások automatikusan nem kapják meg ezt a rendszergazdai jogkört (ez alól kivétel a beépített Administrator-Rendszergazda fiók. Rá nem alkalmazódik az UAC).

A felhasználónak külön engedélyeznie kell azt, amikor rendszergazda jogaival élni szeretne. Ez lehetőséget biztosít a felhasználónak, hogy eldöntse, egy alkalmazás élhet-e a ezekkel jogokkal. Ez egyben azt is jelenti, hogy a felhasználó minden esetben információt kap arról, hogy milyen alkalmazások indulnak el amelyek rendszergazdai joggal futnak.

Amikor egy felhasználó bejelentkezik, az UAC két security tokent hoz létre. Egy "normál" felhasználói tokent és egy másikat, amely tartalmazza az rendszergazdai jogokat. Egy elindított folyamat nem kapja meg a rendszergazda jogokat, amennyiben a felhasználó a folyamat indulásakor nem engedélyezi azt az UAC felületén keresztül. A létrejött "normál" felhasználói token a következőkben különbözik a rendszergazdai tokentől:

  • Kilenc rendszergazda-szintű jog nincs benne
  • A felhasználó integritási szintje Medium, High helyett
  • Alkalmazódik rá egy alapesetben mindent tiltó SID
  • Megjelenhet számára az UAC engedélyező ablak (consent.exe)
  • Fájl és regisztrációs adatbázis virtualizáció alkalmazódhat rá

Ennek révén még a rendszergazdai jogokat amúgy birtokló felhasználó sem rendszergazdai jogokkal böngészi az internetet, vagy nyit meg egy potenciálisan veszélyes e-mailt.

A Vista a UAC ellenére továbbra is rendszergazdai jogot követel meg a rendszer szempontjából érzékeny műveletek elvégzésére. A szükséges rendszergazdai jogokkal rendelkező felhasználók számának további csökkentését a Vista többek között a következő módokon teszi lehetővé:

  • Sok feladat elvégzése a Vista esetében már nem igényel rendszergazda jogokat, szemben a korábbi Windows verziókkal (pl. időzóna megváltoztatása, vezeték nélküli hálózat konfigurációja, energiagazdálkodás beállításai, kritikus Windows frissítések telepítése, stb.)
  • A Vista lehetővé teszi a rendszergazdák számára, hogy meghatározzák, hogy a nem rendszergazda jogú felhasználók milyen meghajtóprogramokat, eszközöket, ActiveX vezérlőket telepíthetnek. Így a nem rendszergazdai jogú felhasználók is telepíthetnek engedélyezett nyomtatókat, VPN szoftvereket, stb.
  • Alap hálózati konfigurációk elvégzéséhez a felhasználót elegendő hozzáadni a Network Configurations Operators csoporthoz. Ennek a csoportnak például joga van az IP címek megváltoztatásához, a DNS cache ürítéséhez, vagyis anélkül végezhetők el ezek a feladatok, hogy a felhasználó Administrators csoporttagságára lenne szükség.
  • Az UAC fájlrendszer és regisztrációs adatbázis virtualizációja, valamint a beépített alkalmazás kompatibilitási sémák segítségével több, korábban rendszergazdai jogokat igénylő alkalmazást futtatathatunk akár standard felhasználóval is

Összefoglalva, a Vista rengeteg lehetőséget tartalmaz, amely révén a felhasználók elvégezhetik a feladataikat anélkül, hogy rendszergazdai jogokra lenne szükségük.

Harmadik tévhit: csak Rendszergazdák használják a UAC elevációt

A UAC engedélyező ablakban nem adhatunk meg "standard" felhasználói fiókot, hiszen egy ilyen fióknak nincsenek olyan jogai, amit az UAC elevációval lehetne engedélyezni. Azonban az UAC engedélyezés ettől még nem csak a Rendszergazdák csoport tagjaira érvényes. Bármilyen fiók a Rendszergazdák, Biztonsági másolat felelősök, Hálózati rendszergazdák vagy Kiemelt felhasználók csoportokból szintén magasabb jogkörűnek számítanak, így ezen csoportok tagjaira is érvényes az UAC eleváció.

Például, amennyiben egy felhasználói program futtatásához valamelyest eltérő jogokra van szükség, de nem kívánunk rendszergazda jogokat adni, az alábbiakat tehetjük: egy másik felhasználói fiókot létrehozunk és hozzáadjuk a Kiemelt felhasználók (Power users) csoporthoz -- amely Vista esetében semmivel nem tartalmaz több jogot, mint a Users csoport, csak kompatibilitási okok miatt maradt meg -- és ennek a csoportnak adjuk meg az alkalmazás futtatásához szükséges jogokat. Ezután, ha egy felhasználónak (akinek a fiókja csak "standard" Users csoport tagsággal rendelkezik) szüksége van az alkalmazásra, akkor az indítás után megadhatja a korábbiakban felvett Power Users csoporttagságú fiók nevét és jelszavát, és azt gépeli be az UAC engedélyezési ablakba.

Negyedik tévhit: csak négy integritási szint létezik

A folyamatok és más objektumok biztonsági leíróiban is új SID-ek jelentek meg, ezek a Mandatory Integrity Level (IL) szintek. A következők szintek léteznek:

Szint SID Hex Használati példák
Untrusted S-1-16-0 0 Anonymus/Null Session
Low S-1-16-4096 1000 Védett módú Internet Explorer
Medium S-1-16-8192 2000 Hitelesített felhasználók/Nem elevált
Rendszergazda jogúak
High S-1-16-12288 3000 Rendszergazdák/Elevált jogok
System S-1-16-16384 4000 Helyi rendszer
Protected process S-1-16-20480 5000 Rendszer

Az egyes objektumok integritási szintjei a System Access Control List-eken (SACL) tárolódnak. Az egyes folyamatok, szálak minden esetben rendelkeznek integritási szint bejegyzésekkel. A fájl és regisztrációs adatbázis bejegyzések, amennyiben nem rendelkeznek explicit IL bejegyzéssel, implicit Medium IL szint hozzáférésűek. Azok az objektumok, amelyeket Medium vagy magasabb integritási szintű folyamatok hoznak létre Medium IL megjelölést kapnak. Azok az objektumok, amelyeket Low integritási szintű folyamatok (például a védett módú Internet Explorer) hoznak létre Low megjelölést kapnak.

Az integritási szintek ellenőrzése minden esetben a Discretionary Access Control List (DACL) -- amely tartalmazza az objektumhoz tartozó hozzáférési listát -- ellenőrzések előtt történik. Egy folyamat, vagy szál csak akkor nyithat meg egy objektumot írásra, ha az IL-je nagyobb vagy egyenlő, mint a megnyitandó objektum IL-je. Egy szál vagy folyamat csak akkor nyithat meg egy objektumot olvasásra, ha az nem egy folyamat objektum, vagy a szál, vagy a folyamat IL-je nagyobb vagy egyenlő mint a másik folyamat IL-je. Ez meggátolja az érzékeny információk kiszivárgását a memóriaolvasások révén. Az ablakkezelő alrendszer szintén figyelembe veszi az IL-eket, ez meggátolja a Window Message-ken keresztüli hozzáférést is.

Ötödik tévhit: a UAC virtualizáció meggátolja a rosszindulatú fájl- és registry írásokat

A UAC biztosít egy fájlrendszer- és regisztrációs adatbázis virtualizációt is. Ennek révén az ilyen "virtualizáltan" futtatott alkalmazások úgy végezhetnek írást a fájlrendszerbe vagy a regisztrációs adatbázisba, hogy közben a valódi fájlrendszert és regisztrációs adatbázist nem módosítják. A fájlrendszeri írások esetében a rendszermappákba (Windows, System32, Program Files, kivétel a rendszer által védett .exe és .dll állományok és futtatható állományok esetén) történő írások a virtualizált folyamatról átirányításra kerülnek a UsersAppDataLocalVirtual Store mappában megfelelő almappákba, a regisztrációs adatbázis írások pedig a HKCUSoftwareClassesVirtualStore kulcs alá.

Mint látható, mind a kettő a felhasználó profilja alatt helyezkedik el, így a felhasználónak van is rá írási joga. Ha felhasználónkénti szabály nem definiálja másképp, az olvasás elsőként a globális helyről történik. A fájlrendszer virtualizációja egy filter driver (luafv.sys) segítségével valósul meg, a regisztrációs adatbázisé pedig beépítetten. Az alábbi ábra ezt mutatja be:

Látható, hogy noha az Administrators csoport tagja vagyok, a WindowsSystem32 mappába írás nem sikerült a nem elevált jogokkal indított parancssorban. A virtualizáció bekapcsolásakor (alapértelmezetten a Windows komponensek nem virtualizáltan indulnak) azonban az írás sikerült. A dir paranccsal ki is listázta a létrejött fájlt, azonban a virtualizáció kikapcsolásakor látható, hogy a fájl nem a WindowsSystem32 mappában jött létre, hanem az átirányított helyen.

Azok a futtatható állományok, amelyek a manifest-jükben máshogy nem rendelkeznek, virtualizáltan kerülnek futtatásra (a Windows komponensek mindegyikének a manfest-je nem virtualizált futtatást ír elő, a példában ezért kellett a parancssort a Task Manager-ben kézzel átállítani a virtualizált futtatásra).

A fájl és regisztrációs adatbázis virtualizáció meggátolja az írásokat a nem rendszergazda jogú (nem elevált) folyamatok számára, de csak az alábbi helyekre:

  • Program Files és minden alkönyvtára
  • Program Files (x86) 64-bites rendszereken
  • Windows és minden almappája, beleértve a System32-t is
  • Users%AllUsersProfile% ProgramData (Ami XP-n a Documents and SettingsAll Users mappa volt)
  • Documents and Settings (átirányított mappa)
  • HKLMSoftware

Az alábbi objektumok azonban soha sem kerülnek virtualizálásra:

  • Vista alkalmazások
  • Futtatható állományok, mint az .EXE, .BAT, .VBS és .SCR. További fájlrendszeri kivételek a HKLMSystemCurrentControlSetServicesLuafvParameters ExcludedExtensionsAdd kulcsban adhatóak meg.
  • 64-bites alkalmazások és folyamatok
  • Azok az alkalmazások, amelyek manifesztjükben definiálják, hogy nem virtualizáltan futtatandók (mint az összes Vista komponens)
  • Folyamatok és alkalmazások amelyek rendszergazdai jogokkal futnak
  • Kernel módú alkalmazások
  • Műveletek, amelyek nem interaktív bejelentkezésből származnak (pl.: fájlmegosztáson keresztüli elérés)
  • Alkalmazások amelyek a regisztrációs adatbázisban a Dont_Virtualize registry flag-el megjelöltek (A reg.exe segítségével láthatjuk a három új registry flag-et a HKLMSoftware kulcs alatt: DONT_VIRTUALIZE, DONT_SILENT_FAIL, RECURSE_FLAG)
A cikk több oldalból áll:
Facebook
Adatvédelmi okokból az adott hír megosztása előtt mindig aktiválnod kell a gombot! Ezzel a megoldással harmadik fél nem tudja nyomon követni a tevékenységedet a HWSW-n, ez pedig közös érdekünk.
Augusztus 28-án és 29-én folytatjuk, fejlesztői meetupokkal jövünk. A program éles, lehet regisztrálni.