Podatności Electron

Electron to framework do tworzenia wieloplatformowych aplikacji desktopowych przy użyciu JavaScript, HTML i CSS. W wersjach przed 42.11.16, 43.8.1, 44.9.1 i 45.0.0-beta.6 Electron nie blokuje skompromitowanych certyfikatów pośrednich eMudhra w sieci Chromium, Node.js tls, Node.js https ani Node.js fetch. Atakujący posiadający certyfikat wystawiony przez taki certyfikat pośredni i mogący przechwycić ruch sieciowy może podszyć się pod serwer TLS dla podatnej aplikacji.

W Electronie przed wersjami 42.11.6, 43.7.3, 44.4.3 i 45.0.0-alpha.9 dane ramek otrzymywane z procesu GPU przy renderowaniu offscreen na macOS nie były w pełni walidowane przez proces główny. Atakujący z kodem wykonawczym w procesie GPU mógł dostarczyć niespójną geometrię ramki i spowodować odczyt poza granicami pamięci w procesie głównym, ujawniając pamięć lub powodując awarię aplikacji.

W Electronie przed wersjami 42.11.6, 43.7.3, 44.4.3 i 45.0.0-alpha.9 dane ramek otrzymywane z procesu GPU dla webContents.beginFrameSubscription nie były w pełni walidowane przez proces główny. Atakujący z kodem wykonawczym w procesie GPU mógł dostarczyć niespójną geometrię ramki i spowodować odczyt poza granicami pamięci w procesie głównym, ujawniając pamięć lub powodując awarię aplikacji.

W Electronie przed wersjami 42.11.3, 43.7.0, 44.3.0 i 45.0.0-alpha.5 żądania otwarcia zewnętrznych adresów URL protokołów mogły być przypisane do innego dokumentu niż ten, który je zainicjował. Powodowało to, że parametr requestingUrl przekazywany do session.setPermissionRequestHandler wskazywał zaufaną treść dla żądania pochodzącego z niezaufanej treści.

Electron to framework do tworzenia aplikacji desktopowych. W wersjach przed 42.11.3, 43.7.0, 44.3.0 i 45.0.0-alpha.5 sprawdzanie uprawnień hid i usb wykonywane z iframe powodowało, że setPermissionCheckHandler otrzymywał origin i szczegóły ramki najwyższego poziomu zamiast ramki żądającej. Aplikacja, która delegowała hid lub usb do niezaufanego iframe cross-origin i zezwalała na dostęp do urządzeń na podstawie logiki origin, mogła przyznać tej osadzonej ramce dostęp przeznaczony dla strony najwyższego poziomu.

W frameworku Electron żądania uprawnień pointerLock z niektórych iframe'ów cross-origin powodowały, że session.setPermissionRequestHandler() otrzymywał requestingUrl i isMainFrame ramki najwyższego poziomu zamiast wartości ramki żądającej. Aplikacja osadzająca niezaufaną zawartość iframe i przyznająca pointer lock na podstawie pochodzenia żądania mogła przyznać uprawnienie w imieniu strony najwyższego poziomu. Problem naprawiono w wersjach 42.11.9, 43.7.6, 44.5.0 i 45.0.0-alpha.13.

W frameworku Electron funkcja chrome.tabs.query() zwracała adres URL i tytuł każdej karty rozszerzeniom, które nie miały uprawnienia tabs ani pasujących uprawnień hosta. Aplikacja ładująca niezaufane rozszerzenie przez session.extensions.loadExtension mogła pozwolić mu odczytać URL i tytuł każdego webContents w swojej sesji. Problem naprawiono w wersjach 42.11.1, 43.5.1, 44.1.1 i 45.0.0-alpha.4.

W Electronie przed wersjami 42.11.3, 43.7.0, 44.3.0 i 45.0.0-alpha.6 strony otwierane w nowym oknie z linków były traktowane jako nawigacje zainicjowane przez aplikację, zamiast zachowania strony zawierającej link jako inicjatora. Powodowało to, że żądanie najwyższego poziomu mogło zostać zaklasyfikowane jako same-site, wysyłając ciasteczka SameSite=Strict i nie ujawniając inicjatora w Sec-Fetch-Site.

