3.38.1 リリース は https://github.com/syslog-ng/syslog-ng/pull/4110 をリンクしており、これには単体テストといくつかの検証が含まれており、このバグの類似バリアントを防ぐためのものです。

元の issue には、根本原因を特定した有用なデバッグ情報が含まれています。

GitHub の勧告では、この脆弱性は従来の BSD syslog 形式である RFC3164 の不正な解析によって発生すると主張しています。勧告では、整数アンダーフローが発生する可能性があり、可用性以外への影響はないと考えられると説明されています。

脆弱性を修正するプルリクエストでは、RFC3164 と RFC5424 (新しい syslog 形式) の両方のタイムスタンパーサーに単体テストが追加されています。

RFC3164 仕様では、タイムスタンプを Oct 11 22:14:15 形式に一致させるよう定義されていますが、RFC5424 は ISO 形式 1985-04-12T19:20:50.52-04:00 を使用します。単体テストケースは、syslog-ng コードが両方の形式を解析しようとすることを示しています。GitHub 勧告では、RFC3164 メッセージの解析時に脆弱性が発生すると主張していますが、これは完全に正確ではありません。RFC5424 メッセージが可変長タイムスタンプの原因です。syslog プロトコルはメッセージタイプを明示的に指定しないため、syslog-ng プロジェクトは両方のタイムスタンプを解析しようとしました。これにより、不正な形式のタイムスタンプを持つ RFC3164 メッセージでも脆弱性がトリガーされる可能性があります:

syslog ソース は、RFC6587 で説明されているオクテットカウントを使用し、TCP メッセージで送信されるバイト数を syslog メッセージの前に付加します。

この脆弱性は、ISO タイムスタンプを完全に考慮していないメッセージサイズを送信することでトリガーされる可能性があります。syslog-ng コードはタイムスタンプを反復処理し、指定された長さから桁数を減算します。この不一致により、メッセージから読み取るデータがまだ残っているにもかかわらず、読み取り長が負になるアンダーフロー状態が発生します。

プロセスは while ループに進み、メッセージから文字を読み取ろうとしてスタックします。この問題により、特定のプロセスで CPU 使用率が 100% になります。攻撃者は複数のペイロードを送信して、追加のシステムリソースを消費する可能性があります。

syslog は UDP 上でオクテットカウントを使用しないため、上記のペイロードは異常な影響を与えません。syslog-ng コンテナ/プロセスを再起動すると、CPU 使用率はリセットされます。

補足

syslog-ng のメンテナの一人は、メッセージの途中で TCP RST を介してこれをトリガーできる可能性があると指摘しました。TCP RST の前に部分的なタイムスタンプを送信する必要があると指摘されています。これにより、オクテットカウントをバイパスできる可能性があります。