Vulnerabilidades na biblioteca Valve Game Networking Sockets atingem a remontagem de mensagens fragmentadas e podem afetar clientes, servidores de jogos e jogadores conectados.
| Componente | Valve Game Networking Sockets, também conhecida como Steam Sockets, biblioteca de rede usada por jogos da Valve e títulos de terceiros. |
| Vetor | Mensagens fragmentadas enviadas para o mecanismo de remontagem, com manipulação do deslocamento de segmento em um caminho que mistura interpretação sem sinal e sinalizada. |
| Impacto | Travamento remoto de cliente de jogo, travamento de servidor da Valve em algumas condições e, em jogos de terceiros, possível tomada de servidor para execução de código arbitrário. |
| Prioridade | Atualizar integrações que usam a biblioteca afetada, revisar servidores baseados em Steam Sockets e monitorar falhas anormais associadas a mensagens fragmentadas. |
| Versões | O contexto identifica quatro vulnerabilidades entre CVE-2020-6016 e CVE-2020-6019, sem listar números de versão afetados. |
| Artefatos | CVE-2020-6016 envolve um Heap-Based Buffer Underflow acionado durante a remontagem de segmentos confiáveis ou não confiáveis. |
A análise identifica quatro vulnerabilidades na implementação da biblioteca Valve Game Networking Sockets, conhecida no ecossistema de jogos como Steam Sockets. A biblioteca é usada como camada de rede em títulos da própria Valve, incluindo CS:GO, Dota 2 e Team Fortress 2, e também aparece em jogos de terceiros, como Destiny 2. O componente foi aberto em 2018 e passou a integrar o Steamworks SDK no ano seguinte, ampliando o alcance da infraestrutura de relé de rede da Valve para desenvolvedores externos. O ponto central da pesquisa é que uma falha em um componente comum de rede pode deixar de ser apenas um defeito local de jogo e se tornar uma superfície compartilhada entre clientes, servidores e motores de terceiros.
O conjunto de falhas foi registrado como CVE-2020-6016 a CVE-2020-6019. Entre elas, CVE-2020-6016 recebe destaque por atingir a remontagem de mensagens fragmentadas, uma área sensível porque precisa combinar múltiplos pedaços recebidos pela rede, respeitar comprimento, deslocamento e ordem, e entregar ao motor do jogo uma mensagem lógica íntegra. O defeito nasce de uma incompatibilidade de interpretação: um deslocamento de segmento é lido inicialmente como valor sem sinal, mas depois é processado por uma função que o trata como inteiro assinado de 32 bits. Quando um valor grande o suficiente atravessa esse limite, ele pode ser interpretado como número negativo e deslocar a escrita para antes do buffer reservado para a mensagem.
O impacto descrito varia conforme o papel do sistema atingido e a forma de integração da biblioteca. Em partidas contra adversários on-line, um invasor poderia travar remotamente o cliente do oponente, produzindo uma condição de negação de serviço no processo do jogo. Em algumas condições, o defeito também permitiria travar um servidor de jogo da Valve, afetando mais participantes da partida. Em jogos desenvolvidos por terceiros, a consequência mais severa descrita é a possibilidade de assumir o servidor e executar código arbitrário; depois disso, a mesma classe de falha poderia ser usada contra jogadores conectados ao servidor comprometido. Esses efeitos dependem do caminho de execução da biblioteca, do ambiente de compilação e do uso do componente pelo jogo.
Steam Sockets oferece comunicação ponto a ponto e também um modo centralizado cliente-servidor. A biblioteca estabelece um canal criptografado por meio de um protocolo de handshake próprio da Valve. As mensagens de negociação usam protobuf, o que reduz a exposição a falhas clássicas de parsing em estruturas complexas. Durante o handshake, cliente e servidor verificam identidades com certificados assinados, anunciam esquemas criptográficos suportados e negociam um segredo por Elliptic-Curve Diffie-Hellman. O segredo derivado é usado para gerar uma chave AES-256 compartilhada, que protege a comunicação depois que a negociação termina. A vulnerabilidade descrita não está nesse handshake criptográfico, mas em uma etapa posterior, quando mensagens de aplicação são divididas e remontadas.
A biblioteca aceita mensagens do tipo confiável, com reconhecimento e correção de perda, e mensagens não confiáveis, mais próximas de datagramas enviados sem garantia de entrega. Como o limite de transmissão por mensagem no fio é de 1300 bytes, uma mensagem lógica maior pode ser dividida em segmentos. Cada segmento carrega atributos como número da mensagem e deslocamento, permitindo que a biblioteca reúna os pedaços recebidos e entregue uma única mensagem ao motor do jogo. Essa remontagem é uma operação propensa a erro porque qualquer desvio na validação de offset, tamanho ou presença de lacunas pode transformar dados de rede em escrita fora dos limites esperados.
Em CVE-2020-6016, o deslocamento do segmento é lido em uma variável sem sinal e depois repassado a SNP_ReceiveUnreliableSegment, onde é tratado como inteiro assinado de 32 bits. Um valor suficientemente alto sofre interpretação diferente no segundo estágio e passa a representar um deslocamento negativo. O resultado é que a rotina de remontagem pode posicionar o fragmento antes do início do buffer destinado à mensagem lógica, criando uma condição de Heap-Based Buffer Underflow. A falha não é descrita como simples corrupção imediata em todos os casos, porque a implementação ainda mantém estruturas de controle para acompanhar segmentos e lacunas antes de concluir a remontagem.
Os segmentos são armazenados em uma estrutura associativa por uma chave formada por campos que identificam a mensagem e o offset. A biblioteca acumula os segmentos até concluir que todas as partes necessárias estão presentes. A lógica de verificação percorre os segmentos conhecidos e busca lacunas antes de remontar a mensagem. O problema adicional observado é que a busca natural da tabela começa em offset zero e avança, não procurando diretamente um deslocamento negativo. Isso impede um caminho trivial de exploração, mas deixa o programa em um estado inconsistente: a verificação passa a operar sobre um iterador vazio ou sobre o elemento end() de uma estrutura C++, tratando dados próximos em memória como se fossem um segmento válido.
No ambiente analisado, a exploração explorou detalhes de implementação de iteradores C++ e da forma como o GCC representa estruturas como std::map em uma árvore balanceada. O elemento end() funciona como marcador depois do último elemento lógico, mas internamente pode se traduzir em ponteiros relacionados à estrutura do contêiner. Ao acessar campos de um item inexistente, o código passa a interpretar memória adjacente como se fosse um par chave-valor de segmento. A condição de exploração descrita assume um servidor Linux de 64 bits compilado com GCC e exige que o fluxo confiável alcance uma posição específica próxima de 4 GB, permitindo que o valor desejado seja interpretado como negativo em complemento de dois. A descrição técnica confirma que a falha foi acionada de modo confiável como Heap-Based Buffer Underflow, sem exigir a publicação de comandos operacionais ou payloads reproduzíveis.
A superfície afetada é ampla porque o componente vulnerável fica abaixo da lógica específica de cada jogo. A biblioteca é usada por jogos da Valve e por títulos de terceiros que optaram por integrar Steam Sockets para aproveitar comunicação de baixa latência, proteção contra negação de serviço e relés de rede. O defeito, portanto, não se limita à interface gráfica de um jogo ou a uma função de matchmaking; ele aparece em uma camada de transporte de mensagens que decide como fragmentos são aceitos, armazenados, validados e remontados. Sistemas que processam tráfego de jogadores remotos, especialmente servidores que aceitam conexões de clientes não confiáveis, representam a área de maior atenção.
O risco muda conforme o papel do alvo. Em um cliente de jogo, a consequência documentada é travamento remoto quando um adversário consegue acionar a cadeia durante uma partida. Em um servidor da Valve, o contexto descreve travamento em algumas condições, o que caracteriza indisponibilidade para todos os jogadores daquela sessão. Em servidores de jogos de terceiros, a consequência mais grave é a execução de código arbitrário após tomada do servidor, seguida da possibilidade de atingir jogadores conectados. Esse encadeamento deve ser tratado como risco condicionado ao uso específico da biblioteca e ao caminho de código presente no servidor, não como garantia universal para todo jogo que mencione Steam Sockets.
A existência de criptografia no canal não elimina a falha porque a corrupção ocorre depois que as partes já estabeleceram a sessão e a biblioteca passa a processar mensagens internas do protocolo. O handshake com certificados e AES-256 protege confidencialidade e autenticação do canal, mas não substitui validação de limites em estruturas de remontagem. Do ponto de vista defensivo, isso significa que a exposição não deve ser avaliada apenas por firewall, TLS equivalente ou presença de canal criptografado. A pergunta operacional correta é se o binário em produção incorpora a versão vulnerável da biblioteca e se aceita mensagens fragmentadas de pares remotos.
O contexto não fornece números de versão afetados, builds específicos do Steamworks SDK ou lista completa de jogos vulneráveis. Essa ausência impede afirmar que um título específico, fora dos exemplos citados, permaneça vulnerável em determinada versão. A triagem deve partir do inventário interno de servidores e clientes que incorporam Valve Game Networking Sockets, da origem do código usado na compilação e da data de atualização do SDK ou da biblioteca aberta.
- Servidores Linux de 64 bits compilados com GCC fazem parte do cenário de exploração detalhado para
CVE-2020-6016. - Jogos que usam Steam Sockets em modo cliente-servidor ficam expostos ao processamento remoto de segmentos por clientes conectados.
- Clientes de jogos podem ser impactados quando recebem tráfego de rede capaz de atravessar o caminho vulnerável de remontagem.
- O contexto cita CS:GO, Dota 2, Team Fortress 2 e Destiny 2 como exemplos de adoção da biblioteca, sem declarar versões vulneráveis desses jogos.
A investigação defensiva deve focar sintomas de processamento anômalo de mensagens fragmentadas, especialmente quedas de processo ligadas a partidas on-line, servidores com encerramento inesperado e clientes que travam durante interação com pares remotos. Como o defeito envolve remontagem de segmentos e manipulação de offsets, logs de aplicação que registrem erros de rede, falhas de assert, exceções de memória, encerramentos por sinal e dumps de processo são mais úteis do que indicadores tradicionais de infraestrutura. O contexto não traz domínios, IPs, hashes ou infraestrutura de comando e controle; portanto, caçar por IoCs de rede seria uma abordagem artificial para este caso.
Em servidores dedicados, operadores devem correlacionar crashes com padrões de sessão: entrada de jogadores pouco antes da falha, aumento incomum de mensagens fragmentadas, desconexões simultâneas e repetição do problema contra o mesmo binário. Quando houver dumps de memória, a análise deve observar se a pilha de chamadas passa por funções de recepção de segmentos, estruturas de remontagem ou código relacionado a mensagens confiáveis e não confiáveis. Em clientes, telemetria de endpoint pode apontar travamentos repetidos do executável do jogo durante partidas específicas, mas a confirmação exige vincular o crash ao módulo de rede e não apenas ao motor gráfico ou a drivers.
Para ambientes com pipeline próprio de jogos de terceiros, a caça deve incluir revisão de dependências e símbolos do binário. A presença de Game Networking Sockets em servidores customizados, motores baseados em Unreal com integração a Steam Sockets ou builds que carregam a biblioteca vulnerável deve acionar revisão de atualização. Em repositórios, é importante identificar commits ou pacotes do Steamworks SDK usados na compilação, já que a biblioteca foi incorporada ao SDK em 2019 e pode ter sido vendorizada em projetos que não atualizam dependências com frequência.
A telemetria de rede pode ajudar por volume e forma, não por assinatura de payload. Um fluxo confiável que cresce até posições muito altas, próximo ao limite descrito de quase 4 GB de dados, pode ser anormal para uma sessão comum de jogo, dependendo do título. Esse sinal deve ser usado com cuidado para evitar falsos positivos, porque jogos podem trafegar volume alto de dados em algumas condições. O valor defensivo está na combinação entre volume incomum, fragmentação, crash subsequente e binário vulnerável, não em um único contador isolado.
- Crashes de cliente ou servidor associados a rotinas de recepção e remontagem de segmentos da biblioteca.
- Sessões com volume excepcional de dados confiáveis antes de falhas de processo.
- Dumps apontando Heap-Based Buffer Underflow ou corrupção de heap perto de estruturas de remontagem.
- Servidores de terceiros com builds antigos de Steam Sockets ou Steamworks SDK incorporado ao projeto.
- Repetição de travamentos após conexão de um mesmo par remoto ou durante partidas contra adversários específicos.
A resposta começa por inventariar onde Valve Game Networking Sockets está presente. Equipes responsáveis por jogos, servidores dedicados, backends de matchmaking e builds de clientes devem mapear se a biblioteca é usada diretamente, via Steamworks SDK ou por integração de motor. Como o contexto não fornece versões afetadas, a medida prática é comparar o código ou SDK em uso com as correções disponibilizadas pelo fornecedor do componente e reconstruir binários que carreguem a implementação corrigida. Projetos que vendorizam a biblioteca precisam evitar a falsa sensação de atualização apenas porque o ambiente Steam foi atualizado separadamente.
Na correção de engenharia, a área crítica é a validação de offsets e tamanhos antes de qualquer cópia para buffers de remontagem. Um deslocamento recebido pela rede não deve atravessar conversões entre tipos sem checagem explícita de faixa, e o cálculo do destino de escrita precisa rejeitar valores negativos, estouros inteiros e combinações de offset mais tamanho que ultrapassem o buffer lógico. A rotina que decide se todos os segmentos estão presentes também precisa lidar corretamente com iteradores vazios e com o elemento end(), sem tratar memória adjacente como segmento válido. Essas recomendações são princípios defensivos derivados da falha descrita, não instruções de exploração.
No plano operacional, servidores expostos devem ser atualizados antes de clientes sempre que atuarem como ponto central para múltiplos jogadores. Um servidor comprometido ou instável amplia o impacto porque concentra sessões e pode encaminhar a falha para jogadores conectados. Depois da atualização, operadores devem revisar logs históricos de crash para identificar se houve exploração anterior ou tentativas de acionamento. A prioridade deve ser maior para jogos de terceiros que aceitam tráfego de clientes não confiáveis e que rodam em Linux de 64 bits com builds compatíveis com o cenário descrito de exploração.
A contenção temporária, quando a atualização imediata não for possível, deve reduzir exposição sem depender de payloads específicos. Isso inclui limitar acesso a servidores de teste, restringir partidas privadas a usuários conhecidos, monitorar reinícios anormais, coletar dumps para análise e remover de produção binários que apresentem falhas repetidas durante processamento de rede. Essas medidas não substituem a correção da biblioteca, mas reduzem a janela em que mensagens fragmentadas malformadas podem atingir processos críticos.
Depois da remediação, a validação deve incluir testes negativos de remontagem: segmentos fora de ordem, offsets extremos, lacunas, duplicações e mensagens que excedem limites esperados. O objetivo é confirmar que o parser rejeita entradas inconsistentes sem travar e sem escrever fora de limites. Também é recomendável ativar proteções de compilação e diagnóstico de memória nos ambientes de teste, porque falhas de heap podem permanecer silenciosas até se manifestarem como corrupção posterior. Para produção, métricas de estabilidade por versão do binário ajudam a confirmar se a atualização reduziu crashes associados à camada de rede.
- Inventariar jogos, servidores e clientes que incorporam Valve Game Networking Sockets ou Steamworks SDK.
- Atualizar a biblioteca ou reconstruir binários com a implementação corrigida pelo fornecedor.
- Priorizar servidores de terceiros que aceitam tráfego remoto de jogadores e concentram múltiplas sessões.
- Monitorar travamentos, dumps e reinícios associados a rotinas de remontagem de mensagens.
- Adicionar testes de limite para offsets, comprimentos, lacunas e duplicação de segmentos.
0 Comentários