Aplikacje Electron na macOS korzystające z automatycznych aktualizacji opartych na Squirrel.Mac są podatne na lokalny wyścig w uprzywilejowanym pomocniku ShipIt w wersjach przed 39.8.10, 41.10.5 i 42.0.0-beta.2. Pomocnik nie wiązał zweryfikowanego celu aktualizacji z jedną kanoniczną ścieżką pakietu aplikacji, co pozwala lokalnemu atakującemu przekierować zapis z uprawnieniami roota i nadpisać pliki innej aplikacji.

Electron to framework do tworzenia aplikacji desktopowych. W wersjach od 42.3.3 do 42.10.0, 43.5.0 i 44.0.0-beta.6, sandboxowany preload code cache nie weryfikował, czy wpis w cache odpowiada preloadowi, dla którego był serwowany. Złamany renderer mógł zapisać dane cache kontrolowane przez atakującego i spowodować, że Electron użyje ich przy późniejszym ładowaniu, wykonując kod renderera w bardziej uprzywilejowanym kontekście preload. Problem dotyczy aplikacji ładujących niezaufane treści. Poprawiono w wersjach 42.10.0, 43.5.0 i 44.0.0-beta.6.

Elektron to framework do tworzenia aplikacji desktopowych. Przed wersjami 41.10.6, 42.9.2, 43.4.1 i 44.0.0-beta.5, gość <webview> mógł włączyć nodeIntegrationInWorker dla swoich Web Workerów, nawet gdy osadzający (embedder) miał wyłączoną integrację Node.js i nie był w piaskownicy. Pozwalało to niezaufanej treści na utworzenie workera z uprawnieniami Node.js, przekraczającymi przyznane przez osadzającego.

Elektron przed wersjami 41.10.6, 42.9.2, 43.4.1 i 44.0.0-beta.5 miał problem z odpowiedziami serwowanymi przez protocol.registerFileProtocol lub protocol.registerHttpProtocol dla niestandardowego schematu z włączonym supportFetchAPI, ale wyłączonym corsEnabled. Odpowiedzi te mogły pozostać czytelne dla skryptów z innych źródeł (cross-origin). Jest to dopełnienie poprawki dla CVE-2026-70604.

Elektron przed wersjami 41.10.6, 42.9.2, 43.4.1 i 44.0.0-beta.5 nie dziedziczył aktywnych ograniczeń sandboxa HTML dla okien otwieranych z sandboxowanego dokumentu najwyższego poziomu. Niezaufana treść w takim dokumencie, która mogła otwierać popupy, mogła utworzyć okno z pełnym originem aplikacji Electron, zamiast ograniczonego originu przewidzianego przez sandbox.

Elektron przed wersjami 41.10.4, 42.5.2 i 43.0.0 nie przekazywał odziedziczonych ograniczeń sandboxa HTML do popupów otwieranych z sandboxowanego iframe przez ścieżkę OpenURLFromTab, w tym linki z target="_blank" lub środkowym kliknięciem. Niezaufany iframe z konfiguracją allow-scripts allow-popups mógł otworzyć popup z pełnym originem aplikacji, ujawniając ciasteczka, storage i możliwości skryptowania samego originu.

Electron to framework do tworzenia aplikacji desktopowych. Przed wersjami 39.8.8, 40.9.0, 41.2.1 i 42.0.0-beta.3, żądania otwarcia zewnętrznych protokołów URL z treści web nie uwzględniały ograniczeń sandboxa iframe, więc sandboxowany iframe mógł uruchomić zewnętrzną aplikację zarejestrowaną w systemie operacyjnym. Stan sandboxa ramki nie był również udostępniany handlerom uprawnień aplikacji, co wpływa na aplikacje renderujące niezaufane treści w sandboxowanych iframe i przyznające domyślnie uprawnienie openExternal, gdy nie zainstalowano setPermissionRequestHandler.

Electron to framework do tworzenia aplikacji desktopowych. Przed wersjami 39.8.9, 40.9.2, 41.2.1 i 42.0.0-beta.3, akcja DevTools 'reveal in file manager' mogła uruchomić docelowy plik zamiast go pokazać. Atakujący z osobnym sposobem uruchamiania skryptów w frontendzie DevTools, takim jak złośliwe rozszerzenie DevTools, mógł użyć obsługi showItemInFolder do wykonania natywnego kodu poza sandboxem, gdy DevTools jest otwarty dla okien narażonych na niezaufane treści lub niezaufane rozszerzenia DevTools.

