Malte Timmermann válasza a Black Hat 2009 „OOo Biztonsága” előadásában előadottakra

Malte Timmermann aki az OOo biztonságáért felelős, a blogján válaszolt a Black Hat 2009 konferencián Eric Filiol és Jean-Paul Fizaine által előadottakra: http://blogs.sun.com/malte/entry/comments_on_the_black_hat

A blog bejegyzés teljes fordítása:

Megjegyzések a Black Hat 2009 „OOo Biztonsága” előadásra

A válaszaim a Eric Filiol és Jean-Paul Fizaine jegyzett OpenOffice v3.x Biztonsági gyengeségei dokumentumban („fehér papír” -ban) leírtakra.

A cikkből vett kijelentések (nem idézeteket) dőlt betűvel jelezve. Az eredeti szöveg kikereshető a szabadon elérhető dokumentumban.

1. Fejezet Bevezetés

Néhány kérdés amire itt is hivatkoztak, és amit a korábbi „Az OpenOffice.org dokumentumok vírusok általi sebezhetőségének részletes elemzése” cikkben írtak le.

A felsorolt felhasználói felületen át elvégzett műveletek és a felhasználói környezetben (user space) futó makrók kérdéséről itt nem beszélnék, csak rámutatok az erre a cikkre válaszoló blog hozzászólásomra.

Nem kezelt a nem titkosított, sima dokumentumok sértetlensége, fájlok és futtatható makrók adhatók hozzá

Igen, az ODF egy nyílt szabvány, így bármilyen sértetlenségi ellenőrzés jól dokumentált lehet. Más ODF alkalmazásoknak képesnek kell lennie az ellenőrzés megvalósítására, így a rosszhiszemű szoftver tudja azt, hogy milyen ellenőrzésen kell átesnie. A nem nyílt bináris fájlformátumok nem sokkal biztonságosabbak – csak egy kicsit bonyolultabbak (az ismeretlenség biztonsága).

Végül is mindegy is: ha valaki hozzáad egy makrót, az OOo figyelmeztetni fog, és megkérdezi a felhasználót, hogy tényleg futtatni akarja-e (ezt nem fogja megtenni ha a dokumentumban nem bízik). Ha az extra tartalom valamilyen végrehajtható fájl, az nem jelent semmit az OOo számára, figyelmen kívül hagyja.

Titkosított dokumentumok: Makrók hozzáadhatók, kicserélhetők, vagy eltávolíthatók

Az OOo 3.0-ban már nem lehetséges a titkosított dokumentumokhoz makrókat hozzáadni, vagy kicserélni. Ha a dokumentum titkosított az összes tartalom (tartalom folyam) titkosított egy és ugyanazon kulccsal.

Sajnos az OOo csak az ODF 1.2 formátumú dokumentumok esetén figyelmeztet a nem titkosított tartalomra. A régebbi típusú dokumentumok esetében kompatibilitás megőrzése miatt nem kerül ez kijelzésre. Már most dolgozunk azon, hogy ez a OOo 3.2 -ben ez megváltozzon, mivel érzékeltük, hogy ebben az esetben a biztonság fontosabb mint a kompatibilitás.

[FISSÍTÉS: Hibáztam amikor, azt állítottam, hogy ez a figyelmeztetés működik. Még most is lehetséges a titkosított makró lecserélése tiszta szöveges makróra.]

A titkosított dokumentumokból a makrók jelenleg is eltávolíthatók. De ennek nincs semmi káros hatása, de belátom, kissé furcsának tűnhet a felhasználó szemszögéből, mivel azt gondolja, hogy ezt egy titkosított dokumentummal nem lehetne megtenni.

Az OOo 3.2 biztonsága növelésén dolgozó csoportban megtárgyaltuk a lehetséges megoldásokat. Megértem azt, hogy Filiol úr a manifest.xml titkosítását támogatja, de ezt nem lehet megtenni, a mivel a használt, titkosítás/lenyomatképző (hash) algoritmus kerül benne leírásra, és az ODF alkalmazásnak képesnek kell lennie az olvasására. (Azt sem szabad figyelmen kívül hagyni, hogy az ODF 1.2 -nek lehetővé kell tennie különböző titkosítási algoritmusok használatát, mivel a különböző országok vagy cégek különböző elfogadott/engedélyezett/jóváhagyott algoritmussal rendelkezhetnek).

