Zoom-annotációs hibák: egy résztvevő átveheti mások kliensének irányítását

enlightened Ez az oldal a közösségért készül. heart Kövess minket máshol is:  Linux Mint Magyar Közösség a Mastodon-on  Telegram csatorna – csak hírek  Beszélgessünk a Telegram – Linux csevegő csoport  Hírek olvasása RSS segítségével  Linux Mint Hivatalos Magyar Közösség a Facebook-on      Linux Mint Baráti Kör a Facebook-on
wink Ha hasznosnak találod, és szeretnéd, hogy folytatódjon, támogasd a munkát Ko-fi vagy Paypal segítségével. laugh

kami911 képe

Aki Zoom-hívásban megosztotta a képernyőjét, átvehette minden néző gépének irányítását, és bármelyik néző átvehette az előadó gépét.

A hiba az annotációs eszközben volt, abban a funkcióban, amely lehetővé teszi, hogy a résztvevők rajzoljanak és írjanak a megosztott képernyőre. Az áldozattól semmi mást nem igényelt, csak azt, hogy bent legyen a meetingben. Nem kellett kattintani, letölteni, jóváhagyni semmit, és a képernyőn sem jelent meg semmi, ami jelezte volna, hogy megtörtént a támadás.

A javítócsomagok nem újak. A kliensoldali javításokat júniusban és júliusban adták ki, nagyjából két hónappal azelőtt, hogy a hibákat nyilvánosságra hozták volna, és a cikk megjelenéséig nem jelentettek visszaélést. A három azonosító egyike sem szerepel a CISA ismert, aktívan kihasznált sebezhetőségeket listázó katalógusában.

A sebezhetőségeket az alábbi verziók zárják le:

  • Zoom Workplace, minden támogatott platformon, 7.1.5 és 7.0.6 előtti verziók a saját ágaikon
  • Zoom Workplace VDI Client Windowsra, 7.0.11 és 6.6.16 előtti verziók
  • Zoom Rooms és Zoom Meeting SDK, minden platformon, 7.1.0 előtti verziók, illetve a harmadik hibánál 7.1.5 előtti verziók

A kutatást az „A Security” végezte, egy izraeli alapítású, támadó-biztonságra fókuszáló startup, amely júniusban lépett ki a rejtett üzemmódból 37 millió dolláros befektetéssel. A cég szerint kevesebb mint egy nap alatt jutottak el a hiba felfedezésétől a működő exploitig, kevesebb mint 20 prompttal, nyilvánosan elérhető AI modelleket használva.

Ezt az állítást a cégen kívül senki sem tudja ellenőrizni: a leírás nem nevez meg egyetlen modellt sem. A gyártó ráadásul alacsonyabb súlyosságúnak minősíti a hibákat, mint a cég, és a három közül az egyiket a saját belső csapatának tulajdonítja.

A Zoom nem közölt technikai részleteket, ezért a belső működésről a cég saját reverse engineering elemzése ad képet. A rajz nem képként megy át a hálózaton. A kliens strukturált objektummá alakítja, majd számlálók sorozataként küldi el az adatmezők előtt, a fogadó pedig ezekre a számlálókra hagyatkozik, hogy eldöntse, mennyit olvasson be.

Az egyik ilyen mező egy fix, 128 bájtos puffert tölt fel anélkül, hogy ellenőrizné, belefér-e az adat. Mivel ez az objektum utolsó mezője, egy túl nagy számláló túlfut a puffer végén, és felülírja a visszatérési címet.

Az teszi lehetővé, hogy egy hibás rajz az egész szobát elérje, hogy hiányzik az ellenőrzés arra, honnan érkezett az üzenet. Minden nézőnek van egy csatornája a megosztó felé, a megosztónak pedig visszafelé, amelyen elvileg csak visszaigazolásoknak kellene menniük.

A kutatók által feltérképezett útvonalakon a dispatcher kiolvassa a vezetékes üzenet típusszámát, és gondolkodás nélkül átadja a megfelelő parsernek, anélkül hogy megnézné, honnan jött az üzenet. A 0x10001 azt jelenti, hogy itt egy objektum; a 0x10002 azt, hogy megkaptam az objektumodat. Ha az elsőt oda küldik, ahová a második való, az áldozat kliense teljes egészében újraépíti az objektumot.

A Zoom a hibákat CVE-2026-53413 (CVSS pontszám: 8,3, buffer túlírás) és CVE-2026-53414 (CVSS pontszám: 6,5, buffer túlolvasás) azonosítóval tartja nyilván, mindkettőt a ZSB-26015 és a ZSB-26016 fedi le, valamint a CVE-2026-53415-öt (CVSS pontszám: 8,3, use-after-free) a ZSB-26017-ben.

A cég mindhárom hibát 9,0-ra értékeli a CVSS 4.0 szerint, ez a pontszám azonban egyik közleményben sem szerepel. A Zoom saját CVE-rekordokat ad ki, és a NIST már nem pontozza újra ezeket automatikusan, így a mostani alacsonyabb értékek valószínűleg maradnak. A gyártói vektorok mindegyike úgy jelöli, hogy felhasználói interakció szükséges, ami nehezen egyeztethető össze a „zero-click” keretezéssel.

A két beszámoló a buffer túlolvasásnál tér el leginkább. A cég szerint a támadók a sértett kliens nem inicializált heap-memóriájából tudtak kinyerni élő kódot és vtable mutatókat – pontosan azt, amire egy címrandomizáció megkerüléséhez szükség van.

A közlemény szerint ugyanaz a hiba lehetővé teheti, hogy egy résztvevő „szolgáltatásmegtagadást idézzen elő”, és a bizalmasságra gyakorolt hatását nullának veszi. A krediteket is megosztják: két közlemény Idan Levcovichot, az A Security szakértőjét nevezi meg, míg a use-after-free hibát tárgyaló bulletin a Zoom Offensive Security csapatát emeli ki, amely a 9,8-as súlyosságú fiókátvételi hibát is felfedezte, amelyet a cég júliusban javított.

A startup bejegyzése mindhárom hibát sajátjaként sorolja fel, miközben elismeri, hogy a Zoom a harmadikat már ismerte, és a jelentés beérkezése előtt szerveroldalon szűrte. Az MI-vel végzett munka leírása is jóval kuszább, mint a saját összefoglalójuk.

Az első körben egy automatizált rangsorolás futott, amely a Java rétegből elérhető függvényeket sorba rendezte. Így 3762 függvényből álló sort kaptak 70 library-ben, és a sebezhető library-t teljesen kihagyták, a 45. helyre sorolták. Csak akkor bukkant elő, amikor egy élő hívás közben, funkcióról funkcióra végigkövették a futó klienst. Levcovich szerint az ilyen jellegű exploitok felépítésének akadálya „összeomlott, és nem fog visszatérni”.

A nyilvánosságra hozatal egy nappal azután történt, hogy az OpenAI kettéválasztotta a Daybreak programját, és a GPT-5.6-Cyber modellt csak előzetesen ellenőrzött partnereknek tette elérhetővé, arra hivatkozva, hogy ezt a képességet korlátozni kell. A startup azt állítja, hogy az eredményt bárki által használható modellekkel érte el. Az OpenAI saját mérése szerint a korlátozott, nyilvános modell a fejlett támadó-biztonsági kérdések 1,5 százalékára válaszol, míg a zárt modell 95 százalékukra.