Oracle: el a kezekkel a szoftvereinktől!

Tilos az Oracle szoftverek visszafejtése - figyelmeztette a cég ügyfeleit blogbejegyzésében Mary Ann Davidson, az Oracle CISO (biztonságért felelős vezérigazgató). A szürrealitás határát súroló bejegyzést az Oracle alig egy nap után eltávolította, az archivált szöveg azonban jó betekintést nyújt abba, hogyan ítéli meg a vállalat a független biztonsági kutatók tevékenységét illetve a saját ügyfelek által végzett biztonsági vizsgálatokat. Egy szóban: negatívan. Több szóban: tűzzel-vassal irtaná.

A bejegyzés lényege, hogy Davidson felhívta az Oracle licenccel rendelkező vásárlóinak figyelmét, hogy a szoftverek visszafejtése a licencfeltételekbe ütközik, így kimondottan tilos ilyen tevékenységet végezni - még akkor is, ha ezt kizárólag biztonsági szempontok indokolják. A bejegyzés szerint a "reverse engineering" minden olyan tevékenységet takar, amely a szoftver működését igyekszik feltérképezni, többek között a forráskód visszaállítására tett próbálkozást, a deobfuszkációt, de ide tartozik a szoftverkomponensek közötti kommunikáció vizsgálata is. Ezekre a tevékenységekre általában szükség van, ha a biztonsági szakértő szeretné pontosan megérteni a szoftver működését és feltérképezni a potenciális hibákat.

Az Oracle szerint azonban erre a licencfeltételek nem adnak lehetőséget, sőt, kifejezetten tiltják azt. Még abban az esetben is, ha a vizsgálatot kizárólag biztonsági szakemberek végzik és annak célja a szoftverek hibáinak elemzése. A cég a tiltást azzal indokolja, hogy a forráskód "nagyon értékes szellemi tulajdon", amelyet az Oracle védelmezni kíván.

Csak a támadók fejthetnek vissza?

Az Oracle tehát azt követeli a vásárlóitól, hogy a cég által fejlesztett szoftverekben bízzanak meg vakon, azt ne teszteljék és ne fejtsék vissza. Ezek a korlátozások természetesen csak a szoftverlicenccel rendelkezőkre vonatkoznak, a potenciális támadókat nyilvánvalóan nem a licencfeltételek fogják majd eltántorítani attól, hogy biztonsági réseket keressenek az Oracle szoftvereiben.

Ez keltett egységes megütközést a szakmai berkekben, a rosszindulatú támadók számára ugyanis nyilván adott a lehetőség a szoftverek tetszőleges mélységű boncolgatására, ennek csak a szakmai kompetencia szab gátat. Ugyanezt a lehetőséget azonban az Oracle megtagadná a "jófiúktól", az elismert kutatóktól és biztonsági szolgáltatást nyújtó cégektől is, a licencfeltételekre való hivatkozással.

Van benne jogos kritika is

Davidson hosszú bekezdésekben ecsetelte, hogy a részlegének (és személyesen neki) mennyire elege van már a teljesen használhatatlan biztonsági visszajelzésekből - és ebben nagy valószínűséggel igaza van. A biztonsági szakmát ugyanis ugyanúgy fertőzi az amatőrök és sarlatánok serege, mint minden más szakmát, ennek egyik jele pedig az automatizált penetrációs tesztekben mutatkozik meg.

Kis kitérő: a biztonsági audit sok iparágban kötelező (vagy erősen ajánlott), így stabil piaca van az etikus hackelésnek, vagyis a vállalati rendszerek tesztelésének. Ennek egyik eszköze az automatizált szkennelés/pentest, amely (a felhasznált szoftver képességeitől függően) végigmegy a különböző szóba jöhető hibákon és mindegyikre végrehajtja a tesztet. Az ilyen tesztelés eredménye jellemzően egy rendkívül hosszú lista, amely a milliónyi teszt eredményét sorolja. A szakértő feladata a lista feldolgozása, az eredmények leszűkítése a releváns találatokra, és természetesen annak kiegészítése saját tesztekkel, manuális, az adott rendszerre szabott penetrációs vizsgálatokkal, stb. Itt jönnek a képbe a sarlatánok, akik ezeket a lépéseket kompetencia hiányában már képtelenek elvégezni, helyette az egységsugarú automatizált teszt eredményét adják be szakértői véleményként - dolgozza azt fel a megrendelő.

Ünnepi mix a bértranszparenciától a kódoló vezetőkig Négy IT karrierrel kapcsolatos, érdekes témát csomagoltunk a karácsonyfa alá.

Ilyenkor ha a megrendelőnél is kevéssé kompetens személyek dolgoznak, akkor a fals pozitív találatoktól hemzsegő "hibalistát" átnyújtják a beszállítónak (esetünkben az Oracle), és elvárják a nem létező hibák kijavítását. Abban pedig igaza van Davidsonnak, hogy ez egy mélyen problémás, és terjedő iparági gyakorlat - abban viszont téved, hogy ezt a licencfeltételek szigorú kikényszerítése fogja majd megoldani.

Hiszti törölve

A bejegyzés előbb értetlenséget és egységes felháborodást keltett az IT-biztonsági szakma köreiben (érdemes Twitteren a #oraclefanfic hashtagre rápillantani), az Oracle álláspontját egyöntetűen nevetségesnek tartotta mindenki. A reakciót észlelve az Oracle gyorsan törölte a bejegyzést és közleményben igyekezett elhatárolódni az ott leírtaktól. "Termékeink és szolgáltatásaink biztonsága mindig kritikus fontosságú volt az Oracle számára. Az Oracle jelentős termékbiztonsági programot működtet és együtt működik külső kutatókkal és vásárlókkal, hogy együtt biztosítsák az Oracle technológiák biztonságát. A bejegyzést eltávolítottuk, mivel az nem tükrözi értékeinket és a vásárlóinkkal kialakított kapcsolatunkat."

Az eltávolítás így ha lehet, még meglepőbb, mint maga az eredeti bejegyzés. A termékek biztonságáért, a külső kutatókkal való együttműködésért és általában a vásárlóktól érkező, a biztonsággal kapcsolatos visszajelzések kezeléséért ugyanis pontosan a Davidson által vezetett szervezeti egység felel. Ha Davidson a bejegyzésben felszínre került nézeteket vallja, akkor felmerül a kérdés, hogy az Oracle hogyan képzeli el e részleg hosszabb távú működését ezzel a biztonsági igazgatóval.

Davidson ugyanis nem először vallott visszatetszést keltő nézeteiről. A Heartbleed és a többi "márkázott sebezhetőség" kapcsán írta, hogy ragaszkodjunk csak a CVSS (common vulnerability scoring system) használatához, a sajtót ugyanis a sebezhetőségek "marketingje" teljesen félrevezeti. Ha ehhez hozzávesszük, hogy a szakmában széles körben elfogadott nézet, hogy az Oracle évek óta aktívan manipulálja a sebezhetőségek CVSS pontszámát, akkor érthető, hogy miért számít igencsak megosztónak Davidson - és vele az Oracle hozzáállása az informatikai biztonsághoz.

És akkor még egy szót sem szóltunk a Javáról.