A jelenlegi elképzelésünk szerint a manifest.xml lenyomatképzőjét külön folyamban készítjük el, amit a dokumentum többi részét is aláíró kulccsal írunk alá. Az OOo így figyelmeztethet ha a lenyomatképző megsérült vagy nem létezik. További megbeszélésekre van szükség arra, hogy ezt a figyelmeztetést miként magyarázzuk meg a felhasználónak, mivel az OOo figyelmeztetheti a régebbi változat szerint titkosított, vagy más ODF alkalmazások által készített dokumentumok esetében is. A régebbi dokumentumok esetében szükség lehet e figyelmeztetés kikapcsolását lehetővé tevő opcióra is.

A továbbiakban azt tervezzük, hogy figyelmeztetés kerül kijelzésre, amikor az archívum néhány folyama nem szerepel a manifest.xml -ben. Az ODF előírás jelenleg kimondja, hogy csak a manifest.xml -ben felsorolt tartalom figyelembe veendő az ODF dokumentum szempontjából (eltérően a manifest .xml lenyomatképző titkosított értékétől, amelyet specifikálni kell még)

Lehetséges a digitális aláírás eltávolítása

Nekem ez így jó – az OOo felhasználói felületén keresztül is eltávolítható, nem látok semmi problémát benne.

(A titkosított dokumentumoknál az OOo 3.2 -ben ez már nem lesz lehetséges.)

2. Fejezet – ODF Formátum és a biztonsági tulajdonságok

ZIP az ODF Formátum és a kezelő eszközök

Nagyon sok módszer létezik arra miként bizonyosodjunk meg arról, hogy az ODF fájlok zip tárolót használnak – és senki sem állított mást. Én speciel nagyon szeretem azt a formát amit az ODFToolkit.org projekt használ: „a célunk az, hogy az OpenDocument formátum közvetlen és tiszta/világos kezelését lehetővé tevő eszközöket adjunk”.

A hivatkozott írás értelmében úgy tűnik mintha ez az eszköz a rossz indulatú felhasználásra az ODF dokumentumok manipulálására készülne. A nyílt szabvány lényege éppen az, hogy különböző típusú eszközök is használhatják. Érdemes megjegyezni, hogy a projektet eredetileg a mi embereink kezdték el itt Hamburgban, hogy más projektek könnyebben tudják az ODF -t befogadni.

Makrók helye – ezen fájlok lehetővé teszik, hogy egyszerű szöveg szerkesztéssel lényegesen megváltoztatható a dokumentum biztonsági állapota

Így van. A makrók lényege az, hogy a makrók szerzői sok mindent megtehetnek. Jó dolgokat és rossz dolgokat is. Lényegtelen az, hogy a makrókat milyen eszközzel készítettem.

Senki se futtasson makrókat, ha nincs meggyőződve azok biztonságáról. Semmi többet erről.

Dokumentum titkosítás: Nagyon meglepő azzal szembesülni, hogy a manifest.xml nem titkosított

Igen, de én nem találom meglepőnek, mivel, ahogy korábban is írtam ebben a cikkben, ez tartalmazza azokat a szükséges adatokat, amely alapján az ODF alkalmazás megtudja, hogyan kezelje a titkosítást.

Ahogy már írtam, azon gondolkodunk, hogy titkosított lenyomat értéket vezetünk be a manifest.xml -hez, így azt már majd nem lehet manipulálni a későbbiekben. A manifest.xml többi tartalmát nem érdemes elrejteni, mivel azt az információt (leginkább a folyam neveket) a zip fájlcímke maga is tartalmazza.

A dokumentumok digitális aláírása

Az aláírással kapcsolatos információ egy kiegészítő fájlban van nem pedig a manifest.xml -ben

Jelenleg az aláírás folyam a manifest.xml -ben fel van sorolva. Vagy azt jelezte itt, hogy az aláírást nem közvetlenül a manifest.xml tartalmazza?

Érdemes megjegyezni, hogy a META-INF/manifest.xml és a META-INF/documentsignatures.xml maguk nem aláírtak.

A manifest.xml aláírása a terveinkben szerepel az OOo 3.2 -ben. Ne feledje, ez a makrók aláírásának a korlátozását is jelenti, a dokumentum aláírása után már nem lehet a makrókat aláírni, mert ez az addigra már aláírt manifest.xml manipulálását igényelné.

Nem vagyok biztos abban a részben ahol az aláírás aláírásáról van szó. A teljes fájl aláírásáról nem lehetne szó, mivel az újabb aláírásokat is a fájlban kellene tárolni, feltörve az előzőt. További magyarázat/vita szükséges erről.

