Katalog podatności CVE

Podatność ujawnienia poświadczeń w Froxlor przed wersją 2.3.12 w komendzie API DirProtections.listing, która zwraca hashe haseł htpasswd. Uwierzytelnieni użytkownicy API mogą pobrać hashe bcrypt haseł użytkowników katalogów chronionych, co umożliwia ataki offline i ujawnienie ponownie użytych poświadczeń.

Froxlor do wersji 2.3.10 nie egzekwuje polityki mail.allow_external_domains w poleceniu API EmailSender.add. Gdy administrator włączył funkcję dozwolonych nadawców, ale wyłączył zewnętrzne domeny (mail.enable_allow_sender = 1, mail.allow_external_domains = 0), uwierzytelniony klient z dostępem do API może nadal użyć EmailSender.add do zarejestrowania dowolnego zewnętrznego adresu nadawcy dla swojej skrzynki, który jest przechowywany mimo polityki. Tworzy to obejście między konfiguracją UI/administratora a API i — tam gdzie wygenerowana konfiguracja poczty korzysta z tabeli dozwolonych nadawców — umożliwia klientowi autoryzację tożsamości nadawcy spoza hostowanych domen, ułatwiając podszywanie się pod nadawcę. Naprawiono w wersji 2.3.12.

Froxlor w wersjach 2.3.10 i wcześniejszych zawiera niekompletną poprawkę podatności GHSA-c3p2 — funkcja Validate::validateUrl odrzuca znaki CR/LF tylko w ścieżce, zapytaniu i fragmencie, a nie sprawdza części userinfo (user:pass@). Uwierzytelniony klient z uprawnieniami do tworzenia subdomen może podać adres URL przekierowania subdomeny z ładunkiem CR/LF w części userinfo, który przechodzi walidację i jest zapisywany dosłownie w konfiguracji vhost nginx lub Apache. Froxlor regeneruje i przeładowuje konfigurację jako root, więc wstrzyknięte dyrektywy działają w całym serwerze.

Froxlor w wersjach 2.3.10 i wcześniejszych zawiera niekompletną poprawkę podatności GHSA-75h4-... — cron eksportu danych klienta (DataDump) nie waliduje pośrednich komponentów ścieżki docelowej. Funkcja Froxlor\FileDir::makeCorrectDir() ma błąd off-by-one w przechodzeniu komponentów ścieżki, pomijając pierwszy segment poniżej katalogu domowego klienta, a zabezpieczenie w ExportCron.php sprawdza tylko ostatni komponent przez is_link(). Uwierzytelniony klient z włączonym eksportem może zaplanować eksport do podkatalogu swojego webspace, a następnie zastąpić pośredni komponent ścieżki dowiązaniem symbolicznym przed uruchomieniem crona jako root. Wtedy 'chown -R' rekurencyjnie zmienia właściciela drzewa katalogów (np. /etc) na UID klienta, co prowadzi do przejęcia uprawnień roota i kompromitacji między dzierżawcami.

Froxlor w wersjach do 2.3.10 jest podatny na dowolne usuwanie plików poprzez podążanie za dowiązaniami symbolicznymi w zadaniu cron usuwania danych FTP. Zadanie cron 8 (deleteFtpData), kolejkowane przy usuwaniu konta FTP, wywołuje FileDir::makeCorrectDir() bez argumentu $fixed_homedir, więc przechodzenie komponentów ścieżki jest pomijane, a następnie wykonuje 'rm -rf' jako root na wynikowej ścieżce z jedynie tekstowymi zabezpieczeniami. Ponieważ makeCorrectDir() dodaje końcowy ukośnik, GNU rm podąża za dowiązaniem symbolicznym użytym jako pośredni lub końcowy komponent ścieżki. Uwierzytelniony klient mogący zapisywać w katalogu domowym FTP może umieścić dowiązanie symboliczne między wstawieniem zadania a wykonaniem crona, powodując rekurencyjne usunięcie dowolnych drzew katalogów przez zadanie roota.

