Paulo Valente

Um invasor não autenticado pode causar exaustão de memória e travar o nó enviando um corpo de requisição excessivamente grande via streaming do cliente ou streaming bidirecional. O problema ocorre porque o caminho de leitura de streaming em `Elixir.GRPC.Server.Adapters.Cowboy.Handler`:info/3 não impõe o limite `max body size`, ao contrário do caminho de leitura unária. Especificamente, `Elixir.GRPC.Server.Adapters.Cowboy`:reading stream/1 anexa os chunks recebidos a um buffer até que uma mensagem completa com prefixo de comprimento seja formada. Ao declarar uma mensagem muito grande e enviá-la através de múltiplos frames DATA HTTP/2 pequenos, um invasor pode forçar o buffer a crescer sem limite, levando à exaustão de memória do BEAM e ao travamento completo do nó.

Atacantes autenticados podem acessar ou modificar recursos pertencentes a outros usuários ao contrabandear um valor conflitante para qualquer campo vinculado ao caminho via string de consulta ou corpo da requisição. Isso ocorre na função `map request/5` em `Elixir.GRPC.Server.Transcode` (lib/grpc/server/transcode.ex), onde `Map.merge/2` é utilizado com vinculações de caminho como o primeiro argumento, atribuindo-lhes a menor precedência de mesclagem. Consequentemente, uma requisição como 'GET /users/me/profile?user id=victim' ou uma requisição POST contendo `user id` no corpo resulta em uma estrutura protobuf decodificada onde o campo vinculado ao caminho é sobrescrito pelo valor fornecido pelo atacante. Isso permite a evasão de manipuladores que utilizam esses campos para autorização, verificações de propriedade ou escopo de multi-tenancy. Este problema requer que a transcodificação HTTP-para-gRPC esteja habilitada.

Atacantes não autenticados podem esgotar a memória do BEAM e travar o servidor ao transmitir um corpo de requisição unária grande ou em fluxo lento (slow-trickle). A função `read full body/3` em 'Elixir.GRPC.Server.Adapters.Cowboy.Handler' acumula cada chunk recebido em um único binário crescente sem limite de tamanho. Além disso, quando o cliente omite o cabeçalho `grpc-timeout`, o tempo limite de leitura por chunk é definido como infinito, permitindo que um cliente de fluxo lento mantenha a conexão indefinidamente enquanto a memória cresce. Uma única conexão é suficiente para esgotar a memória do servidor e travar o nó.

O manuseio inadequado de dados altamente compactados nos módulos `GRPC.Compressor.Gzip` e `GRPC.Message` permite a negação de serviço por meio de uma bomba de descompressão gzip. A função `decompress/1` em `Elixir.GRPC.Compressor.Gzip` chama `:zlib.gunzip/1` em bytes controlados por um invasor sem limite de tamanho descompactado, verificação de proporção ou decodificação incremental. Isso ocorre automaticamente quando um frame gRPC recebido contém o cabeçalho `grpc-encoding: gzip`. Como o `:zlib.gunzip/1` aloca todo o resultado descompactado como um único binário, uma carga útil pequena e altamente compressível pode expandir-se para vários gigabytes, esgotando o heap do nó BEAM e causando a interrupção por falta de memória (out-of-memory kill). O limite `max receive message length` é ineficaz, pois é aplicado apenas após a descompressão. Isso pode ser explorado por um peer remoto não autenticado utilizando a função `from data/2` em `Elixir.GRPC.Message`.

A desserialização de dados não confiáveis e a alocação de recursos sem limites ou controle permitem que atacantes não autenticados causem a queda do nó BEAM ou alcancem a execução remota de código no servidor. A função `decode/2` em `Elixir.GRPC.Codec.Erlpack` chama `:erlang.binary to term/1` no corpo da mensagem gRPC bruta sem a opção `:safe`, sem limites de tamanho e sem guardas de tipo. Um peer não autenticado que envie uma requisição com `Content-Type: application/grpc+erlpack` pode enviar um payload manipulado para criar novos átomos arbitrários, que não são coletados pelo garbage collector, resultando na exaustão da tabela de átomos e no travamento da VM. Além disso, o payload pode codificar um termo fun que, se aplicado posteriormente, executa código controlado pelo atacante dentro do processo do servidor. Este problema ocorre quando o `GRPC.Codec.Erlpack` é explicitamente registrado como um codec no servidor gRPC.