
Preuve de concept pour CVE-2022-38725 contre syslog-ng
CVE-2022-38725 est une vulnérabilité de déni de service non authentifiée dans syslog-ng versions antérieures à 3.38.1.
https://github.com/syslog-ng/syslog-ng/security/advisories/GHSA-7932-4fc6-pvmc
https://nvd.nist.gov/vuln/detail/CVE-2022-38725
docker pull linuxserver/syslog-ng:3.36.1
docker run -p 514:5514/udp -p 601:6601/tcp --rm -it linuxserver/syslog-ng:3.36.1
echo '27 <182>2022-08-17T05:02:28.217 mymachine su: 'su root' failed for lonvick on /dev/pts/8' | nc 127.0.0.1 601 -w 1

La version 3.38.1 renvoie à https://github.com/syslog-ng/syslog-ng/pull/4110, qui inclut des tests unitaires et plusieurs validations pour prévenir des variantes similaires de ce bogue.
Le problème d'origine inclut un débogage utile qui a identifié la cause racine.
L'avis GitHub affirme que la vulnérabilité provient d'une analyse incorrecte de RFC3164, qui est le format syslog BSD traditionnel. L'avis explique qu'un dépassement négatif (underflow) d'entier peut se produire et qu'aucun impact au-delà de la disponibilité n'est jugé possible.
La demande de tirage pour corriger la vulnérabilité ajoute des tests unitaires aux analyseurs d'horodatage RFC3164 et RFC5424 (format syslog plus récent).
Notez que la spécification RFC3164 définit l'horodatage au format Oct 11 22:14:15, tandis que RFC5424 utilise le format ISO, 1985-04-12T19:20:50.52-04:00. Les cas de test indiquent que le code syslog-ng tente d'analyser les deux formats. L'avis GitHub affirme que la vulnérabilité se produit lors de l'analyse des messages RFC3164, ce qui n'est pas tout à fait exact. Les messages RFC5424 sont responsables de l'horodatage de longueur variable. Comme le protocole syslog ne spécifie pas explicitement un type de message, le projet syslog-ng a tenté d'analyser les deux horodatages. Cela permet également à un message RFC3164 avec un horodatage malformé de déclencher la vulnérabilité :
echo '21 <182>Oct 11 22:14:15.123 mymachine su: 'su root' failed for lonvick on /dev/pts/8' | nc 127.0.0.1 601 -w 1
La source syslog utilise le comptage d'octets comme décrit par RFC6587, qui préfixe le message syslog avec le nombre d'octets envoyés dans les messages TCP.
La vulnérabilité peut être déclenchée en envoyant une taille de message qui ne tient pas pleinement compte de l'horodatage ISO. Le code syslog-ng parcourt l'horodatage et soustrait le nombre de chiffres de la longueur spécifiée. Ce décalage permet une condition de dépassement négatif où la longueur de lecture devient négative alors qu'il reste encore des données à lire dans le message.
Le processus aboutit à une boucle while où le processus reste bloqué à essayer de lire des caractères du message. Ce problème entraîne une utilisation CPU de 100% pour le processus concerné. Un attaquant peut envoyer plusieurs charges utiles pour consommer des ressources système supplémentaires.
Syslog n'utilise pas le comptage d'octets sur UDP, donc la charge utile ci-dessus n'a aucun effet inhabituel. Redémarrer le conteneur/processus syslog-ng réinitialise l'utilisation CPU.
Un des mainteneurs de syslog-ng a indiqué qu'il pourrait être possible de déclencher cela via un TCP RST au milieu d'un message. Il a été noté que le message devrait envoyer un horodatage partiel avant le TCP RST. Cela pourrait permettre de contourner le comptage d'octets.