Froxlor w wersjach przed 2.3.12 nie ogranicza ani nie escapuje ustawienia system.letsencryptchallengepath — w przeciwieństwie do innych ustawień wzmocnionych w GHSA-33mp, pole nie ma zabezpieczenia string_regexp ani required_otp, a jego wartość jest dołączana bez escapowania do wiersza poleceń acme.sh budowanego w lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php i wykonywanego przez cron roota przez FileDir::safe_exec. Ponieważ safe_exec blokuje tylko metaznaki powłoki takie jak ; | & > < \ $ ~ ?, spacje i cudzysłowy przechodzą, a wartość jest dzielona na dodatkowe argumenty acme.sh. Administrator lub dowolny podmiot mogący zapisywać ustawienia (np. przez API importu ustawień) może wstrzyknąć opcje acme.sh takie jak --renew-hook, --pre-hook lub --post-hook, aby uzyskać wykonanie dowolnych poleceń jako root przy następnym uruchomieniu crona Let's Encrypt, albo użyć --config-home/--cert-home do zapisu dowolnych plików.

Froxlor 2.3.10 i wcześniejsze zawierają wyścig TOCTOU w synchronizacji kluczy SSH (lib/Froxlor/Cron/System/SshKeys.php, SshKeys::generateFiles). Walidacja zawartości/symlinków wykonywana przez FileDir::makeCorrectDir()/makeCorrectFile() jest tylko w czasie sprawdzenia; ścieżka pliku jest ponownie rozwiązywana jako root w czasie zapisu, bez przypinania ścieżki lub deskryptora pliku. Na instalacjach z włączonym system.allow_customer_shell=1, klient może podmienić swój katalog ~/.ssh na symlink po sprawdzeniu, co powoduje, że cron działający jako root dopisuje klucz publiczny klienta do /root/.ssh/authorized_keys i zmienia właściciela /root/.ssh na klienta, prowadząc do pełnego przejęcia hosta panelu. Naprawiono w Froxlor 2.3.12.

Froxlor do wersji 2.3.10 wyłącza dwuskładnikowe uwierzytelnianie (2FA) użytkownika natychmiast po nieuwierzytelnionym żądaniu GET do strony zarządzania 2FA (np. /customer_index.php?page=2fa&action=delete), bez potwierdzenia, ponownego uwierzytelnienia ani tokena CSRF. Globalny middleware CSRF obejmuje tylko żądania POST/PUT/PATCH/DELETE, a ciasteczko sesji ma SameSite=Lax, więc nawigacja między witrynami (kliknięcie linku lub przekierowanie) przenosi sesję ofiary i cicho czyści type_2fa/data_2fa. Dotyczy to zarówno handlerów 2FA klienta, jak i administratora. Atakujący, który zwabi zalogowanego użytkownika panelu do kliknięcia spreparowanego linku, redukuje konto do uwierzytelniania tylko hasłem, co można połączyć z przejętym hasłem do przejęcia konta. Naprawione w 2.3.12.

Froxlor przed wersją 2.3.12 nie unieważnia istniejących sesji panelu, kluczy API i ciasteczek zaufania 2FA po zmianie hasła użytkownika. Atakujący posiadający przejęte sesje, ważne klucze API lub tokeny zaufania 2FA zachowują pełny dostęp do konta po rotacji hasła, omijając działania związane z reagowaniem na incydenty.

