O lançamento 3.38.1 aponta para https://github.com/syslog-ng/syslog-ng/pull/4110, que inclui testes de unidade e diversas validações para prevenir variantes semelhantes deste bug.

A issue original inclui uma depuração útil que identificou a causa raiz.

O advisory do GitHub afirma que a vulnerabilidade ocorre devido à análise inadequada do RFC3164, que é o formato tradicional de syslog BSD. O advisory explica que pode ocorrer um underflow de inteiro e que não se acredita haver impacto além da disponibilidade.

O pull request para corrigir a vulnerabilidade adiciona testes de unidade tanto para os analisadores de timestamp RFC3164 quanto RFC5424 (formato de syslog mais recente).

Observe que a especificação RFC3164 define que o timestamp deve corresponder ao formato Oct 11 22:14:15, enquanto o RFC5424 usa o formato ISO, 1985-04-12T19:20:50.52-04:00. Os casos de unidade indicam que o código do syslog-ng tenta analisar ambos os formatos. O advisory do GitHub afirma que a vulnerabilidade ocorre ao analisar mensagens RFC3164, o que não é totalmente preciso. As mensagens RFC5424 são responsáveis pelo timestamp de comprimento variável. Como o protocolo syslog não declara explicitamente um tipo de mensagem, o projeto syslog-ng tentou analisar ambos os timestamps. Isso permite que uma mensagem RFC3164 com um timestamp malformado também acione a vulnerabilidade:

A fonte do syslog usa contagem de octetos, conforme descrito pelo RFC6587, que prefixa a mensagem syslog com o número de bytes enviados em mensagens TCP.

A vulnerabilidade pode ser acionada enviando um tamanho de mensagem que não contabiliza totalmente o timestamp ISO. O código do syslog-ng itera sobre o timestamp e subtrai o número de dígitos do comprimento especificado. Essa incompatibilidade permite uma condição de underflow em que o comprimento de leitura acaba se tornando negativo enquanto ainda há dados para ler da mensagem.

O processo flui para um loop while onde fica preso tentando ler caracteres da mensagem. Esse problema resulta em 100% de uso de CPU para o processo em questão. Um atacante pode enviar múltiplos payloads para consumir recursos adicionais do sistema.

O Syslog não usa contagem de octetos via UDP, portanto o payload acima não tem efeito incomum. Reiniciar o contêiner/processo syslog-ng reinicia o uso de CPU.

Adicional

Um dos mantenedores do syslog-ng indicou que pode ser possível acionar isso através de um TCP RST no meio de uma mensagem. Foi observado que a mensagem precisaria enviar um timestamp parcial antes do TCP RST. Isso pode permitir que a contagem de octetos seja contornada.