Soci (Soczó Zsolt) szakmai blogja

2006.11.10.

Vista Protected mode

Filed under: Security,Szakmai élet,Vista — Soczó Zsolt @ 14:43

Huncut dolog ez az IE7 védett mód, illetve a mögötte levő technológiák (csak Vistán, XP-n nem).

Ha egy process Integrity Levelje mondjuk 100, pl. egy protected módban futó IE7-ben futó kódé ennyi, akkor az hiába ír ki OutputDebugStringgel valamit, nem látszik a DebugView-ban, mert a debugview 200-as szinten fut. Minden user processz, amit az explorer indít alapban ezen a szinten fut, mert a child processzek öröklik a szülő integrity leveljét.

Nem tudom az OutputDebugString illetve a DebugView belül hogyan működik (pont most jól jött volna a DebugView forráskódja…), de a jelek szerint messagekkel, mert pont azokat blokkolják az integrity levelekben különböző processzek között.

Ezért ha Low Integrity alatt futó folyamat OutputDebugStringjét akarom megnézni, akkor Low-ban indítom el a Debugview-t. De hogyan? A korábbi cikkben van egy kis kódrészlet, ami megmutatja hogyan kell Low-ban elindítani egy új processzt. Az ott található kódot beraktam egy kis console appban, így LI ize.exe-vel máris bármit el tudok indítani low integrity levelen.
Pontosan a következőket befolyásolja a protected mód a User Interface Privilege Isolation (UIPI)-re építve:

A lower privilege process cannot:

  • Perform a window handle validation of higher process privilege.
  • SendMessage or PostMessage to higher privilege application windows. These application programming interfaces (APIs) return success but silently drop the window message.
  • Use thread hooks to attach to a higher privilege process.
  • Use Journal hooks to monitor a higher privilege process.
  • Perform dynamic link library (DLL)–injection to a higher privilege process.

With UIPI enabled, the following shared USER resources are still shared between processes at different privilege levels.

  • Desktop window, which actually owns the screen surface
  • Desktop heap read-only shared memory
  • Global atom table
  • Clipboard

Szóval a clipboard még oszott, szép is lenne, nem lehetne másolni az IE-ből pl. notepadba kopipasztával.

Ez úgy néz ki, hogy ha létrehozol pl. egy megnevezett mutexet egy 200-as szálban, és azt el akarod érni egy 100-as integrity levelű kódból, akkor access denied-ot kapsz. Azért, mert ha nincs ACL az erőforráson, akkor azt úgy értelmezi a Vista, mitha egy 200 vagy e fölöttieket beengedő ACL lenne rajta (részben írtam már erről).
Csak úgy férhet hozzá a 100-as szál a 200-as által létrehozott globális erőforráshoz, ha az erősebb szál kézzel rárak egy olyan ACL-t, ami beengedi a 100-asokat. De miféle ACL ez, hisz tudjuk, hogy csak DACL van, ami Józsinak ad read jogot mondjuk egy file esetén, vagy az SACL, ami az auditok igényét tárolja. Nos, az SACL-t bővítették ki, az Integrity leveleket itt tárolják.

Szopatós a Vista, beleköp több ponton az appok életébe, de jól teszi, végre látszik, hogy komolyan vették a secut az msnél. Persze, a Windows 2003 az XP SP2 már jól láthatóan ebbe az irányba ment el, de most befoltoztak olyan arhitekturális likat is, mint amilyen a mindenki küldhet mindenkinek üzenetből fakadt.

Ja, és még egy tapasztalat. Low, azaz 100-as Integrity level esetén virtualizálják a file és reg hozzáférést is, ezért számít, hogy ha neked csak read jog kell valamihez, akkor tényleg azt kérj, ne read write-ot. Gyakori, hogy az ember lazán lekér egy all accesses handle-t, pedig csak read kellett volna. Az ilyen akciók könnyen büntivel végzik Vistában. Még jobban észnél kell lenni programozáskor, ez a secu ára. De legalább precízebb munkára kényszerít.

3 Comments

  1. Ha jól emlékszem, az OutputDebugString() a háttérben named eventeken és egy szintén named system swapre mappelt memory mapped file-on alapszik (adatcsere-terület). Nyilván mivel ezek kernel objectek, ezekre is játszik a fenti security probléma, de konkrétan üzenetekről nincs szó :)

    Istenem, ez olyan szépen hangzott.

    Közben utánanéztem, jól emlékeztem :)http://www.codeproject.com/dotnet/Debug_Monitor_string.asp

    Comment by pb — 2006.11.10. @ 15:51

  2. Egyébként kíváncsi vagyok, hogy az embedded IE HTML engine-re mennyire vonatkozik a protected mode, mert rendesen alapozunk némelyik szoftverünkben az IE-re pl. report megjelenítéséhez és már volt szívás az IE servereken alapértelmezett “restricted mode”-jából, amihez custom security managert kellett írni (nagy öröm volt kitalálni).

    Ettől még tényleg úgy tűnik, hogy ezúttal sikerült valami jót összehozniuk.

    Comment by pb — 2006.11.10. @ 15:54

  3. Szerintem a beépített cuccaikra is pontosan ugyanazok a restrikciók vonatkoznak.
    Küszönöm a debugos cikket.

    Comment by Soczó Zsolt — 2006.11.15. @ 11:51

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress