Chrome 142: aktualizacja bezpieczeństwa łata 5 podatności (3 „High”), w tym WebGPU (CVE-2025-12725)

Wprowadzenie do problemu / definicja luki

Google wydało poprawkę bezpieczeństwa dla Chrome 142 usuwającą 5 podatności, z czego 3 mają wagę High. Najpoważniejsza z nich to błąd zapisu poza bufor (out-of-bounds write) w WebGPU – CVE-2025-12725, potencjalnie umożliwiający zdalne wykonanie kodu (RCE). Dodatkowo naprawiono błędy „inappropriate implementation” w Views (CVE-2025-12726) i V8 (CVE-2025-12727) oraz dwie usterki średniej wagi w Omnibox (CVE-2025-12728, CVE-2025-12729). Google nie raportuje na ten moment aktywnego wykorzystania tych luk. Oficjalne wersje z łatami to m.in. 142.0.7444.134/.135 dla Windows/Mac/Linux.

---

W skrócie

• Zakres: 5 luk (3×High: WebGPU, Views, V8; 2×Medium: Omnibox).
• Warianty wersji z poprawką: Windows/Mac 142.0.7444.134/.135, Linux 142.0.7444.134; rollout etapowy.
• Eksploatacja „in the wild”: brak potwierdzenia.
• Ryzyko praktyczne: możliwe RCE (WebGPU, V8), korupcja pamięci/stanów UI (Views), manipulacje paskiem adresu i scenariusze phishingowe (Omnibox).
• Dla kogo priorytet: SOC/IT z dużym udziałem przeglądarki w łańcuchu pracy (SaaS, VDI, SSO, EDR w konsoli web), środowiska z WebGPU/AI w przeglądarce oraz parkiem rozszerzeń.

---

Kontekst / historia / powiązania

Chrome 142 został ogłoszony jako stabilny 28 października 2025 r., a kilka dni później wydano aktualizację stricte bezpieczeństwa dla desktopów ze zredukowanymi szczegółami do czasu, aż większość użytkowników się zaktualizuje (standardowa polityka). Wpis zespołu Chromium podaje listę CVE i numery wersji kanału stabilnego.

---

Analiza techniczna / szczegóły luki

1) WebGPU — CVE-2025-12725 (High, OOB write → RCE)

• Natura błędu: out-of-bounds write w implementacji WebGPU (warstwa umożliwiająca stronom dostęp do GPU). Tego typu usterki to klasyczna korupcja pamięci — zapis poza przeznaczonym obszarem może prowadzić do crasha lub dowolnego wykonania kodu przy odpowiednio spreparowanych shaderach/buforach.
• Implikacje praktyczne: złośliwe strony/aplikacje webowe uruchamiające obciążenia GPU (np. wizualizacje 3D/AI) mogą próbować eskalować błąd do RCE w procesie renderera; potencjalnie do piaskownicy, ale łańcuchy „renderer → browser” są znane z wcześniejszych kampanii. (Implikacja na bazie typologii błędu w Chrome i modelu procesów.)

2) Views — CVE-2025-12726 (High)

• Opis: „inappropriate implementation” w frameworku Views (warstwa UI Chrome), niebezpieczne obchodzenie się z referencjami obiektów UI → możliwość korupcji pamięci po odwiedzeniu spreparowanej strony lub poprzez rozszerzenie.

3) V8 — CVE-2025-12727 (High)

• Opis: błąd „inappropriate implementation” w silniku V8 (JS/WebAssembly). Tego rodzaju defekty (np. type confusion, błędy pamięci) są historycznie atrakcyjne do RCE przez skrypty na stronie.

4–5) Omnibox — CVE-2025-12728, CVE-2025-12729 (Medium)

• Opis: „inappropriate implementation” w Omnibox (pasek adresu). Skutki to m.in. nadużycia UI lub błędne odwzorowanie danych, co w praktyce zwiększa ryzyko phishingu/redirectów i ataków „tapjacking”/„clickjacking” w interakcji z paskiem.

Tabela szybkiego mapowania (CVE → komponent → poziom):
CVE-2025-12725 (WebGPU, High), CVE-2025-12726 (Views, High), CVE-2025-12727 (V8, High), CVE-2025-12728 (Omnibox, Medium), CVE-2025-12729 (Omnibox, Medium).

---

Praktyczne konsekwencje / ryzyko

• Atak RCE z poziomu strony: kombinacje luk WebGPU/V8 mogą umożliwić uruchomienie kodu w procesie renderera i potencjalny sandbox escape przy dodatkowych błędach (łańcuchy exploitów).
• Manipulacja interfejsem i socjotechnika: błędy Omnibox podnoszą skuteczność kampanii phishingowych (maskowanie adresów, nieoczekiwane autouzupełnianie, przekierowania).
• Ryzyko dla środowisk korporacyjnych: przeglądarka to największa powierzchnia ataku w organizacji; wiele zakładek/aktywnych skryptów zwiększa ekspozycję — stąd presja na szybkie wdrożenia poprawek.

