Openoffice.org 3.2 biztonsága

Az OpenOffice.org 3.2-re frissítés nem csak a bejelentésben részletezett újdonságok és a teljesítményjavulás miatt javasolt, hanem javított biztonsági hibák és a biztonsági változtatások miatt is.

Az OpenOffice.org 3.2-ben javított biztonsági hibák:

• CVE-2006-4339: Potenciális sebezhetőség harmadik féltől való libxml2 könyvtáraktól
• CVE-2009-0217: Potenciális sebezhetőség harmadik féltől való libxmlsec könyvtáraktól
• CVE-2009-2493: OpenOffice.org 3 Windows változata az MSVC sebezhető változatát tartalmazta
• CVE-2009-2949: Potenciális sebezhetőség XPM fájl feldolgozással kapcsolatban
• CVE-2009-2950: Potenciális sebezhetőség GIF fájl feldolgozással kapcsolatban
• CVE-2009-3301/2: Potenciális sebezhetőség MS-Word dokumentum feldolgozással kapcsolatban

OpenOffice.org 3.2 biztonsági és személyes adatbiztonsági fejlesztései

Az OOo biztonságáról már volt szó egy korábbi hozzászólásban: http://www.openoffice.hu/2009/05/ooo_biztonsaga/.

Abban megtárgyalásra került néhány kérdés amely közvetlenül tisztázásra került, de volt néhány terület amelyről Malte Timmermann, az OOo biztonsági projekt vezetője azt ígérte, hogy az OOo 3.2-ben kerül sor a szükséges módosításokra, és ez meg is történt. Alább található szöveg a blogbejegyzés fordítása.

A korábbi hozzászólásban felsorolt szükségesnek ítélt fejlesztések

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

Az OOo 3.2-ben nem lehet hozzáadni nem titkosított makrófolyamot, vagy a meglévőt lecserélni egy másik nem titkosítottra.

A kompatibilitás megtartása miatt ez az ellenőrzés csak az ODF 1.2 változatú dokumentumokra vonatkozik, amelyeket az OOo 3.0 vagy újabb változatával készítettek. De az OOo nem egyedül a manifest.xml tartalmától függő ellenőrzést végez, hanem leellenőrzi a titkosított content.xml változatát is, így a dokumentumot manipuláló felhasználó nem tudja az ellenőrzést kikerülni az alacsonyabb számú ODF formátum használatával a manifest.xml-ben.

Továbbra is van lehetőség a makrófolyam teljes eltávolítására, mert a manifest.xml továbbra sem védett. Ennek védetté tételéhez az ODF 1.2 további módosítására lesz szükség, mivel nem akarunk csak az OOo által kezelt titkosítást készíteni.

Más kérdés a titkosított makrófolyamok beillesztése, de ennek nincs hatása. Az ok, amiért különböző aláírású makrók lehetnek, hogy a felhasználó minden makrókönyvtárt külön-külön jelszóval védhet. A titkosított makrófolyam hozzáadásával nem érhető el semmi, az OOo nem tudja a titkosítást feloldani, és nem regisztrálódnak a Basic könyvtárban, mert az a fájl is titkosított.

A megmaradt (valószínűleg nem olyan fontos) probléma esetében, ahol a titkosított dokumentumból eltávolítható a makrófolyam, különböző lehetőségeket kell kiértékelni. Az egyik lehet a manifest.xml védelme valamilyen aláírási algoritmuson keresztül, vagy a teljes ODF zip-folyam titkosítása. Az utóbbi esetben az ODF konténerbe lehet a folyamot csomagolni, így a mimetime-folyam rendelkezésre állhat a rendszerintegrálásra, és tárolhatja, hogy mely titkosítás került alkalmazásra.

Ennek kifejtésére ez a hozzászólás nem alkalmas, ha a részletek érdeklik, és dolgozni kíván a megoldásán, csatlakozzon az OOo Biztonsági projektjéhez, az ötleteket a biztonsági levelezési listán vitassák meg, ahova előzetesen fel kell iratkozni, mivel a válaszokat általában csak a listára küldik meg.

Probléma: Meg kell jegyezni, hogy a META-INF/manifest.xml és a META-INF/documentsignatures.xml önmagukban nem aláírtak

Az ODF 1.2 specifikáció módosításra került (ez az első változat ahol a digitális aláírás említésre kerül). A dokumentum aláírások fogalmának meghatározása, kijelenti, hogy az ODF csomag összes folyama, beleértve a manifest.xml-t is a dokumentum aláírásnak le kell fednie. Az egyetlen kivétel az aláírási folyam, amely kihagyható.

Az OOo 3.2-ben a manifest.xml a dokumentum aláírás része.

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

Ahogy az az eredeti hozzászólásban is szerepelt, ez nem nagyon változtatja meg a biztonságot, attól függetlenül, hogy a manifest.xml-ben szerepel-e vagy sem, ugyan is a manifest.xml amúgy is könnyen frissíthető.

De mivel az egy jó módszer, hogy minden fájl deklarálva legyen a manifest.xml-ben, az OOo 3.2 ellenőrzi ezt az ODF 1.2 dokumentumok esetében.

Mivel a régebbi változatú OOo-ok rögzítették az összes fájlt a manifest.xml-ben, megvitatásra érdemes az összes régebbi változatú dokumentum ellenőrzésének kérdése.

Probléma: Gondoljuk át azt az esetet ha egy titkosított makró lecserélésre kerül egy nem titkosított egyszerű szöveg (veszélyes) makróval.

Az első problémánál fentebb megbeszéltük, az OOo nem fogadja el a nem titkosított folyamokat a titkosított dokumentumokban, a dokumentum ODF változattól függetlenül.

További fejlesztések az OOo 3.2-ben és az ODF 1.2 specifikációban.

ODF 1.2 már lehetővé teszi különböző titkosítási algoritmusok alkalmazását, és manifest.xml-ben minden részletet a felhasznált algoritmusokkal kapcsolatban dokumentálni kell(ez az oka annak, hogy a manifest.xml nem titkosítható). Ezek az ODF módosítási javaslatok, benyújtásra kerültek az OASIS ODF műszaki bizottságához, és az OOo 3.2-ben bevezetésre kerültek. Ez csak annyit jelent, hogy az OOo az összes szükséges információt a manifest.xml-be helyezi. Nem azt jelenti, hogy az OOo új beépített titkosító algoritmust tartalmaz.

A részletekért, és a biztonsággal kapcsolatos további információkért keresse fel az OOo Biztonsági projekt wikioldalát.