Podatności Electron

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.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.

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.