Google a lansat un update important pentru Chrome după ce a descoperit o breșă folosită deja în atacuri
Google a publicat pe 11 decembrie 2025 un pachet de actualizări de securitate pentru browserul Chrome, care corectează trei probleme, dintre care una este deja exploatată „în sălbăticie” (adică în atacuri reale, nu doar în laborator). Particularitatea acestui caz este că Google a ales să nu dezvăluie public nici identificatorul CVE, nici componenta exact afectată, nici modul concret în care poate fi exploatată vulnerabilitatea, invocând faptul că informațiile sunt „în coordonare” și că divulgarea prea devreme ar crește riscul ca și alți atacatori să copieze tehnica.
Deși compania a limitat comunicarea oficială, indicii dintr-un commit public asociat bug-ului din Chromium sugerează că problema ar fi în biblioteca open-source ANGLE (Almost Native Graphics Layer Engine), mai precis în rendererul Metal. Pentru utilizatori, mesajul important este simplu: există un exploit activ, iar actualizarea imediată a browserului reduce semnificativ riscul.
Ce se știe despre vulnerabilitate și de ce contează componenta ANGLE
Vulnerabilitatea urmărită în Chromium sub ID-ul 466192044 este clasificată de Google drept „high severity” și este confirmată ca fiind exploatată activ. În mod obișnuit, în astfel de situații, producătorii oferă un CVE și un rezumat tehnic, însă aici compania a ales o comunicare minimală. Asta nu înseamnă că problema este mică, ci dimpotrivă: discreția este o strategie frecventă atunci când există atacuri în desfășurare și se dorește câștigarea de timp pentru ca actualizările să ajungă la cât mai mulți utilizatori.
Totuși, un commit vizibil public a indicat o zonă posibilă: ANGLE, un strat de compatibilitate grafică folosit pentru a traduce apeluri grafice (de tip OpenGL ES) către API-uri native (precum Metal pe macOS). Mesajul commit-ului menționează explicit o problemă de dimensionare a bufferelor: „Metal: Don’t use pixelsDepthPitch to size buffers. pixelsDepthPitch is based on GL_UNPACK_IMAGE_HEIGHT, which can be smaller than the image height.” Pe românește, un parametru folosit la dimensionarea bufferului poate fi mai mic decât înălțimea reală a imaginii, ceea ce deschide ușa unor erori de memorie.
Dacă această interpretare este corectă, scenariul tehnic plauzibil este un buffer overflow (sau o problemă înrudită) în care datele ajung să scrie dincolo de limitele alocate. Consecințele tipice pentru astfel de defecte sunt coruperea memoriei, blocarea aplicației și, în cazurile cele mai grave, execuție de cod arbitrar. Într-un browser, o astfel de breșă poate deveni un „cap de pod” pentru a rula cod malițios în contextul proceselor browserului, mai ales dacă atacul este combinat cu alte vulnerabilități.
De ce Google nu publică încă CVE-ul și ce înseamnă „exploatat în sălbăticie”
Când un producător spune că „este conștient că există un exploit în sălbăticie”, mesajul este mai serios decât pare. Înseamnă că cineva a transformat vulnerabilitatea într-un instrument de atac folosit împotriva unor ținte reale. În astfel de cazuri, fiecare detaliu tehnic public poate ajuta atacatorii să reproducă exploitul mai repede, să-l adapteze și să îl scaleze către și mai multe victime.
De aceea, amânarea publicării CVE-ului și a explicațiilor detaliate este, de multe ori, un compromis: utilizatorii trebuie să primească patch-ul rapid, iar adversarii nu trebuie să primească „manualul de utilizare” al vulnerabilității. Practic, se încearcă obținerea unui avantaj defensiv: cât mai multe sisteme actualizate înainte ca informațiile să devină suficiente pentru a fi imitate în masă.
Mai există un motiv pragmatic: patch-urile pot fi „reverse engineered”. Dacă apare o actualizare și se publică imediat detalii tehnice complete, un atacator poate compara versiunile și poate reconstrui cauza exactă, dezvoltând rapid exploituri pentru utilizatorii care nu au actualizat încă. Iar în lumea reală, „nu am apucat să dau update” este una dintre cele mai comune cauze pentru incidente majore.
În 2025, Google a ajuns deja la opt vulnerabilități de tip zero-day în Chrome care fie au fost exploatate activ, fie au fost demonstrate ca proof-of-concept. Această frecvență nu înseamnă neapărat că Chrome este „mai slab” decât alternativele, ci că browserul este o țintă uriașă, că suprafața de atac este complexă (motor JS, sandboxing, renderere grafice, extensii, codec-uri) și că raportarea/monitorizarea este intensă.
Ce versiuni rezolvă problema și de ce contează și pentru Edge, Brave sau Opera
Actualizarea recomandată aduce Chrome la versiunile 143.0.7499.109/143.0.7499.110 pentru Windows și macOS, respectiv 143.0.7499.109 pentru Linux. Ca să verifici rapid dacă ești la zi, intră în meniul Chrome, apoi la „Ajutor” și „Despre Google Chrome”; browserul verifică și descarcă automat update-ul, iar la final îți cere o repornire („Relaunch”) ca să activeze patch-ul. Diferența dintre „am descărcat” și „am repornit” contează: vulnerabilitatea rămâne, de regulă, exploatabilă până când procesele vechi sunt închise.
În același pachet, Google a remediat și două vulnerabilități de severitate medie: una de tip use-after-free în Password Manager și una legată de o implementare nepotrivită în Toolbar. Chiar dacă accentul mediatic cade pe „exploitat activ”, aceste defecte „medium” merită luate în serios, fiindcă pot deveni componente într-un lanț de atac (de exemplu, una ajută la stabilitate, alta la ocolirea unor protecții).
Foarte important: dacă folosești un browser bazat pe Chromium (Microsoft Edge, Brave, Opera, Vivaldi), nu ești automat „în afara problemei”. Deși fiecare vendor are propriul calendar de livrare a update-urilor, baza de cod și componentele comune pot însemna că fixul trebuie preluat și distribuit și acolo. Diferența e doar de ritm: unele aplicații primesc patch-ul la ore, altele la zile. În perioade cu exploit activ, această fereastră de timp devine exact spațiul în care atacurile pot crește.