Katalog podatności CVE

W urządzeniu WAVLINK WN536AX6-A (wersja V260507_2.0.0) wykryto podatność w funkcji sub_41a1d8 pliku /bin/ioos, związanej z obsługą grupy WireGuard CLI. Manipulacja argumentem group_name prowadzi do wstrzyknięcia poleceń systemowych (OS command injection). Podatność można wykorzystać zdalnie, a publiczny exploit jest już dostępny.

W urządzeniu WAVLINK WN536AX6-A (wersja V260507_2.0.0) zidentyfikowano słabość w funkcji sub_416760 pliku /bin/ioos, w komponencie interfejsu zarządzania webowego. Manipulacja argumentem group_name powoduje wstrzyknięcie poleceń systemowych (OS command injection). Atak można zainicjować zdalnie, a exploit został publicznie udostępniony.

Apache Wicket generuje kod JavaScript odwołujący się do renderowanych elementów, umieszczając w literałach tekstowych w pojedynczych cudzysłowach wartości markup id oraz nazwy pól formularza bez odpowiedniego escapowania. Wartość zawierająca apostrof lub backslash może przerwać literał, a następnie wstrzyknąć kod wykonywany w kontekście aplikacji przy załadowaniu strony. Problem dotyczy wicket-core oraz wicket-extensions w wersjach 8.0.0–8.19.0, 9.0.0–9.24.0 i 10.0.0–10.11.0.

Apache Wicket w wersjach 10.10.0, 10.11.0 i 9.24.0 nie ustawia nagłówków Content-Security-Policy na stronach, których procedura obsługi żądania renderowania jest opakowana w więcej niż jeden IRequestHandlerDelegate. Framework odpakowuje tylko jeden poziom delegata przy podejmowaniu decyzji o renderowaniu strony, więc przy głębszym łańcuchu (np. delegujący mapper żądań aplikacji w połączeniu z CryptoMapper) strona jest serwowana bez nagłówka CSP, mimo że CSP jest włączone i nie jest zgłaszany żaden błąd ani ostrzeżenie. Ochrona oparta na nonce dla skryptów i stylów inline oraz inne skonfigurowane dyrektywy CSP są tracone dla tych stron, narażając je na wstrzyknięcie treści, któremu polityka miała zapobiegać. Aplikacje na standardowym Wicket, które same nie opakowują procedur obsługi żądań, nie są dotknięte. Wersje przed 10.10.0 i 9.24.0 obsługiwały zagnieżdżone delegaty poprawnie.

Podatność typu cross-site scripting (XSS) w Apache Wicket wynika z niewłaściwej neutralizacji danych wejściowych podczas generowania stron. Komponent ExternalLink, powiązany z elementem innym niż a, link lub area, wstawia URL z modelu do literału JavaScript w atrybucie onclick bez odpowiedniego escapowania, co pozwala na wykonanie złośliwego skryptu w kontekście aplikacji.

W Apache Wicket występuje błąd kolejności sprawdzeń: ścieżka pliku jest walidowana przez PackageResourceGuard zanim framework dołączy do niej atrybuty style, variation i locale. W rezultacie otwierany plik może być innym plikiem niż zatwierdzony przez guard, co pozwala na odczytanie szablonów HTML komponentów, których nazwy klas zawierają podkreślenie (np. Report_v2).

W Apache Wicket mechanizm PackageResourceGuard błędnie zezwala na serwowanie szablonów znaczników komponentów jako zasobów pakietowych, gdy wicket-core jest ładowany przez class loader, który nie widzi klas aplikacji. W takiej konfiguracji sprawdzenie obecności pliku klasy obok szablonu kończy się niepowodzeniem, a żądanie URL zasobu pakietowego zwraca szablon komponentu ze statusem 200. Ujawnieniu podlegają treści szablonów tworzone przez deweloperów, takie jak struktura komponentów, komentarze, skrypty inline i nazwy endpointów.

Podatność w Apache Wicket dotyczy zasobu AbstractFileUploadResource (serwerowa strona uploadu bez formularza z FileUploadToResourceField). Limity rozmiaru żądania, pojedynczego pliku i liczby części są pobierane z parametrów żądania (maxSize, fileMaxSize, fileCountMax) zamiast z konfiguracji aplikacji, więc klient może je dowolnie zawyżyć lub pominąć. Zasób nie ma adnotacji autoryzacyjnej, więc domyślnie żądanie nie wymaga uwierzytelnienia.

Podatność w Apache Wicket dotyczy komponentu FileUploadToResourceField, którego callback Ajax odczytuje parametr filesInfo bez powiązania go z rzeczywistym uploadem. Metoda UploadInfo#get() alokuje tablicę bajtów na podstawie rozmiaru podanego przez klienta, co pozwala na wyczerpanie sterty JVM pojedynczym żądaniem, a wartości ujemne powodują wyjątek NegativeArraySizeException.

Podatność w Apache Wicket dotyczy metody JavaScriptUtils#escapeQuotes(), która nie escapuje znaku backslash przed cudzysłowami. Wartość zawierająca backslash bezpośrednio przed cudzysłowem powoduje, że cudzysłów nie jest escapowany i zamyka literał JavaScript, umożliwiając wstrzyknięcie kodu JavaScript. Problem występuje, gdy aplikacja używa tej metody do osadzenia danych kontrolowanych przez atakującego w literale JavaScript, m.in. przez komponent AjaxEditableLabel.