---

Rekomendacje operacyjne / co zrobić teraz

1) Szybki update użytkownika końcowego

• Ręcznie (GUI): Ustawienia → Informacje → Google Chrome (sprawdzenie/instalacja, restart).
• Windows (Winget, CMD/PowerShell jako admin): winget upgrade --id Google.Chrome --source winget $v = (Get-Item "C:\Program Files\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion Write-Host "Zainstalowana wersja Chrome: $v"
• macOS (Homebrew): brew update && brew upgrade --cask google-chrome /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --version
• Linux (Debian/Ubuntu repo Google): sudo apt update && sudo apt install --only-upgrade google-chrome-stable google-chrome --version

Wersje docelowe: 142.0.7444.134/.135 (w zależności od OS, rollout etapowy).

2) Zarządzanie w organizacji (MDM/Intune/GPO)

• Wymuś auto-update i restart przeglądarki:
  • GPO (Windows): wgraj najnowsze Chrome ADMX, ustaw:
    • Automatic Browser Updates Enabled = Enabled
    • Target version prefix = 142 (opcjonalnie, aby wymusić min. 142)
    • ComponentUpdatesEnabled = Enabled
    • RelaunchNotification = Required / deadline (np. 24h)
• Microsoft Intune (Windows/macOS): profil konfiguracyjny z politykami Chrome; ustaw deadline na restart (np. 24–48 h) i Grace Period dla użytkownika.
• macOS (Jamf/Munki/MDM): Payload z com.google.Keystone (auto-update), polityka wymuszająca relaunch po instalacji.
• Linux (fleet): repo Google + „pin” wersji, zadanie cron/systemd na aktualizację dzienną.

3) Kontrola zgodności (detekcja niezałatanych hostów)

• Skany bezpieczeństwa/Nessus/Qualys: użyj wtyczek/QL odpowiadających Chrome 142 (dla macOS/Windows). Przykładowo, Tenable identyfikuje podatność <142.0.7444.135.
• Szybki skrypt inwentarzowy (Windows/PSRemoting): $computers = Get-Content .\workstations.txt Invoke-Command -ComputerName $computers -ScriptBlock { $p = "C:\Program Files\Google\Chrome\Application\chrome.exe" if (Test-Path $p) { (Get-Item $p).VersionInfo.ProductVersion } else { "Brak Chrome" } }
• EDR/NDR: stwórz reguły detekcyjne na artefakty exploitów przeglądarkowych (crashe renderera, nieoczekiwane procesy child od Chrome).

4) Hardening przeglądarki (szczególnie do czasu pełnej adopcji)

• Wyłącz WebGPU w środowiskach o podwyższonym ryzyku (tymczasowo): chrome://flags → Disable WebGPU lub polityka HardwareAccelerationModeEnabled = False (koszt: UX/perf).
• Ogranicz rozszerzenia: allow-list, audyt uprawnień, blokada developer mode.
• Zasady izolacji: włącz Site Isolation / Strict Origin Isolation dla aplikacji krytycznych.
• Zachowania Omnibox: rozważ wyłączenie sugestii i autouzupełniania w stacjach o podwyższonym ryzyku (polityki Omnibox).

---

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

• Brak zero-day w tej fali (w odróżnieniu od poprzednich wydań z 2025 r., gdzie V8 bywał wykorzystywany „in the wild”). Obecna łatka dotyczy nowych CVE w 142 i nie ma wzmianki o aktywnej eksploatacji.
• Komponenty: ponownie widzimy mieszankę błędów pamięci (WebGPU/V8) i błędów implementacyjnych UI (Views/Omnibox), co odpowiada trendom w złożonych przeglądarkach (warstwy grafiki + interfejs).

---

Podsumowanie / kluczowe wnioski

• Zaktualizuj Chrome do 142.0.7444.134/.135 jak najszybciej; zdefiniuj deadline i wymuszony relaunch.
• Monitoruj zgodność — hosty poniżej 142.0.7444.134/.135 są podatne; skanuj i raportuj odsetek niezałatanych.
• Zarządzaj ryzykiem WebGPU/Omnibox (tymczasowe wyłączenia/ograniczenia), szczególnie w stacjach z wysoką ekspozycją web/AI.

---

Źródła / bibliografia

1. Chrome Releases – Stable Channel Update for Desktop (142.0.7444.134/.135, 5 CVE, rollout i restrykcje szczegółów). (Chrome Releases)
2. SecurityWeek – „Chrome 142 Update Patches High-Severity Flaws” (CVE, opis WebGPU, brak „in the wild”). (SecurityWeek)
3. Tenable – Nessus Plugin 274070 (detekcja hostów <142.0.7444.135, lista CVE). (Tenable®)
4. Chrome for Developers – Release notes 142 (data stabilnego wydania 28.10.2025). (Chrome for Developers)
5. FortiGuard – wpis zbiorczy o lukach w Chrome 142 (mapowanie CVE/komponentów). (fortiguard.com)