boringproxy w wersji do 0.10.0 włącznie zawiera podatność na wyczerpanie zasobów (resource exhaustion), która pozwala każdemu uwierzytelnionemu użytkownikowi trwale wyczerpać deskryptory plików, goroutines i pamięć serwera. Skutkuje to całkowitym zatrzymaniem przesyłania ruchu tunelowego dla wszystkich użytkowników.
▸ Pokaż oryginał (EN)
boringproxy through 0.10.0 contains a resource exhaustion vulnerability that allows any authenticated user to permanently exhaust server file descriptors, goroutines, and memory by sending requests to the GET /loading endpoint with attacker-supplied id query parameter values. Because the handler performs no map-lookup validity check and receives on a nil channel that blocks forever, with no timeout, no context cancellation, and no server-side reclamation due to absent HTTP server timeouts, each malicious request permanently holds one goroutine, one file descriptor, and approximately 50 kB of memory until the server's file descriptor limit is reached and listener Accept calls fail, halting all tunnel traffic forwarding for all users.
Handler obsługujący endpoint GET /loading nie wykonuje żadnej walidacji parametru zapytania 'id' — nie sprawdza, czy podana wartość istnieje w mapie wewnętrznej. Zamiast tego próbuje odbierać dane z kanału o wartości nil, co powoduje trwałe zablokowanie goroutine bez jakiegokolwiek timeoutu, anulowania kontekstu ani mechanizmu odzyskiwania zasobów po stronie serwera (brak skonfigurowanych timeoutów HTTP). Każde złośliwe żądanie na stałe zajmuje jedną goroutine, jeden deskryptor pliku oraz około 50 kB pamięci. Po wyczerpaniu limitu deskryptorów plików wywołania Accept na listenerze zaczynają zwracać błędy, co wstrzymuje cały ruch tunelowy.
Uwierzytelniony atakujący może doprowadzić do trwałej niedostępności serwera (Denial of Service) poprzez wyczerpanie deskryptorów plików, goroutines i pamięci, co uniemożliwia obsługę połączeń tunelowych dla wszystkich użytkowników.
Należy zastosować patche dostępne u producenta zgodnie z referencjami. Jako środek zastępczy można rozważyć ograniczenie dostępu do endpointu GET /loading wyłącznie do zaufanych użytkowników oraz wdrożenie limitów połączeń i timeoutów na poziomie reverse proxy lub firewalla.
boringproxy w wersji do 0.10.0 włącznie
Podatność wymaga uwierzytelnienia — atakujący musi posiadać aktywne konto w systemie boringproxy. Mechanizm ataku jest opisany szczegółowo w publicznym repozytorium GitHub wskazanym w referencjach.
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X