Froxlor do wersji 2.3.10 nie filtruje wrażliwych kolumn z odpowiedzi API: Domains::get(), Domains::listing(), SubDomains::get() oraz gałąź admina SubDomains::listing() wykonują SELECT z użyciem wildcard na tabeli panel_domains i zwracają wiersz bez modyfikacji, w tym pole panel_domains.dkim_privkey. Uwierzytelniony administrator niebędący superadminem z flagą customers_see_all może odczytać prywatne klucze DKIM domen innych dzierżawców przez Domains.get, Domains.listing, SubDomains.get lub SubDomains.listing, a jedno wywołanie listing ujawnia klucz każdej widocznej domeny. Ujawnione klucze pozwalają atakującemu podpisywać e-maile przechodzące weryfikację DKIM i wyrównanie DMARC dla dotkniętych domen. To następstwo niepełnej poprawki, która usunęła hasło i data_2fa, ale nie dkim_privkey. Problem naprawiony w 2.3.12.

Froxlor do 2.3.10 przechowuje w tokenach remembered-2FA (panel_2fa_tokens) tylko numeryczny identyfikator użytkownika bez przestrzeni nazw konta, a wyszukiwanie tokena przy logowaniu nie jest ograniczone do typu konta klienta lub administratora. Ponieważ identyfikatory klientów i administratorów pochodzą z oddzielnych przestrzeni, token wystawiony klientowi o danym ID pasuje także do administratora o tym samym ID, co pozwala obejść drugi składnik TOTP administratora przy znanym haśle.

Froxlor przed wersją 2.3.13 zwraca kolumnę ssl_key_file — która przechowuje surową zawartość prywatnego klucza TLS w formacie PEM — bezpośrednio w odpowiedziach JSON poleceń API Certificates.get i Certificates.listing, ponieważ wyniki zapytań domain_ssl_settings są przekazywane przez ApiCommand::response() bez żadnego usuwania pól ani listy dozwolonych. Nisko uprzywilejowany uwierzytelniony klient API może pobrać klucze prywatne certyfikatów swoich domen, w tym klucze Let's Encrypt generowane przez Froxlor po stronie serwera i przechowywane z uprawnieniami root-only (0600), do których klient nie ma dostępu do systemu plików; konta reseller i customers_see_all admin mogą zrzucić klucze prywatne innych podmiotów przez ten sam mechanizm. Ujawnione klucze umożliwiają podszywanie się pod domenę, pasywne deszyfrowanie przechwyconego ruchu TLS oraz aktywne ataki typu man-in-the-middle.

Kyverno w wersjach przed 1.19.1 zawiera lukę pozwalającą na obejście izolacji przestrzeni nazw w wpisie kontekstu apiCall dla zasobów Policy z ograniczeniem do namespace. Wynika to z niespójnej interpretacji ścieżek między walidacją a wykonaniem. Użytkownik o niskich uprawnieniach może użyć procentowo zakodowanych segmentów kropek w urlPath, aby ominąć sprawdzanie przestrzeni nazw i odczytać zasoby z innych namespace przy użyciu poświadczeń ServiceAccount kontrolera Kyverno.

Kyverno przed wersją 1.19.1 nieprawidłowo waliduje zakodowane w URL segmenty ścieżki w apiCall urlPath polityki, co pozwala tenantom namespace'ów ominąć ograniczenia per-namespace i tworzyć obiekty w innych namespace'ach jako ServiceAccount kontrolera admission. Atakujący mogą wykorzystać percent-encoded sekwencje traversal katalogów do tworzenia obiektów MutatingWebhookConfiguration w całym klastrze lub obiektów PolicyException w namespace kyverno, co umożliwia eskalację uprawnień do administratora klastra.

Kyverno przed wersją 1.19.1 jest podatny na SSRF. Domyślna lista blokowania egress (169.254.169.254, 169.254.169.253, metadata.google.internal, 127.0.0.0/8, ::1/128) i kontrola tokenów z ograniczonym zakresem były podłączone tylko do nowej biblioteki CEL http.Get/Post, ale nie do starszego executor usług apiCall (pkg/engine/apicall/executor.go) ani do ścieżki GlobalContextEntry external-API. Te ścieżki używają zwykłego klienta net/http bez filtrowania egress i bez walidacji adresu URL usługi, co pozwala autorowi ClusterPolicy lub GlobalContextEntry (lub osobie przesyłającej zasoby, jeśli polityka używa szablonu URL) na wysyłanie żądań GET/POST do dowolnego hosta, w tym do punktu metadanych chmury, loopback i usług wewnątrz klastra. Executor bezwarunkowo dołącza token ServiceAccount Kyverno do wybranego przez atakującego miejsca docelowego. Naprawiono w wersji 1.19.1.

