CVE-2021-28235

etcd to rozproszony magazyn klucz-wartość dla danych systemów rozproszonych. Przed wersjami 3.5.33, 3.6.14 i 3.7.1, atakujący sieciowo, który może dotrzeć do nasłuchującego TLS, może otworzyć wiele połączeń TCP i nigdy nie wysłać ClientHello. W client/pkg/transport/listener_tls.go, każde połączenie obsługiwane przez tlsListener.acceptLoop tworzy gorutynę, która blokuje się w nieskończoność wewnątrz tls.Conn.Handshake() i pozostaje śledzona w mapie oczekujących. Nieograniczony wzrost gorutyn i mapy może wyczerpać pamięć procesu etcd, powodując utratę dostępności klastra, a gdy etcd obsługuje Kubernetes, również płaszczyzny sterowania. Problem naprawiono w wersjach 3.5.33, 3.6.14 i 3.7.1.

etcd to rozproszony magazyn klucz-wartość dla danych systemów rozproszonych. Przed wersjami 3.5.33, 3.6.14 i 3.7.1, użytkownik z uprawnieniami READ do pojedynczego klucza może użyć interfejsu Watch gRPC z clientv3.WithFromKey(), aby otrzymywać zdarzenia watch dla każdego klucza leksykograficznie większego lub równego dozwolonemu kluczowi. W server/etcdserver/api/v3rpc/watch.go, otwarty znacznik RangeEnd jest przepisywany przed sprawdzeniem uprawnień RBAC w funkcji isRangeOpPermitted w server/auth/range_perm_cache.go, co powoduje, że żądanie jest traktowane jako watch dokładnego klucza. Żądania Range/Get i DeleteRange nie są dotknięte, a problem dotyczy tylko klastrów z włączonym uwierzytelnianiem. Problem naprawiono w wersjach 3.5.33, 3.6.14 i 3.7.1.

W etcd przed wersjami 3.5.32 i 3.6.13, gdy skonfigurowano osobne nasłuchiwacze dla HTTP i gRPC za pomocą --listen-client-http-urls, lista CRL (Certificate Revocation List) nie była wymuszana na nasłuchiwaczu gRPC. Umożliwiało to klientowi z odwołanym certyfikatem pomyślne uwierzytelnienie przez gRPC.