Electron to framework do tworzenia aplikacji desktopowych. Przed wersjami 39.8.9, 40.9.2, 41.2.2 i 42.0.0-beta.4, obiekty kopiowane przez granicę contextBridge z niezaufanych treści mogły przenosić prototyp wpływający na atakującego, umożliwiając ataki typu prototype pollution na kod preload, mimo włączonej izolacji kontekstu. Aplikacje są dotknięte tylko wtedy, gdy ich kod preload akceptuje argumenty obiektowe z niezaufanych treści i czyta z nich właściwości bez sprawdzania własności; aplikacje akceptujące tylko argumenty prymitywne lub walidujące argumenty obiektowe nie są dotknięte.

Electron to framework do tworzenia aplikacji desktopowych. Przed wersjami 39.8.7, 40.9.0, 41.2.0 i 42.0.0-beta.1, opcja mode w webContents.openDevTools() nie była sanityzowana przed użyciem przez frontend DevTools. Jeśli atakujący może wpłynąć na tę wartość, skrypt pod jego kontrolą może zostać uruchomiony w kontekście DevTools, który w konfiguracjach bez sandboxa ma dostęp do Node.js, w tym gdy niezaufane dane wejściowe trafiają do argumentu mode funkcji openDevTools() lub gdy niezaufana treść wywołuje openDevTools() na osadzonym webview.

Electron przed wersjami 39.8.10, 41.10.3 i 42.0.1 pozwalał sandboxowanemu iframe bez atrybutu allow-popups na otwieranie nowych okien lub wyzwalanie setWindowOpenHandler bez interakcji użytkownika. Dzieje się tak, ponieważ nawigacje nowego okna korzystające ze ścieżki OpenURL nie stosowały ograniczeń popup dla sandboxowanych iframe. Problem dotyczy aplikacji osadzających niezaufane treści w sandboxowanych iframe i polegających na braku allow-popups, a nie dotyczy aplikacji, które blokują tworzenie okien w setWindowOpenHandler lub nie osadzają niezaufanych treści.

Electron (przed wersjami 39.8.8, 40.9.0, 41.2.1 i 42.0.0-beta.3) stosuje niektóre opcje okna dostarczone przez treść internetową w ciągu window.open() do nowego BrowserWindow bez listy dozwolonych. Niezaufana treść może ustawić opcje okna, których nie powinna kontrolować, w tym opcje powodujące dostęp procesu głównego do wybranych przez atakującego ścieżek plików lub sieci, gdy niezaufana treść może wywołać window.open() i aplikacja nie nadpisuje opcji okna podrzędnego przez setWindowOpenHandler lub overrideBrowserWindowOptions.

Podatność w Electron przed wersjami 40.10.6, 41.9.1, 42.5.1 i 43.0.0 polega na tym, że gdy niestandardowy handler protokołu zwraca ProtocolResponse z polem url i bez session, żądanie jest wysyłane przez defaultSession zamiast sesji obsługującej protokół. Może to spowodować ponowne użycie odpowiedzi z pamięci podręcznej między izolowanymi partycjami sesji. Aplikacje używające ProtocolResponse.url, pomijające ProtocolResponse.session i polegające na oddzielnych sesjach są narażone.

Podatność w Electron przed wersjami 39.8.8, 40.9.0, 41.2.1 i 42.0.0-beta.3 polega na tym, że podczas podążania za przekierowaniami HTTP, net.fetch() i net.request() nie ograniczały schematów, do których może prowadzić przekierowanie. Zdalny serwer może przekierować żądanie do lokalnego zasobu, a jeśli aplikacja zwraca lub przekazuje treść odpowiedzi, może dojść do ujawnienia lokalnych plików. Aplikacje są narażone tylko wtedy, gdy wykonują żądania sieciowe do adresów URL kontrolowanych przez atakującego i ujawniają treść odpowiedzi.

