Si vous partagez le lien de l'avis que vous utilisez, je peux formater un tableau propre « Affecté / Corrigé » dans le README sans avoir à deviner.

En quoi consiste la vulnérabilité (conceptuellement)

Ce laboratoire illustre un mode de défaillance de compression framing / inadéquation des métadonnées de taille :

• Les messages MongoDB sont préfixés par leur longueur. Avec la compression réseau, une enveloppe OP_COMPRESSED ajoute plus de champs de taille (longueur du message externe, taille décompressée déclarée, et la propre longueur du message interne).
• Si une implémentation fait confiance à l'un de ces champs de taille sans validation stricte, elle peut mal gérer les tampons lors de la décompression ou de l'analyse.
• Dans des implémentations boguées, cela peut entraîner des lectures hors limites ou le retour d'octets de tampon non initialisés, ce qui est une manière dont une « divulgation mémoire » peut se produire.

Voir protocol_overview.md pour la description détaillée du cadrage.

Avertissement éthique

• Ce projet est non exploitable par conception.
• Il n'inclut pas de logique militarisée, de code d'exploitation ou de techniques destinées à compromettre des systèmes.
• Il ne doit être exécuté que contre le conteneur Docker local fourni ici.
• Ne pointez pas ce code vers des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas d'autorisation explicite de tester.

Objectifs d'apprentissage

À la fin du laboratoire, vous devriez être capable de :

• Expliquer comment fonctionne le cadrage du protocole filaire de MongoDB à un haut niveau.
• Décrire comment la compression réseau zlib est négociée et appliquée.
• Comprendre comment des métadonnées de longueur / taille malformées pourraient conceptuellement conduire à une exposition mémoire dans une implémentation boguée.
• Identifier les mesures d'atténuation pratiques : correction, durcissement de la configuration et détection réseau.

Ce que ce dépôt fait (et ne fait pas)

Il fait :

• Démarrer MongoDB dans Docker avec la compression zlib activée.
• Utiliser un petit client Python original pour :
  • Envoyer un hello non compressé incluant compression: ["zlib"]
  • Envoyer un message OP_COMPRESSED correctement cadré utilisant zlib
  • Journaliser les tailles non compressées vs compressées et un résumé des réponses du serveur
• Inclure une démonstration locale d'« analyseur jouet » qui montre comment un analyseur défensif rejette les métadonnées de taille incohérentes.

Il ne fait PAS :

• Forger des paquets malveillants pour une exploitation réelle.
• Tenter de contourner l'authentification.
• Tenter de lire la mémoire arbitraire.

Contenu du dépôt

• docker-compose.yml – Exécute un conteneur MongoDB avec la compression zlib activée et une exposition locale uniquement.
• protocol_overview.md – Protocole filaire + BSON + flux de compression + explication conceptuelle de la vulnérabilité.
• mitigation.md – Conseils de défense : correction, configuration et idées de détection.
• lab_probe.py – Sonde originale qui négocie la compression et journalise les tailles de messages en toute sécurité.

Comment exécuter le laboratoire en toute sécurité

1) Prérequis

• Docker Desktop (ou moteur Docker compatible)
• Python 3.10+ (recommandé)

2) Démarrer MongoDB

Depuis le répertoire de ce dépôt :

Confirmez qu'il tourne :

3) Exécuter la sonde

Sortie attendue :

• Affiche les compresseurs négociés depuis le premier hello
• Affiche les tailles requête/réponse
• Envoie un hello compressé et journalise les tailles de messages compressés et décompressés

4) Exécuter la démo jouet (sans réseau)

Ceci exécute uniquement des vérifications d'analyse locales pour illustrer pourquoi la validation de taille est importante.

5) Arrêter

Notes de sécurité

• Le conteneur est lié à 127.0.0.1:27017 sur l'hôte.
• Aucun comportement d'exploitation n'est présent.
• La sonde applique des limites prudentes (par exemple, taille maximale de message) et valide tous les champs de longueur.