Podatność typu cross-site scripting (XSS) w komponentach SmartLinkLabel i SmartLinkMultiLineLabel biblioteki Apache Wicket. Komponenty te zamieniają znalezione w tekście adresy URL w hiperłącza, akceptując dowolny schemat URL — w tym schematy wykonujące skrypt, takie jak javascript:. Eskapowanie wartości modelu nie chroni, ponieważ payload trafia do atrybutu href, a nie do tekstu elementu.

Podatność typu cross-site scripting (XSS) w Apache Wicket dotyczy zachowania AjaxNewWindowNotifyingBehavior, które zapisuje w stanie strony wartość window.name przesłaną przez klienta. Wartość ta jest później wstawiana bez escapowania do literału JavaScript w preconditions wywołania Ajax, co pozwala na wykonanie dowolnego skryptu w kontekście aplikacji przy każdym renderowaniu strony. Podatność występuje tylko w aplikacjach, które jawnie dodały to zachowanie do komponentu.

Wykryto lukę bezpieczeństwa w Shanghai Xi Yu Ji Zhi Technology Minimax Code 0.5.8. Dotyczy ona nieznanej części komponentu Find Command Handler, a manipulacja argumentem -exec prowadzi do wstrzyknięcia poleceń systemu operacyjnego. Atak może być przeprowadzony zdalnie.

Apache Wicket zapisuje teksty z resource bundle (etykiety, nazwy klas CSS) do generowanego JavaScriptu i znaczników HTML bez odpowiedniego escapowania dla kontekstu. Tekst zawierający apostrof lub cudzysłów może przerwać literał lub atrybut, a następnie zostać zinterpretowany jako skrypt lub znacznik w origin aplikacji. Problem dotyczy m.in. MultiFileUploadField, Form, UploadProgressBar, FilterForm i TrapFocusBehavior w wersjach 8.0.0–8.19.0, 9.0.0–9.24.0 i 10.0.0–10.11.0.

W Apache Wicket występuje nieprawidłowa kolejność sprawdzeń bezpieczeństwa w ResourceIsolationRequestCycleListener — strona docelowa żądania jest tworzona przed sprawdzeniem polityk izolacji zasobów. W wyniku tego wyjątek RestartResponseAtInterceptPageException jest rzucany z wnętrza listenera, zanim polityki zostaną uruchomione, a żądanie z innego origin nie zostaje odrzucone. Dodatkowo zapisany URL docelowy (wraz z query stringiem) jest używany po zalogowaniu, co pozwala innemu origin wpłynąć na wartości pól formularza przekazywane do Form#onSubmit().

Podatność typu session fixation w Apache Wicket dotyczy klasy AuthenticatedWebSession i metody signIn(String, String). Identyfikator sesji jest odnawiany tylko przy pierwszym logowaniu, a nie przy ponownej autoryzacji już zalogowanej sesji, mimo że metoda zwraca true w obu przypadkach. Wykorzystanie wymaga umieszczenia przez atakującego wybranego identyfikatora sesji w przeglądarce ofiary, np. przez kontrolę hosta w tej samej domenie rejestrowanej lub konfigurację kontenera przenoszącego identyfikator sesji w URL.

Apache Wicket nie egzekwuje autoryzacji zasobów (isResourceAuthorized() ani adnotacji @AuthorizeResource) w komponentach ResourceLink, Image, ImageButton oraz AjaxDownloadBehavior, gdy zasób jest przekazany jako instancja IResource. W takim przypadku zasób jest serwowany bez sprawdzenia uprawnień, podczas gdy ta sama kontrola działa przy użyciu ResourceReference. Problem dotyczy też ExportToolbar, który buduje linki eksportu z instancji IResource.

W Apache Wicket brak autoryzacji pozwala na wywołanie listenera komponentu, dla którego strategia autoryzacji odmówiła akcji RENDER. Wystarczy spreparowany lub nawet standardowy URL listenera bez identyfikatora strony, przez co nie wykonuje się faza renderowania ani Component#configure(), a flaga widoczności pozostaje domyślna. Dotyczy to również komponentów ukrytych lub wyłączonych w Component#onConfigure().

Podatność w Apache Wicket polega na niewystarczającym wygasaniu sesji w obsłudze natywnych WebSocketów. Połączenie WebSocket przechowuje kopię sesji HTTP z momentu jego otwarcia, więc unieważnienie sesji przez kontener (timeout, wylogowanie, invalidate z filtra) nie kończy połączenia — kolejne ramki nadal korzystają z wygasłej tożsamości i jej atrybutów.

Apache Wicket nie sprawdza autoryzacji przed wywołaniem callbacków onMessage() w WebSocketBehavior. Komunikat wysłany przez klienta jest dostarczany do każdego WebSocketBehavior na stronie, nawet jeśli komponent, do którego jest przypisany, jest ukryty, wyłączony lub zabroniony przez IAuthorizationStrategy — w przeciwieństwie do zachowań Ajax, gdzie taka weryfikacja jest wykonywana.