W Eclipse Jetty komponent serwera obsługujący uwierzytelnianie Digest koduje hasło przy użyciu ISO-8859-1, co powoduje ciche zastępowanie znaków spoza tego zestawu (np. cyrylicy, greki, chińskiego) znakami zapytania `?`. Atakujący może wykorzystać ten mechanizm do uwierzytelnienia się na koncie użytkownika bez znajomości rzeczywistego hasła.
▸ Pokaż oryginał (EN)
In Eclipse Jetty, the Digest authentication server-side component uses ISO-8859-1 to encode the password as bytes. This was done because the initial specification for HTTP did not specify explicitly a charset, and it was assumed to be ISO-8859-1 for historical reasons. If the password contains characters that cannot be represented in ISO-8859-1, they are silently replaced by `?`. This happens with passwords that contain Chinese, Cyrillic or Greek characters, for example: `αβ123` converts to `??123`. An attacker can send a request with a digest `Authorization` header crafted with a password made of only `?` characters; the server would match any password of the same length that contains non-ISO-8859-1 characters. Recent HTTP Digest [RFC-7616](https://datatracker.ietf.org/doc/html/rfc7616) supports a `charset` parameters that defaults to UTF-8 that allows for correct encoding/decoding of passwords.
Serwer Jetty podczas weryfikacji poświadczeń w Digest authentication konwertuje hasło do bajtów przy użyciu kodowania ISO-8859-1. Znaki, których nie można reprezentować w tym kodowaniu (np. `α`, `β`, znaki cyrylicy), są po cichu zamieniane na znak `?`. Atakujący, wiedząc o tej właściwości, może spreparować nagłówek `Authorization` z hasłem złożonym wyłącznie ze znaków `?` o odpowiedniej długości. Serwer zaakceptuje takie żądanie, ponieważ przekształcone hasło ofiary będzie identyczne z hasłem atakującego po stronie serwera.
Atakujący nieposiadający rzeczywistego hasła może uzyskać nieautoryzowany dostęp do konta użytkownika, którego hasło zawiera znaki spoza zestawu ISO-8859-1, skutecznie omijając mechanizm uwierzytelniania Digest.
Należy zastosować patche dostępne u producenta zgodnie z referencjami. Zgodnie z opisem, prawidłowym rozwiązaniem jest wsparcie parametru `charset` w RFC-7616 z domyślnym UTF-8, co zapewnia poprawne kodowanie haseł. Jako obejście należy rozważyć zmianę haseł użytkowników na takie, które zawierają wyłącznie znaki z zestawu ISO-8859-1, lub zastąpienie Digest authentication innym mechanizmem uwierzytelniania.
Eclipse Jetty — wersje wskazane w referencjach producenta (dotyczy konfiguracji wykorzystujących Digest authentication z hasłami zawierającymi znaki spoza zestawu ISO-8859-1)
Podatność sklasyfikowana jako CWE-173 (Improper Handling of Alternate Encoding) oraz CWE-303 (Incorrect Implementation of Authentication Algorithm). Atak możliwy jest bez uwierzytelnienia, bez interakcji użytkownika i przez sieć (AV:N), co potwierdza wektor CVSS 4.0.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/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:XEclipse Jetty
APPEclipse9.4.0 – 9.4.63 (bez)10.0.0 – 10.0.31 (bez)11.0.0 – 11.0.31 (bez)12.0.0 – 12.0.36 (bez)12.1.0 – 12.1.10 (bez)
Powiązane podatności
Eclipse Jetty: wyciek danych między sesjami przez double-release ByteBuffer
Eclipse Jetty: integer overflow w parsowaniu chunk length — obejście autoryzacji
Eclipse Jetty — pominięcie autoryzacji przez HTTP Request Smuggling
Eclipse Jetty: ominięcie zabezpieczeń przez nieprawidłową normalizację ścieżek URL (Windows)
The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can ...