A digitális aláírás a XML-DSIG előírástól függ. Ugyanakkor, ez nem szabványosított az OpenDocument 1.2 változatban (jelen pillanatban nincs több információ mint a hivatkozás az 1.1 változatra)

Ne feledje, a digitális aláírás specifikációja integrálásra került a OpenDocument-v1.2-draft6.odt (September 2007) változatába.  A legújabb változat az ODF 1.2 tervezetből a Committee Draft 01-rev06.

Az aláíráshoz kapcsolódó összes szempont (lásd a cikk 31.oldalán) érdekes lehet minden olyan rosszindulatú programnak, amelyik a memóriában közvetlenül fut, így az aláírást is manipulálni tudja az előállítása során

Igen, ha egy rosszindulatú program fut a rendszerén a memóriában, akkor már a rendszere sérült, és a rendszerben már nem bízhat meg. Elolvashatja mit gondolok az elsődleges fertőzések kérdéséről.

Digitális aláírások a titkosítással kombinálva: az aláírás fájl maga nem titkosított

Több emberrel beszéltem erről a kérdésről. Van előnye és hátránya e fájl titkosításának. Ez a felhasználásról felhasználásra más és más. Végül is ez adatvédelmi kérdés lehet, és ez az én szempontomból nem biztonsági vagy sértetlenségi kérdés.

Aláírás és a makrók: A dokumentum aláírása tartalmazza az összes folyamot, amíg a makró aláírása nem tartalmazza a dokumentum folyamokat. A dokumentum nem védett, ez egy nagy tervezési gyengeség

Ezzel egyáltalán nem értek egyet, ugyanis így kell működnie! A vállaltok egy csomó dolgot bonyolult makrók segítségével oldanak meg. Nagyon gyakran ezeket a makrókat a sablonokba helyezik el. Az emberek ezeket a sablonokat megnyitják, és adatokat visznek be. Ha a makró aláírása tartalmazná a dokumentumot, a makró aláírása érvénytelen lenne abban a pillanatban amikor a felhasználó adatot visz be. A jelenlegi megközelítéssel a makró aláírások végig érvényesek maradnak. Ne feledje, hogy a makró aláírása mást jelent mint a dokumentum aláírása. Ha csak a makró kerül aláírásra, nem pedig a dokumentum, a dokumentum nem fog aláírt dokumentumnak látszani. A makró aláírás bizonyítja, hogy a makró nem került megváltoztatásra, és használható a makró megbízhatósági döntéseknél.

A dokumentum aláírásokkal, amikor az egész dokumentum tartalom aláírásra kerül, aláírásra kerülnek a makrók is. Ez nagy előre lépés az OpenOffice 2.x -hez képest, ahol a makrók nem voltak aláírhatók. Ennek következményeként, a korábban azonosított támadási lehetőségek nem működnek legalábbis közvetlenül

Igen. Az egy rossz döntés volt, hogy csak a dokumentum tartalmát lehetett aláírni a dokumentum aláírással. Most az összes makró folyam (és minden egyéb folyam a zip archívumban, kivéve a META-INF könyvtárat) az aláírás része. Ne feledje ez csak egy sértetlenség ellenőrzés – a dokumentum aláírással aláírt makrók nem ugyan olyanok mint az aláírt makrók.

3. Fejezet – Vírus támadás egyszerű OpenOffice dokumentumon keresztül

Az egyszerű archívum kezelés (zip/unzip programok és szöveg szerkesztők felhasználásával) támadások sorozatára ad lehetőséget. Ha az a célunk, hogy a dokumentum tartalmát magát módosítsuk (a dokumentumban látható szöveget), elviekben elégséges a megfelelő címkékben lévő információt módosítani.

Hát…igen? Nem értem miért kellene emiatt összezavarodni.

Az ODF szabvány egy nyílt szabványként került meghatározásra – nem tartozik egyetlen alkalmazáshoz sem. Ez azt jelenti, hogy bármely alkalmazás használhatja az ODF formátumot. A legtöbb felhasználó az OpenOffice.org -hoz hasonló alkalmazásokat használ az ODF dokumentumok elkészítésére. De teljesen rendben van ha egy ODF/XML parancsköteget használunk, de használhatjuk az ősrégi VI -t is, ahol az ODF struktúráját a szerzőnek kell fejben tartania, mivel a VI csak egy sima szöveg fájl szerkesztő.

Tehát a fent vázolt forgatókönyv teljesen igaz és használható.

A sértetlenség vizsgálat hiányában, a módosítás rejtve marad a felhasználó előtt

