Neil Berkman

Um invasor pode ler os caminhos do sistema de arquivos de uma aplicação através da configuração do Tidewave. Isso ocorre porque o servidor não valida o cabeçalho `Host` e a função `check origin()` aceita requisições que não possuem um cabeçalho `Origin`. Uma página web maliciosa pode usar DNS rebinding para redirecionar seu domínio para o endereço de loopback e realizar uma requisição de mesma origem para recuperar informações sensíveis. Os dados expostos, que incluem o nome de usuário local e o layout do projeto, são vazados através do endpoint `/tidewave/connect` ou através da barra de ferramentas renderizada e injetada em respostas HTML pela função `Tidewave.call()`. Especificamente, a função `Tidewave.tidewave config meta/1` coleta dados como `root`, `framework.app paths`, `wsl distro` e `host path` e os insere em uma tag meta.

Um invasor remoto não autenticado pode esgotar a memória do servidor enviando quadros DATA que excedem a janela de recebimento anunciada na implementação HTTP/2. O invasor pode solicitar uma resposta maior que a janela inicial de 65.535 bytes e reter o `WINDOW UPDATE`, fazendo com que o processo de fluxo bloqueie durante o envio e pare de ler. Subsequentemente, a inundação de pequenos quadros DATA nesse fluxo faz com que cada quadro seja enfileirado na caixa de correio do fluxo até que o nó BEAM fique sem memória. Isso ocorre porque a função `Bandit.HTTP2.Connection.handle frame/3` encaminha os quadros DATA para o processo de fluxo sem consultar a janela de recebimento, e a função `Bandit.HTTP2.FlowControl.compute recv window/2` reabastece a janela conforme os dados chegam, em vez de quando são consumidos, não disparando um `FLOW CONTROL ERROR` em caso de violação.

Um invasor remoto não autenticado pode expor a base da chave secreta ou outros segredos sensíveis através dos logs da aplicação ao fornecer argumentos com tipos incorretos. Isso ocorre porque as funções públicas em `Plug.Crypto` utilizam guards no cabeçalho da função para validação de argumentos. Quando um guard falha, a VM Erlang levanta um `FunctionClauseError` que inclui os valores reais dos argumentos no frame superior da pilha. Como os blocos `rescue` da biblioteca e a função `Plug.Crypto.prune args from stacktrace/1` apenas lidam com exceções levantadas dentro do corpo de uma função, eles não capturam falhas de guard. Consequentemente, o Plug.Cowboy e o Bandit escrevem este frame no log de erros e o anexam como metadados de `crash reason`, que podem ser encaminhados para rastreadores de erros. Dois pontos de entrada principais são afetados: - `Plug.Crypto.verify/4` expõe a base da chave secreta quando o token não é nem um binário nem nulo. - `Plug.Crypto.secure compare/2` expõe o segredo do lado do servidor quando um operando não é um binário, como ocorre quando um cabeçalho de requisição ausente resulta em um valor nulo. O acesso às informações vazadas requer acesso separado aos logs da aplicação ou ao rastreador de erros.

A validação inadequada de certificados no cliente de streaming WebSocket permite que um invasor no caminho da rede leia e modifique sessões do WebSocket da OpenAI, incluindo o token de portador `authorization`. A função `ReqLLM.Streaming.WebSocketSession.Client.start/3` em `lib/req llm/streaming/web socket session/client.ex` inicia o WebSockex sem opções de TLS. Como o WebSockex assume por padrão `insecure: true`, ele se conecta usando `verify: :verify none`, o que aceita qualquer certificado. Além disso, a lista de permissões de opções descarta `cacerts` ou `ssl options` fornecidos pelo chamador, impedindo que as aplicações ativem a verificação. Isso afeta os caminhos de WebSocket do OpenAI Responses, Realtime e Codex, que transmitem chaves de API ou tokens de acesso OAuth no cabeçalho `authorization`.