Katalog podatności CVE

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.

W Apache Wicket w wersjach od 10.3.0 do 10.11.0 występuje brak autoryzacji przy przetwarzaniu formularzy. Formularz przyjmuje nazwę komponentu zatwierdzającego z parametrów żądania i przekazuje ją bezpośrednio do onFormSubmitted(), pomijając sprawdzenie widoczności i dostępności komponentu. W efekcie żądanie może wywołać akcje przycisku lub linku, który aplikacja ukryła lub zablokowała.

W Apache Wicket brakuje autoryzacji w obsłudze natywnych WebSocketów. Handler WebSocketMessageBroadcastHandler wywołuje WebSocketResource#onPayload() bez sprawdzenia IAuthorizationStrategy#isResourceAuthorized(), a adnotacja @AuthorizeResource nie działa. Wystarczy sesja Wicket i nazwa zasobu (ujawniana w stronie otwierającej połączenie), by wywołać wszystkie callbacki zasobu, w tym onConnect() i onMessage().

Wykryto podatność w beecue FastBee do wersji 2.1.0. Nieznana funkcjonalność pliku /iot/script w komponencie Groovy Script Executor pozwala na wstrzyknięcie kodu. Atak można przeprowadzić zdalnie, a poprawka jest dostępna pod identyfikatorem 890a33846005a937a58cccd738b7fb9821b82ea9.

W urządzeniach Ruijie RG-ES205GC, RG-ES206GC-P, RG-ES208GC, RG-ES210GC-LP i RG-ES210GS-P (wersja ESW_1.0(1)B1P48) odkryto lukę w nieznanej funkcji pliku set_cloud_serverUrl.cgi, należącego do komponentu Cloud Management. Manipulacja argumentem url prowadzi do cross-site scripting (XSS). Atak można przeprowadzić zdalnie, a exploit został publicznie ujawniony.

W urządzeniach Ruijie RG-ES205GC, RG-ES206GC-P, RG-ES208GC, RG-ES210GC-LP i RG-ES210GS-P (wersja ESW_1.0(1)B1P48) wykryto podatność w nieznanej funkcji pliku httpupg.cgi, należącego do interfejsu lokalnej aktualizacji firmware. Manipulacja danymi prowadzi do przepełnienia bufora (buffer overflow). Atak można zainicjować zdalnie, a exploit jest publicznie dostępny.

W urządzeniu WAVLINK WN553X1-B (wersja V260403_2.0.0) wykryto podatność w funkcji sub_41A748 pliku /bin/ioos, związanej z obsługą grupy WireGuard CLI. Manipulacja argumentami group_id/group_name może prowadzić do wstrzyknięcia poleceń systemowych (OS command injection). Atak można przeprowadzić zdalnie, a exploit został publicznie ujawniony.

W urządzeniu WAVLINK WN553X1-B (wersja V260403_2.0.0) wykryto podatność w funkcji sub_419DA8 pliku /bin/ioos, w komponencie obsługi CLI WireGuard. Manipulacja argumentem file_id prowadzi do wstrzyknięcia poleceń systemu operacyjnego. Atak można przeprowadzić zdalnie, a exploit został publicznie ujawniony.