Podatność w bibliotece gRPC-Go (implementacja gRPC w języku Go) pozwala atakującemu na ominięcie reguł autoryzacji poprzez przesłanie żądania z nieprawidłowo sformowanym nagłówkiem HTTP/2 `:path` (bez wiodącego ukośnika). Jest to krytyczna luka, ponieważ umożliwia nieautoryzowany dostęp do chronionych zasobów bez żadnych uprawnień i bez interakcji użytkownika.
▸ Pokaż oryginał (EN)
gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 `:path` pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present. This affects gRPC-Go servers that use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`; AND that have a security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server. The fix in version 1.79.3 ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string. While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods: Use a validating interceptor (recommended mitigation); infrastructure-level normalization; and/or policy hardening.
Serwer gRPC-Go akceptował żądania, w których nagłówek pseudo-nagłówkowy HTTP/2 `:path` nie zawierał obowiązkowego wiodącego ukośnika (np. `Service/Method` zamiast `/Service/Method`). Serwer poprawnie kierował takie żądania do właściwego handlera, jednak interceptory autoryzacji (w tym oficjalny pakiet `grpc/authz`) porównywały surową, nieznormalizowaną ścieżkę z regułami zdefiniowanymi dla ścieżek kanonicznych (zaczynających się od `/`). W efekcie reguły "deny" nie dopasowywały się do przychodzącego żądania, a jeśli polityka zawierała domyślną regułę "allow", żądanie było przepuszczane z pominięciem kontroli dostępu. Atak jest możliwy przez bezpośrednie wysyłanie surowych ramek HTTP/2 z celowo zniekształconym nagłówkiem `:path` do serwera gRPC.
Atakujący bez żadnych uprawnień może ominąć reguły autoryzacji opartej na ścieżkach (w tym RBAC), uzyskując nieautoryzowany dostęp do chronionych metod gRPC oraz potencjalnie modyfikując dane lub odczytując poufne informacje (wysoki wpływ na poufność i integralność).
Należy zaktualizować gRPC-Go do wersji 1.79.3 lub nowszej — poprawka odrzuca wszystkie żądania z nagłówkiem `:path` nierozpoczętym od ukośnika zwracając błąd `codes.Unimplemented`. Jako tymczasowe środki zaradcze (do czasu aktualizacji) można zastosować: walidujący interceptor weryfikujący format ścieżki, normalizację ścieżek na poziomie infrastruktury (np. proxy/load balancer) lub wzmocnienie polityki autoryzacji poprzez usunięcie domyślnej reguły "allow".
Biblioteka gRPC-Go (google.golang.org/grpc) w wersjach wcześniejszych niż 1.79.3. Podatność dotyczy serwerów używających interceptorów autoryzacji opartych na ścieżkach (np. oficjalnego pakietu `google.golang.org/grpc/authz` lub własnych interceptorów korzystających z `info.FullMethod` / `grpc.Method(ctx)`), które posiadają politykę z regułami "deny" dla ścieżek kanonicznych oraz domyślną regułą "allow".
Podatność wymaga jednoczesnego spełnienia dwóch warunków: użycia interceptora autoryzacji opartego na ścieżkach ORAZ posiadania polityki z regułami "deny" dla ścieżek kanonicznych i domyślną regułą "allow". Serwery bez path-based authorization lub bez domyślnej reguły "allow" nie są podatne. Szczegóły dostępne w GitHub Security Advisory GHSA-p77j-4mvh-x3m3.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:NGrpc
APPGrpc< 1.79.3
Powiązane podatności
Google gRPC before 2017-04-05 has an out-of-bounds write caused by a heap-based buffer overflow related to cor...
Google gRPC before 2017-03-29 has an out-of-bounds write caused by a heap-based use-after-free related to the ...
Google gRPC before 2017-02-22 has an out-of-bounds write caused by a heap-based buffer overflow related to the...
Google gRPC before 2017-02-22 has an out-of-bounds write related to the gpr_free function in core/lib/support/...
Lack of error handling in the TCP server in Google's gRPC starting version 1.23 on posix-compatible platforms ...