Un exemple typique de gestion de tampon non trivial est l'analyse de fichiers binaires (ou de paquets réseau) qui peuvent contenir des chaînes de longueur arbitraire (y a-t-il un analyseur ASN.1 qui n'a pas eu de bogues de débordement de tampon à un moment donné ?)

Par exemple, considérons le format des blocs de données textuelles dans les fichiers PNG:

Le mot-clé et la chaîne de texte sont séparés par un zéro byte (caractère nul). Ni le mot clé ni la chaîne de texte ne peuvent contenir un caractère nul. La chaîne de texte n'est pas terminée par un zéro (la longueur du morceau définit la fin).

Le devoir pourrait donc être un outil qui génère toutes les données textuelles dans un fichier PNG.

Même du texte brut peut ne pas être tout à fait trivial si vous avez besoin de gérer arbitrairement de longues lignes, et donc de redimensionner un tampon de manière dynamique.Par exemple:

Implémentez tail sans paramètres. (Les lignes peuvent être plus longues que n'importe quel tampon statique. Le fichier entier peut être plus volumineux que la mémoire disponible.)

Je vois beaucoup de problèmes lorsque les gens ont besoin d'analyser des données de caractères hors de structures, en particulier lorsqu'il s'agit d'un tampon normalement terminé par null, mais qui peut avoir la taille du tampon sans terminateur.

  short canary = 0x5678; struct customer {char name [4]; char suffix [3];}; short fencepost = 0x1234;  

Demandez-leur de remplir le client avec des données comme "Joe" et "Jr". Demandez-leur de sortir toutes les données dans ce format exact:

  canary: 0x5678name: Joesuffix: Jrfencepost: 0x1234  

Puis demandez-leur de remplir le client avec "John "et" Esq ". Leur sortie devrait ressembler à ceci:

  canary: 0x5678name: Johnsuffix: Esqfencepost: 0x1234  

C'est une tâche simple et courante. Cela devrait leur apprendre qu'ils ne peuvent pas se contenter de strcpy ("Esq") dans le tampon, car cela tuera le canari. Il devrait les obliger à copier les données du tampon afin de le terminer pour l'imprimer.

Je vous recommande de tester d'abord ceci et de vérifier les paramètres du compilateur. Dans les anciennes versions de Microsoft de Visual C ++, une version de débogage serait liée à une version de débogage de l'allocateur de mémoire qui ajoutait des bornes autour de la mémoire allouée. Cela permettrait au débogueur de signaler une erreur de mémoire écrasée. Je ne sais pas si les versions les plus récentes font toujours cela, mais je sais que les versions de version ne le font pas.

Si vous voulez leur donner un "pourquoi", montrez comment saisir un nom comme Fred @@ @@@@@@ peut provoquer un plantage et permettre à un pirate de prendre le contrôle du programme.

c'est difficile car les noyaux Linux modernes afaik n'ont pas de piles exécutables, ils ne pourront donc pas tester leurs programmes sur une distribution linux normale. (Je me souviens avoir des difficultés à tester le code listé dans l'article Alef One sur ma machine Debian)

Ce que vous pourriez faire, c'est leur fournir une VM personnalisée (comme un sacré Linux vulnérable) dont les paramètres de sécurité sont désactivés et leur dire de tester leur code là-bas.

Plus précisément, une solution serait de leur faire écrire un programme qui contient un nom de fichier comme argument de ligne de commande ou comme entrée utilisateur

• ouvre le fichier
• lit certains configuration à partir de celui-ci
• l'analyse / recherche quelque chose de spécifique
• pousse la partie appropriée dans une prise réseau
• un autre processus lit les données et doit imprimer certaines parties pertinentes .

Votre scénario pourrait être:

Vous devez écrire un programme en c qui lit les horaires des vols des compagnies aériennes à partir d'un fichier fourni par l'utilisateur et le pousse via une socket tcp vers anoth er processus qui l'affiche ensuite.

Afin de pimenter un peu les choses, vous pouvez fournir une structure dans laquelle tout doit être géré.

C'est simple puisque la plupart du code peut être trouvé en ligne (lecture depuis un fichier, écriture sur socket) et les étudiants n'ont qu'à gérer la mémoire

En fonction des contraintes de votre plate-forme, je suggérerais qu’ils implémentent certains DCOM.

La mise en œuvre des appels DCOM implique de nombreux domaines problématiques: appels réseau, gestion des interfaces, marshalling , le comptage de références distribuées et la gestion de la durée de vie des objets, la sécurité de la mémoire partagée, et plus encore - si cela est bien fait, cela inclut également une vérification d'ACL de bas niveau, etc. Beaucoup de petits morceaux et de structures complexes volent.

Je n'ai jamais vu de code DCOM - que ce soit en appelant le client ou le serveur - PAS de bogues significatifs (à moins d'être implémentés dans un langage "sûr", comme VB, et même alors c'est commun).