Electron to framework do tworzenia aplikacji desktopowych. Przed wersjami 39.8.10, 40.9.3, 41.4.0 i 42.0.0 niestandardowy schemat zarejestrowany z supportFetchAPI: true, ale bez corsEnabled: true, nie był objęty egzekwowaniem CORS. Strona załadowana ze zdalnego pochodzenia mogła wykonać fetch() lub XMLHttpRequest do tego schematu w trybie cross-origin i odczytać pełną treść odpowiedzi. Aplikacje serwujące wrażliwe dane z takiego schematu i ładujące zdalne lub niezaufane treści w rendererze są dotknięte.

Podatność w Electron przed wersjami 39.8.6, 40.9.0, 41.1.1 i 42.0.0-beta.1 polega na tym, że shell.openPath() nie odrzucał ścieżek zawierających wbudowane bajty null. Aplikacje, które wykonują tylko walidację ciągów znaków ścieżek, np. sprawdzanie rozszerzenia, przed przekazaniem do shell.openPath(), mogą zostać ominięte, co pozwala na otwarcie innego pliku niż ten, który przeszedł walidację. Aplikacje są narażone tylko wtedy, gdy przekazują ścieżki pochodzące z niezaufanego wejścia i polegają na walidacji opartej na ciągach bez sprawdzenia systemu plików.

Podatność w Electron przed wersjami 39.8.8, 40.9.0, 41.2.1 i 42.0.0-beta.3 polega na tym, że API kart i skryptów rozszerzeń nie były ograniczone do sesji samego rozszerzenia. Złośliwe lub skompromitowane rozszerzenie załadowane w jednej sesji mogło nawigować, skryptować i czytać z okien należących do innej sesji. Aplikacje są narażone tylko wtedy, gdy ładują rozszerzenia Chrome przez session.loadExtension i polegają na oddzielnych sesjach do izolacji.

Electron to framework do tworzenia aplikacji desktopowych. Przed wersjami 39.8.9, 40.9.2, 41.2.2 i 42.0.0-beta.5 aplikacje, które udostępniają funkcje zwracające Promise do treści webowych przez contextBridge, mogą być podatne na obejście izolacji kontekstu. Niezaufana treść webowa może uzyskać dostęp do izolowanego świata preload i, przez to, do wszystkich możliwości skryptu preload. W rendererach bez sandboxa lub z włączonym nodeIntegration może to eskalować do dostępu do Node.js.

Electron to framework do tworzenia aplikacji desktopowych. Przed wersjami 39.8.8, 40.9.0, 41.2.1 i 42.0.0-beta.3 natywny popup autofill mógł być pozycjonowany przez iframe z innego pochodzenia poza granicami tego iframe, nad interfejsem strony osadzającej, co umożliwiało clickjacking lub podszywanie się pod zaufany interfejs. Aplikacje są dotknięte tylko wtedy, gdy osadzają niezaufane treści w iframe w oknach, które również wyświetlają zaufany interfejs. Aplikacje, które nie osadzają niezaufanych treści, nie są dotknięte.

W Electron przed wersjami 39.8.7, 40.9.0, 41.2.0 i 42.0.0-beta.1, sprawdzanie uprawnień do portów szeregowych i mediów wykonywane z iframe przekazywało origin ramki najwyższego poziomu do session.setPermissionCheckHandler zamiast origin żądającej iframe. Logika oparta na origin mogła przyznać iframe z innego originu dostęp do urządzeń przeznaczony tylko dla originu najwyższego poziomu.

Electron to framework do tworzenia aplikacji desktopowych. Przed wersjami 39.8.10, 40.9.0, 41.2.1 i 42.0.0-beta.3 dane ramek renderowania offscreen otrzymywane z procesu GPU nie były w pełni weryfikowane przez proces główny. Złamany proces GPU mógł spowodować odczyt poza zakresem pamięci przez proces główny podczas tworzenia obrazów zdarzeń malowania, ujawniając pamięć lub powodując awarię aplikacji.

W Electron przed wersjami 39.8.8, 40.9.0, 41.2.1 i 42.0.0-beta.3, kontrola używana na macOS do potwierdzenia, że aplikacja została uruchomiona przez proces nadrzędny z tym samym podpisem, mogła zostać ominięta przez lokalny proces. Aplikacje korzystające z zabezpieczeń opartych na fuse, które ograniczają ELECTRON_RUN_AS_NODE i NODE_OPTIONS do procesów nadrzędnych z tym samym podpisem, polegają na tej kontroli; lokalny atakujący mógł ją ominąć i uruchomić kod wewnątrz podpisanej aplikacji, dziedzicząc jej uprawnienia TCC i dostęp do pęku kluczy.