Az összes típusú sértetlenség vizsgálat a lenyomatképzők vizsgálatán alapul. Mivel a lenyomatképzők kiszámítása jól dokumentált lesz az ODF -ben, az algoritmusokat sok nyílt szoftver projekt fogja alkalmazni, a káros szoftverkódoknak sem lesz nehezebb észrevétlenül manipulálni a dokumentumot. A lenyomatképzők csak akkor segítenek amikor titkosítani lehet őket – ez az amire jó a digitális aláírás.

A támadó nem deklarált fájlt tud hozzáadni(különösen veszélyes makrót vagy makrókat)

A 3.2 változattól a fájlokat deklarálni kell a manifest.xml -ben, de ez nem sokat változtat a helyzeten. A makrók számár ez nem kérdés, mivel nem aláírtak, így nem lehet bízni bennük/ végrehajtani őket. Az OOo figyelmeztetni fog a dokumentum betöltésekor.

Érdekes ez a rész: „Lehetséges lopott adat beillesztése az OpenOffice.org fájlba” (Mellékes megjegyzés: Miért hivatkoznak sokan az OOo fájlokra?! Kérem ne feledjék, ezek ODF fájlok, és sok ODF képes alkalmazás létezik).

Az igaz, hogy a dokumentum zip tárolójába be tud tenni bármilyen (lopott) tartalmat, de ehhez hasonlóan egy PDF dokumentumhoz is hozzácsatolható ez, aminek esetében senki sem gondolja ezt amikor továbbküldi a fájlt másokhoz. Valószínűleg ugyanez megtehető nagyon sok más fájl formátumnál is.

A kérdés itt – megint nem a fájl formátum vagy az alkalmazás körül forog hanem az, hogy a rendszerén kárt okozó kód fut! Ez a kód bármit megtehet amire a felhasználó jogosult, és még sok sokkal érdekesebb/hatékonyabb támadás elkövethető vele, mint az irodai alkalmazás vezérlése.

Arra a részere, hogy „támadók kicserélhetik a makrókat (makró kicserélése káros makrókra)”

Ahogy korábban írtam – a nem aláírt makrókban nem lehet megbízni/nem szabad futtatni őket.

Bármilyen XML kompatibilis módosítás észrevétlen marad…

Azt hiszem ezt már megválaszoltam…

4. Fejezet – Vírus támadás titkosított OpenOffice dokumentumon keresztül

Be kell vallanom nem értem mit akar a 4.1 fejezet bemutatni. A szöveg nem ismerteti milyen fajta dokumentum/makró módosítás történt a „sikeres estben”. A különbségek amiket felsorolnak (a zip fejléc könyvtár nevei) nem jelentenek semmit az ODF vagy az aláírás szempontjából. Azt feltételezem, hogy valamilyen régi dokumentumot használtak a tesztjük során. Ahogy korábban kijelentettem, néhány ellenőrzés csak az ODF 1.2 formátumú dokumentumokon történik (kompatibilitás megtartása miatt), és az OOo 3.2 -től kezdve tervezzük hasonló ellenőrzések és figyelmeztetések bevezetését a régebbi dokumentumokra is.

Gondoljuk át azt az esetet amikor egy titkosított makrót lecserélünk egy sima (káros) makróra.

Ez a támadás nem működik az OOo 3.0 és az ODF 1.2 dokumentum esetében. Megismétlem – hasonló ellenőrzést lesz az OOo 3.2 -ben a régebbi dokumentumokra is. Elnézést kérek, hogy ezt nem tettük meg a kezdetektől, „csak” dokumentum kompatibilitási szempontból.

5. Fejezet – Vírus támadás digitálisan aláírt OpenOffice dokumentumon keresztül

Mivel a kritikus fájlok nincsenek titkosítva és különösen nincs, a külső digitális aláírási kulcsot és tanúsítványt kezelő(PKI -t használ), drámaian egyszerű hamis X509-es tanúsítványt készíteni és man-in-the-middle (középső ember) támadást végrehajtani

Először is, szeretném tisztázni azt, hogy az OOo csak használja a PKI -t.

Windowson a Microsoft Cryptography API -t használunk, a tanúsítvány kezelés és az egyéb eszközök azonosak azzal amit minden Windows alkalmazás használ. Más platformokon az OOo a NSS -től függ, ami azt jelenti, hogy a tanúsítványok kezelése a Mozilla Thunderbird, Firefox vagy a Mozilla/SeaMonkey -n keresztül történik.

