Responsible Disclosure

Nem tudom, mi a magyar "köznyelvben" elfogadott fordítása ennek a biztonsági fogalomnak, talán felelősségteljes közzététel lehetne, de elég hülyén hangzik... Mindenesetre már érett bennem egy ideje a gondolat, hogy írok róla néhány sort, de most nyilvánosságra került egy eset, ami megadta a végső lökést. Előre bocsátom: nem foglalok állást az ügyben, mert nem is könnyű. Természetesen kitérek némi elméleti információra is, hogy jobban megismertessem az olvasóimat néhány alap fogalommal.

Microsoft és Google

A Google-nek mostanság elég sok dolga akad a Chrome foltozását illetően, az elmúlt időszakban meglehetősen sok biztonsági hibát kellett javítaniuk a saját böngészőjükben, ezek között akadt néhány komolyabb is. A Microsoft mindeközben Windows 10 frissítésekkel jön, amikkel kapcsolatban az az érzésem, hogy már maguk sem tudják, milyen új funkciókat adjanak hozzá a rendszerhez - én mondjuk jobban örülnék olyanoknak, mint például a Vezérlőpult és a Gépház végleges egyesítése, esetleg beérném azzal is, ha az általam szándékosan letiltott Intel HD 630-as grafikus lassítót nem aktiválná újra a kifejezett kérésem nélkül - szóval apróságokkal. Az utóbbi időben egyébként mintha enyhült volna a korábbi feszültség a két óriás között - lehet, hogy a Google úgy döntött, ideje egy kis hangulatot csinálni.

Böngészőből admin hozzáférés

Szerintem a fenti három szóra minden online rosszfiú megnyalja az ujját. A Chrome legutóbbi frissítésében a Google orvosolt egy hibát a Free Type 2 könyvtárban (CVE-2020-15999), ami puffer túlcsordulást okozhatott megfelelően preparált fontok használata esetén (pl. a támadó ilyen web oldalra csalja az áldozatot). Ugyanakkor a Windows kernel kriptográfiai meghajtójában is van egy túlcsordulásos hiba (CVE-2020-17087), a kettőt együtt kihasználva ki lehet törni a Chrome sandboxból, ahonnan további egyéb hibákat kihasználva admin jogosultsághoz juthat a támadó. A Google Project Zero jelentette a hibát a Microsoftnak a múlt héten, ugyanakor elvárták, hogy a soron következő patch kedd alkalmával - november 10 - a javítást kiadják a redmondiak. A hiba a Windows 7-től kezdődően minden Windows rendszerben jelen van. Nem egészen világos, ezután miért döntött úgy a Google, hogy nyilvánosságra hozza a hibát (full disclosure), hiszen a patch kedd pont egy hétre van mostantól számítva. Mindezzel egy időben a Google az is közzé tette, hogy megfigyeléseik szerint a hibát már aktívan kihasználják, tehát nem a 90 napos, hanem a 7 napos nyilvánosságra hozatal a megfelelő közlési forma a nagyközönség számára (a Microsoftot a múlt héten értesítették, a 7 nap tegnap járt le). A mérleg másik oldalán szerepel, hogy a Chrome már patchelve van, így már a fenti hibák együttesen nem használhatók ki. A Microsoft úgy véli, a Google felelőtlenül hozta nyilvánosságra a hiba részleteit a 7 napos határidő lejárta után, a hibákat együttesen pedig nagyon marginálisan használják ki támadók.

Pro és kontra sokáig lehetne ezen vitatkozni, de nem kívánok ezügyben semmiféle állást foglalni, mert azt gondolom, hogy mindkét oldal hibázott.

Közzététel

Az információbiztonsági iparágban jelenleg nem nagyon vannak szabványok, inkább csak hallgatólagos megegyezések, kvázi-szabványok az alkalmazás-hibákra vonatkozóan. Ilyen a Google által kitalált 90 napos responsible disclosure is. Mielőtt ők színre léptek volna, senki semmihez nem tartotta magát. A különböző cégek magasról fütyültek a bejelentett - akár súlyos - hibákra, de hajlamosak voltak beperelni a részletek megszellőztetőit még akár több éves (!) hibák esetén is. Más esetekben a korábban már említett Cylance-esethez ("Játékos AI") hasonlóan a gyártók esélyt sem kaptak arra, hogy kijavítsák a súlyosabb hibákat.

Ennek vetett véget a Google, amikor bevezette a 90, illetve 7 napos határidőket. Előbbi azokra a biztonsági hibákra vonatkozik, amiket nem használnak ki aktívan, utóbbi - mint a fenti példa is mutatja - a sürgősnek tűnő esetekre. Legfőképpen a 90 napos határidő lett olyan, amit az iparág szereplői elfogadtak és törekszenek a betartására és itt lehetőség is van még egy 90 napos időtartamra, ha valamilyen ok miatt a javítást nem lehet elkészíteni az első 3 hónapban. Még egyszer: semmi nem kötelez senkit ezeknek a betartására, ugyanakkor érdemes még egyéb szempontokat is mérlegelni. Új típusú hibákat lehet felfedezni, amelyek kijavítása talán nem triviális és a javítási folyamat sok erőforrást is felemészthet.

Hogyan csináljuk?

Először is mindenképpen ajánlott a törvényi rendelkezésekkel tisztában lenni. Vannak országok, ahol már a portscan is ütközik a szabályokkal, más helyeken addig el lehet menni külön engedély nélkül, ameddig nem okozunk kárt. Utóbbi szabályzás a maga megengedőbb formájában szerintem üdvözlendő és végeredményben win-win helyzetet teremt: a cégek tudni fognak a hibákról, a biztonsági szakemberek pedig frissen tarthatják a tudásukat, esetleg némi zsebpénzt - ritkább esetekben komolyabb összeget - is nyerhetnek vele, esetleg CV-ben jól mutathat, ha ilyen segítséget nyújtanak.

A következő fontos momentum az, hogyan juttassuk el a talált hibákat a céghez? Sok, de nem minden vállakozás web oldalán található responsible disclosure kapcsolat. Tartsuk észben, hogy a sima email nem titkosított, így egy ilyen formában beküldött jelentést akár full disclosure-nek is tekinthet az adott szervezet és esetleg beperelik a kutatót. Próbáljunk meg találni például publikus kulcsot, amellyel titkosíthatjuk a mondandónkat és csak a személyes kulcs birtokában lehet ismét olvashatóvá tenni. Ha ilyen nincs, telefonon, emailen keresztül kérjünk segítséget az adott szervezettől - nekik is érdekük a hibák kijavítása, segíteni fognak.

Miért is tartottam fontosnak ezt az utolsó paragrafust leírni? Az iparágban tevékenykedőként napi szinten látom, hogy a szabványok és szabályok hiánya mennyire hátráltathat minden résztvevőt, így terjeszteni a megfelelő információt nem árthat.

2020.11.03.
CoreSec