W Electron przed wersjami 39.8.5, 40.8.5, 41.1.0 i 42.0.0-alpha.5 wykryto podatność w funkcji clipboard.readImage(). Jeśli schowek zawiera obraz, który nie może zostać zdekodowany, przekazanie pustej bitmapy do konstrukcji obrazu powoduje kontrolowane przerwanie i awarię procesu. Podatność dotyczy tylko aplikacji wywołujących clipboard.readImage().

Electron przed wersjami 39.8.5, 40.8.5, 41.1.0 i 42.0.0-alpha.5 zawiera podatność, w której okno podrzędne może być nawigowane przez niezwiązanego z nim renderera, jeśli oba użyją tej samej nazwy docelowej. Może to prowadzić do eskalacji uprawnień, a w przypadku włączenia nodeIntegration lub wyłączenia sandboxa do zdalnego wykonania kodu.

Electron w wersjach od 39.0.0-alpha.1 do przed 39.8.0, od 40.0.0-alpha.1 do przed 40.7.0 oraz od 41.0.0-alpha.1 do przed 41.0.0-beta.8 zawiera podatność na ominięcie izolacji kontekstu. Aplikacje przekazujące obiekty VideoFrame (z API WebCodecs) przez contextBridge są podatne na atak. Osoba atakująca, która może wykonać JavaScript w głównym świecie (np. przez XSS), może użyć mostkowanego VideoFrame, aby uzyskać dostęp do izolowanego świata, w tym do API Node.js udostępnionych skryptowi preload.

Podatność w Electron (wersje przed 38.8.6, 39.8.1, 40.8.0, 41.0.0-beta.8) na macOS. Funkcja app.moveToApplicationsFolder() używa AppleScript, który nieprawidłowo obsługuje niektóre znaki w ścieżce, co może prowadzić do wykonania dowolnego AppleScript po zaakceptowaniu przez użytkownika monitu.

W frameworku Electron przed wersjami 38.8.6, 39.8.1, 40.8.1 i 41.0.0 worker usługowy działający w sesji może fałszować odpowiedzi na wewnętrznym kanale IPC używanym przez webContents.executeJavaScript() i podobne metody. Powoduje to, że obietnica w procesie głównym rozwiązuje się z danymi kontrolowanymi przez atakującego.

W frameworku Electron przed wersjami 38.8.6, 39.8.1, 40.8.1 i 41.0.0, gdy element iframe żąda pełnego ekranu, blokady wskaźnika, blokady klawiatury, openExternal lub uprawnień mediów, pochodzenie przekazywane do session.setPermissionRequestHandler() pochodziło z strony najwyższego poziomu, a nie z żądającego iframe. Aplikacje przyznające uprawnienia na podstawie parametru pochodzenia mogą nieświadomie udzielić dostępu treściom osadzonym z zewnątrz.

Electron przed wersjami 38.8.6, 39.8.1, 40.8.1 i 41.0.0 na macOS i Linux zawiera podatność na odczyt poza zakresem sterty podczas parsowania spreparowanej wiadomości drugiej instancji, gdy aplikacja wywołuje app.requestSingleInstanceLock(). Wyciek pamięci może zostać dostarczony do handlera zdarzenia drugiej instancji. Problem dotyczy tylko procesów działających jako ten sam użytkownik co aplikacja Electron. Windows nie jest dotknięty.

W Electronie przed wersjami 38.8.6, 39.8.4, 40.8.4 i 41.0.0 stwierdzono nieprawidłowe zakresowanie ustawienia nodeIntegrationInWorker. W pewnych scenariuszach współdzielenia procesów, workerzy uruchomieni w ramkach z wyłączoną integracją Node.js mogli ją otrzymać. Problem dotyczy tylko aplikacji, które włączają nodeIntegrationInWorker.