A hivatkozott cikkben példát láthatunk arra, hogy valaki összeszedheti „Alice” személyes adatait valahogyan, és kreál egy saját maga által aláírt tanúsítványt, az adatok többségének felhasználásával, hogy „valódinak” tűnjön. Ez után Bob megkapja a dokumentumot ami úgy néz ki mintha Alice írta volna alá, és Bob nem érti a PKI -t, és hagyja magát becsapni azzal, hogy látja Alice nevét. Nem ellenőrzi le a nyilvános kulcsot…

Azzal egyetértek, hogy valószínűleg nagyon sok ember van aki nem tud sokat a nyilvános kulcsú tanúsítványokról és a PKI -ról. Azt sem értik, hogy a saját aláírású tanúsítványok majdnem semmit sem érnek, és valahogyan le kellene ellenőrizni a nyilvános kulcsot.

Ugyanakkor, jelenleg az OOo 3.0 megmondja a felhasználónak azt, hogy a tanúsítvány érvényességét nem tudta leellenőrizni, ami saját aláírású tanúsítványok esetében mindig így van. Úgy látszik, hogy a cikkben a képernyő képeket az OOo egy régebbi változatával készítették. Az OOo 3.x változatában egy felkiáltójeles jelet mutatna az aláírás jelnél, az állapot sornál és a tanúsítvány dialógus ablaknál.

Képernyő képek arról, hogyan néznek ki az OOo 3.x -ban:

– saját aláírású tanúsítvány használata a dokumentum ablakban
– saját aláírású tanúsítvány használata, aláírási ablak
– saját aláírású tanúsítvány használata, tanúsítvány megtekintése, általános oldal
– saját aláírású tanúsítvány használata, tanúsítvány megtekintése, tanúsítvány útvonala

Figyelje meg a dokumentum nem úgy van megjelölve, hogy „(Aláírt)”, a dokumentum ablak címsorában, és az összes helyen a felkiáltó jeles jel szerepel. Az összes ablak azt mutatja a felhasználónak, hogy az aláírást nem tudta leellenőrizni. A felhasználó tudatában lehet annak, hogy valami nincs rendben.

Ehelyett, csak akkor bízhat meg a tanúsítványban, ha valamilyen tanúsító szervezet aláírta, a gyökér és a közbeeső tanúsítványok is rendelkezésre állnak a rendszerükön.

– jó tanúsítvány használata, dokumentum ablak
– jó tanúsítvány használata, aláírás ablak
– jó tanúsítvány használata, tanúsítvány megtekintése, általános oldal
– jó tanúsítvány használata, tanúsítvány megtekintése, tanúsítvány útvonala

Sokkal megbízhatóbbnak tűnik a felhasználónak, ugye?

6. Fejezet – Összegzés: OpenOffice biztonságának növelése

Az én összegzésem az, hogy az OOo/ODF biztonsága nem látszik olyan rossznak mint ahogy a cikkben leírják.

Az OOo 3.2 -vel a helyzet még inkább javulni fog, ahogy ebben a cikkben több helyen is jeleztem. Ne feledje én bármit is mondhatok nem biztos, hogy minden bekerül a OOo 3.2 változatába. De dolgozunk rajta…

Az az ötlet, hogy hozzunk létre egy speciális OOo változatot („megbízható OOo ”) érdekes, de egy szigetet képezne. Ez a speciális változat mindig figyelmeztetne ha a sima OOo -ban vagy ODF alkalmazásban készült/módosított dokumentumot nyitna meg. A dokumentumban lévő kiegészítő információ mindig elveszne, ha egy másik alkalmazásban kerülne szerkesztésre.

Azzal kapcsolatban pedig, hogy a rendszergazdáknak tegyük lehetővé a biztonsági beállítások módosítását, ez most is lehetséges. Változtassa meg az telepítési konfigurációt az igényinek megfelelően, és jelölje meg a konfigurációs egyedet mint végleges. Ekkor a felhasználó nem tudja megváltoztatni a felhasználói felületen keresztül vagy XML módosítással, de ehhez biztosítani kell azt is, hogy a normál felhasználóknak ne legyen írási joguk az OOo telepítési helyéhez.

Azt gondolom, hogy nem kell kommentálni az „OOo egy (biztonsággal kapcsolatos) részének zárttá tételét”. Ez nem opció, a zárt kódú szoftver elleni támadás csak bonyolultabb, de nem lehetetlen.
Véleményeket várok…

Fordítói megjegyzések:

A hash – “lenyomatképző” elnevezés az ujjlenyomat analógiájára keletkezett.

self-signed certificate – saját aláírású tanúsítvány

stream – folyam