| | | | Mottó: Hittél, mert láttál. Boldogok, akik nem látnak, mégis hisznek! /Biblia, Jézus/ | 2011. április 1. | | | | WYSIWYG is hacked... WTF??? TTF! | | | | | Na, akkor ennyit a bolondozásról, és lássuk, mi igaz a címből!
A betűkészlet (pl. TrueType font - TTF) állományok a szövegek megjelenítéséhez elengedhetetlenek a Microsoft Windows számára. Fontosságukat jelzi az is, hogy ezek az állományok elektronikus aláírással vannak ellátva, hogy azokat akárki ne tudja lecserélni, vagy legalábbis trükközés esetén az operációs rendszer azonnal jelezze azt a felhasználó felé. Ez az elmélet... A gyakorlat pedig azt mutatja, hogy az a kriptográfiai védelem, ami működik a driver-ek, vagy egyéb érzékeny állományok (pl. .dll, .exe, .cab, .jar, .msi) esetében, az megkerülhető a betűkészleteknél. Az ügy azért is izgalmas, mert a Windows Vista idején sokminden újra lett gondolva, ami a védelmet, hozzáférési szabályokat érinti, többszintű UAC (User Account Control) került meghatározásra, de a betűkészletek védelme valahogy elkerülte a fejlesztők figyelmét.
Hogyan lehet megkerülni a kriptográfiai ellenőrzést a betűkészleteknél? Nem is tudom, hogy meg kell-e kerülni azt, ami nincs, ugyanis többféle kísérletet hajtottam végre, de alapvetően nem tudom, hogy a TTF állományoknál milyen ellenőrzés megy le. Pontosabban, ha nincs aláírás a TTF állományon, akkor betűkészlet váltásakor lefagy az operációs rendszer, ha viszont van rajta akármilyen (!) aláírás, akkor viszont benyalja azt! Egy pl. böngészőben letöltődő aláírt .cab állománynál legalább az operációs rendszer feldob valami ablakot, amin látszódnak bizonyos adatok, de a betűkészleteknél mintha nem vizsgálna semmit a Windows az aláíróval, illetve a megbízható forrással kapcsolatban, pedig a leírás alapján valamit kellene néznie: You can create a test.spc and test.pvk for testing purposes with the tools provided in the font signing tool, but when you want to sign a font file "for real" you need to obtain these files from Certification Authority such as Verisign. Halkan megjegyzem azonban, hogy az "Only trust items found in the Trust DB" beállítás viszont alapértelmezetten mindenhol "FALSE"...
Fokozzuk az izgalmakat! Az, hogy más betűk jelennek meg Microsoft Word dokumentumokban vagy a Notepad felületén, messzebbre is vezethetnek. Tételezzük fel, hogy kibocsátunk egy elektronikusan aláírt számlát, ami azonnal jelzi, ha a védett adat megváltozik! Ebben egy dokumentum tárolja a számlaadatokat, benne a fizetendő összeggel. Ezt az e-számlát kell elküldeni a címzettnek, hogy rendezze tartozását. A címzett számítógépén azonban valahogy lecserélésre kerül az a betűkészlet, amelyet a számlaadatokat tartalmazó dokumentum is használ. A címzett ellenőrzi az elektronikus aláírást a megkapott e-számlán. Az aláírás hiteles, ezért megnyitja a benne tárolt dokumentumot. Abban viszont mást lát a címzett, mint a küldő a módosított betűkészletnek köszönhetően. A címzett hisz a szemének, ezért pl. más összeget utal el.
Készítsünk egy módosított TTF állományt! Hozzáteszem, hogy ez nem tekinthető igazán klasszikus értelemben vett "hack"-nek, illetve hibának, hiszen nem kell mást csinálni, mint amit a Microsoft oldala is ír a saját betűkészlet készítéséről szóló howto-ban. Elvileg tehát mindenki tud, tudhat róla, hogy ez így működik. Ráadásul már Windows Server 2000 rendszeren így ment, de a Windows 7 rendszert is érinti!
Válasszunk ki egy TTF állományt:- pl. Lucida Sans Regular (TrueType)
C:/WINDOWS/Fonts/lsans.ttf Szerkesszük a TTF állományt:- szerkesztés a ttfedit alkalmazással
A minta TTF állományban az egyik szám került módosításra ("1" helyett "7"), azaz ha valaki pl. 10.000.000 Ft-ról szóló számlát akar kiegyenlíteni felém, akkor lehet, hogy 70.000.000 Ft-ot fog elutalni a bankszámlámra. - formázás FastFont alkalmazással
A TTF állomány megfelelő aláírásához szükséges. Ha kész a módosított betűkészletünk, akkor jön a legfontosabb dolog: alá kell digitálisan írni!
Telepítsük a TTF állományt:- eredeti TTF állomány törlése
- módosított TTF állomány telepítése
Ha sikerült lecserélnünk a betűkészletet, akkor ki lehet próbálni akár egy valós e-számlával is a trükközést. Gyorsan hozzáteszem, hogy nem az elektronikusan aláírt számla rossz, csak a megjelenítési réteg, amiért viszont az operációs rendszer a felelős. Az e-számla továbbra is hiteles, ha nem az emberi szem és agy dolgozza fel a benne tárolt adatokat, hanem bitszinten egy szerver, akkor az továbbra is jó összegeket fog "látni" és elutalni a bankszámlákra...
Ha hibát találunk, akkor megoldást is kell adni rá: az eset rávilágít arra, hogy ha nem bitszinten dolgozza fel egy szerver az adatokat, hanem egy egyszerű humán felhasználó, akkor számára egy megbízható megjelenítési réteget kell biztosítani. Úgy tűnik azonban, hogy a Windows betűkészletére támaszkodó megoldások (pl. különböző, Windows operációs rendszeren futó Office termékek) nem alkalmasak erre, mindenképpen egy tisztán képi adatot is tárolni kell (a gépnek szóló XML mellett) pl. egy e-számlában. A "tisztán képi" állomány alatt egy önleíró adatot képzelek el, ami nem használ külső, nem védett forrásokat, mint pl. TTF állományokat. A PDF esetében is - ha jól értem - lehet valamilyen módon használni TTF állományokat (pl. eZ Publish - eZPDF class), tehát a .pdf állományok sem számítanak ilyen szempontból teljesen megbízhatónak, a PostScript, azaz .ps állományoknál ez már alapvetően másképp működik, de ha biztosra akarunk menni (és bírjuk erőforrással), akkor valószínűleg valami bitmap-jellegű képet kell használni. A kérdés már csak az, hogy a képeket megjelenítő alkalmazások megbízhatónak számítanak-e... ;-)
A kapcsolódó anyagoknál található videón csak mintaadatokkal dolgoztam, de a lényeg azt hiszem, így is érthető. A videó Windows XP SP3 operációs rendszeren készült, de csatolok néhány képet Windows 7 környezetről is.
Kapcsolódó anyagok: (Az alapötletért köszönet illeti Garami Gábor és Psenák Péter kollégámat!)
| | vissza | | | | |
|