Kyverno to silnik polityk dla Kubernetes. W wersjach od 1.14.0 do 1.19.0 evaluator ImageValidatingPolicy nigdy nie odczytuje pól spec.images i spec.allowedValues z PolicyException. Każdy PolicyException, którego policyRefs i matchConditions pasują do zasobu, powoduje pominięcie weryfikacji podpisu obrazu dla całego zasobu, a nie tylko dla wymienionych obrazów lub wartości. W rezultacie niepodpisane lub niezaufane obrazy mogą być dopuszczone do klastra bez weryfikacji podpisu. Różni się to od ValidatingPolicy, GeneratingPolicy i MutatingPolicy, które traktują to samo pole jako częściowe wyłączenie. Problem naprawiono w wersji 1.19.1.

Kyverno w wersjach od 1.16.0 do 1.19.0 rejestruje bibliotekę globalcontext.Lib CEL w środowisku polityk bez ograniczania jej do przestrzeni nazw polityki, w przeciwieństwie do bibliotek pokrewnych, które otrzymują przestrzeń nazw polityki. Tenant mogący tworzyć polityki z ograniczeniem do namespace w swoim namespace może wywołać globalContext.get("<entry>", "") i otrzymać pełną zawartość buforowanego GlobalContextEntry o zasięgu klastra, w tym dane z przestrzeni nazw, do których tenant nie ma uprawnień RBAC. Brak walidacji przyjęcia odrzucającej takie wywołania. Naprawiono w 1.19.1.

Nodemailer przed wersją 10.0.2 nie spłaszcza poprawnie głęboko zagnieżdżonych tablic w polach odbiorców, takich jak to, cc i bcc, co pozwala atakującym spowodować wyczerpanie stosu. Atakujący może dostarczyć głęboko zagnieżdżoną tablicę JSON odbiorców, która wyzwala rekurencyjną konwersję Array.toString(), wyczerpując stos i kończąc proces Node.js.

Nodemailer w wersjach 5.0.0 do 10.0.1 używa globalnej pamięci podręcznej DNS, która jest kluczowana tylko przez host DNS, podczas gdy każdy wpis pamięci podręcznej przechowuje również specyficzny dla wywołującego serwer TLS (servername). Gdy dwa transporty direct TLS/SMTPS (secure: true) rozwiązują ten sam host nie-IP z różnymi wartościami tls.servername, servername pierwszego transportu jest zwracane przy trafieniu w pamięć podręczną i nadpisuje jawnie skonfigurowaną wartość drugiego transportu, więc Nodemailer wysyła błędną wartość SNI i waliduje certyfikat peera względem błędnej tożsamości. W usługach wielodostępnych lub bramkach SMTP z routingiem SNI, atakujący, który może zainicjować pamięć podręczną, może spowodować, że transport ofiary połączy się z wirtualnym hostem TLS atakującego i zaakceptuje certyfikat atakującego nawet przy rejectUnauthorized: true, ujawniając poświadczenia SMTP ofiary. Naprawione w 10.0.2.

nodemailer w wersjach przed 10.0.6 zawiera podatność typu denial of service w wyrażeniu regularnym fallbacku free-text parsera adresów, które wykazuje kwadratowe zachowanie backtrackingu. Atakujący mogą dostarczyć spreparowane wartości nagłówków e-mail z długimi ciągami bez spacji, aby zablokować pętlę zdarzeń Node.js na dziesiątki sekund, powodując niedostępność usługi.