Electron przed wersjami 39.8.1, 40.7.0 i 41.0.0 ma podatność use-after-free w aplikacjach używających renderowania poza ekranem i zezwalających na okna potomne przez window.open(). Zniszczenie nadrzędnego WebContents przy otwartym oknie potomnym może prowadzić do awarii lub uszkodzenia pamięci.

Electron na Windows nie waliduje nazwy protokołu w app.setAsDefaultProtocolClient() przed zapisem do rejestru. Aplikacje przekazujące niezaufane dane jako nazwę protokołu mogą pozwolić atakującemu na zapis do dowolnych podkluczy rejestru, potencjalnie przejmując istniejące procedury obsługi protokołów.

Electron, framework do tworzenia aplikacji desktopowych, zawiera lukę use-after-free w przypadku, gdy aplikacja umożliwia pobieranie plików i programowo niszczy sesje. Jeśli sesja zostanie zniszczona podczas otwartego natywnego okna dialogowego zapisu pliku, zamknięcie okna dialogowego powoduje dereferencję zwolnionej pamięci, co może prowadzić do awarii lub uszkodzenia pamięci. Luka występuje przed wersjami 38.8.6, 39.8.0, 40.7.0 i 41.0.0-beta.8.

Electron przed wersjami 38.8.6, 39.8.0, 40.7.0 i 41.0.0-beta.8 jest podatny na use-after-free w obsłudze żądań uprawnień pełnego ekranu, blokady wskaźnika lub blokady klawiatury, gdy aplikacja rejestruje asynchroniczny program obsługi `session.setPermissionRequestHandler()`. Jeśli ramka żądająca nawiguje lub okno zamyka się w trakcie oczekiwania na odpowiedź, wywołanie zapisanego wywołania zwrotnego powoduje dereferencję zwolnionej pamięci, co może prowadzić do awarii lub uszkodzenia pamięci.

Electron przed wersjami 38.8.6, 39.8.1, 40.8.0 i 41.0.0-beta.8 zawiera podatność use-after-free w module powerMonitor. Po zwolnieniu obiektu PowerMonitor przez garbage collector, zasoby systemowe pozostają z wiszącymi referencjami, co przy zdarzeniach sesji (Windows) lub wyłączeniu systemu (macOS) może prowadzić do awarii lub uszkodzenia pamięci.

Electron przed wersjami 38.8.6, 39.8.0, 40.7.0 i 41.0.0-beta.8 zawiera nieudokumentowaną opcję webPreference commandLineSwitches, która pozwala na dołączanie dowolnych przełączników do linii poleceń procesu renderowania. Aplikacje konstruujące webPreferences z niezaufanych obiektów konfiguracyjnych mogą pozwolić atakującemu na wyłączenie sandboxa renderowania lub kontroli bezpieczeństwa sieci.

Electron na Windows nie cytuje ścieżki pliku wykonywalnego przy zapisie do rejestru Run, co pozwala atakującemu z dostępem do katalogu nadrzędnego na podmianę pliku uruchamianego przy logowaniu.

Electron, framework do tworzenia aplikacji desktopowych, zawiera lukę HTTP response header injection. Aplikacje rejestrujące niestandardowe protokoły za pomocą protocol.handle() lub modyfikujące nagłówki odpowiedzi przez webRequest.onHeadersReceived mogą być podatne, jeśli dane kontrolowane przez atakującego są odzwierciedlane w nazwie lub wartości nagłówka odpowiedzi. Luka występuje przed wersjami 38.8.6, 39.8.3, 40.8.3 i 41.0.3.

W Electron przed wersjami 38.8.6, 39.8.0, 40.7.0 i 41.0.0-beta.8 funkcja zwrotna select-usb-device nie waliduje wybranego identyfikatora urządzenia względem filtrowanej listy. Aplikacja, której procedura obsługi może zostać nakłoniona do wybrania urządzenia spoza filtrowanego zestawu, może uzyskać dostęp do nieautoryzowanego urządzenia USB.

W frameworku Electron istnieje możliwość obejścia mechanizmu ASAR Integrity poprzez modyfikację zasobów. Podatność dotyczy wyłącznie aplikacji z włączonymi fuse'ami embeddedAsarIntegrityValidation i onlyLoadAppFromAsar. Problem naprawiono w wersjach 35.7.5, 36.8.1, 37.3.1 i 38.0.0-beta.6.