Qu’est-ce que Stack Smashing ? Peut-il être corrigé ? –

Chaque minute d’arrêt de production coûtera généralement de l’argent à une entreprise. Si votre application a un problème grave qui provoque l’écrasement de la pile, vous êtes prêt pour un tour. Apprenez ce qu’est le fracas de pile dès le départ et ce qui peut être fait à ce sujet !

Qu’est-ce que Pile fracassante?

Travailler comme ingénieur en assurance qualité, on rencontrera tôt ou tard le terme pile cassant. En tant que développeur, on découvrira probablement ce terme encore plus tôt, surtout si l’on a introduit un bogue dans le code, ce qui provoque une pile brisée. C’est relativement facile (comme dans ‘un peu facile’) pour qu’un développeur fasse une erreur qui introduit un écrasement de pile. En tant qu’utilisateur, lorsque vous découvrez l’écrasement de pile, le mal est probablement déjà fait.

L’écrasement de la pile peut se produire involontairement – par exemple, lorsque le développeur a introduit un bogue qui a provoqué l’écrasement de la pile – ou par malveillance – un attaquant essayant en quelque sorte de déborder ou de corrompre la pile d’un programme.

Stack smashing est un terme assez vaguement défini qui peut indiquer divers problèmes et peut provenir de diverses sources. Les deux problèmes les plus importants qui peuvent provoquer l’écrasement de la pile sont : 1) pour écrire/surallouer trop de données dans une partie donnée de la pile, écrasant ainsi une autre partie de la pile, et 2) où une source externe (malveillante ou non) a écrasé la pile d’un autre programme, bien que ce soit beaucoup moins courant .

Alors, qu’est-ce qu’une pile ? C’est aussi un terme vaguement défini. D’une manière générale, une pile fait référence à une pile de traitement de programme, une pile de fonctions telles que définies dans un logiciel/code donné.

Commencez par imaginer une pile de carreaux de salle de bain empilés, prêts à être utilisés par un carreleur. C’est une assez bonne représentation d’une pile informatique, avec quelques modifications. Si chaque tuile était un peu décalée par rapport à la précédente, ce serait une meilleure image, et on verra bientôt pourquoi.

Imaginez que chaque tuile empilée est une fonction du programme informatique. La fonction la plus basique se trouve en bas, et pourrait être par exemple le main() fonction dans un programme C ou C++. C et C++ sont deux langages de programmation qui utilisent beaucoup la pile.

Chacune de ces fonctions dans le programme C/C++ aura un nom et probablement un ensemble de variables entrantes et de variables sortantes. En termes simplifiés, imaginez si l’une de ces variables avait une longueur de 10 caractères et qu’une autre fonction écrivait accidentellement 100 caractères dans cette variable. Cela peut corrompre toute la pile.

En ce qui concerne l’exemple de tuiles ci-dessus, imaginez quelqu’un avec un marteau frappant la première tuile un peu trop fort et brisant ainsi toutes les autres tuiles. Eh voila ; pile fracassante

L’analogie fonctionne car, tout comme toutes les tuiles sont maintenant brisées dans notre image mémoire fictive, une pile brisée entraînera ‘fonctions cassées’ si vous voulez. Chaque décalage de tuile est une fonction imbriquée plus profondément – plus sur les fonctions cassées dans la section suivante.

Débogage Pile(s) brisée(s)

Alors que techniquement une référence à ‘fonctions cassées’ peut ne pas être tout à fait correct, c’est-à-dire qu’il n’y a probablement qu’une seule fonction cassée, et il peut même n’y avoir aucune fonction cassée lorsqu’il y a une attaque externe ou un programme défectueux, c’est un excellent moyen de penser à une pile brisée.

Soudainement, les noms de variables et de fonctions peuvent être mutilés, et une trace (le flux de fonctions que l’ordinateur a pris pour arriver à une fonction donnée qui s’est écrasée et (dans notre exemple) a écrasé la pile) n’a plus de sens.

D’une manière générale, lorsque nous regardons un backtrace, il aura un flux clair de fonctions qui ont été appelées. Bien qu’un programme en panne ne puisse pas être immédiatement qualifié de « sain », en termes de backtrace/débogage, voici à quoi ressemble un backtrace « sain »:

Cependant, lorsqu’une pile est corrompue, le débogage devient beaucoup plus difficile. La pile peut ressembler à ceci :

Il s’agit d’un exemple de problème d’écrasement de pile qui s’est produit dans MySQL, le serveur de base de données (voir le log.txt pièce jointe au bogue MySQL 37815 pour la sortie complète) en 2008, provoquant le démon du serveur de base de données (mysqld) Terminer.

Alors que la bibliothèque du système d’exploitation libc.so.6, dans ce cas, semble avoir assez bien géré le fracas de la pile (en utilisant certaines fonctionnalités de fortification dans le __fortify_fail fonction), le problème existait quelque part dans le code et a depuis été résolu.

Notez également que dans ce cas, nous ne voyons pas les noms de fonction résolus, nous ne voyons que le nom binaire (fait intéressant, le problème semble avoir été dans le client (mysql) provoquant le serveur (mysqld) pour mettre fin) qui est mysql, avec une adresse mémoire de la fonction : mysql[0x8051565], mysql[0x80525c7] et mysql(main+0x4f8)[0x8053198].

Normalement, lorsque nous utilisons des symboles de débogage (réf. ci-dessous pour un article sur GDB qui explique ce que sont les symboles de débogage en détail), nous verrions des noms de fonctions avec des variables, et même avec certains niveaux d’optimisation/minification binaire en place, nous verrions au moins voir les noms de fonction, tout comme ce que nous voyons dans le premier backtrace « sain » ci-dessus.

Cependant, dans le cas d’une pile brisée, la sortie des noms de fonctions, des noms de variables ou des valeurs n’est jamais garantie et complète souvent le charabia Nous pouvons même voir des noms de fonctions différents ou un pile mutilée (un autre jargon souvent utilisé par les informaticiens) de noms de fonctions différents qui n’ont pas beaucoup de sens (et sont probablement fictifs/faux car la pile a été écrasée d’une manière ou d’une autre).

Cela rend la tâche plus difficile à la fois pour l’ingénieur de test (qui peut se retrouver avec de nombreux résultats différents pour un seul bogue, ce qui complique la gestion du mécanisme de filtrage des bogues connu) ainsi que pour le développeur (qui devra probablement utiliser un traçage étape par étape ou un débogueur à exécution inversée comme RR pour découvrir le bogue en question).

Que faire lorsque vous faites face à un écrasement de pile ?

Si vous rencontrez un écrasement de pile, la première chose que vous voulez faire est de mieux comprendre le problème et l’environnement pour connaître la source. Si vous avez un serveur Web populaire exposé sur Internet avec de nombreux utilisateurs de jeux qui tentent de gagner un tournoi alors que le serveur exploite également Bitcoin, vous voudrez supposer la possibilité d’un acte criminel et déterminer si quelqu’un joue avec le serveur.

Cependant, dans la plupart des cas, le problème sera simplement une erreur d’application. Pendant que je dis ‘juste’, le problème peut être très important, entraîner une interruption des services, coûter très cher et finalement ne pas pouvoir être résolu. Par exemple, un serveur de base de données peut planter de manière persistante lors de son démarrage en raison d’un état donné des données associé à une lacune ou une limitation dans le code.

Si une telle situation est aggravée par le non-écrasement de la pile, ou en d’autres termes, par l’impossibilité de générer une trace claire du problème, le débogage sera plus complexe et parfois presque impossible. N’ayez crainte, cependant, le même débogage de base que pour tout bogue ou erreur/crash/problème d’application reste le même.

Lisez attentivement chaque partie des fichiers journaux avant, pendant et après le problème. Effectuez quelques sauvegardes, puis réessayez l’opération. Est-ce qu’il échoue à nouveau ou non? Recherchez les erreurs, les parties de la pile et même les cadres (c’est-à-dire les fonctions de pile individuelles affichées, comme le do_the_maths fonction dans notre trace de pile « saine » d’origine) peut être placé dans vos moteurs de recherche préférés.

Concaténer (avec un espace) les images de plantage les plus sélectives (en haut) et rechercher les mêmes en ligne vous permet souvent de trouver un rapport de bogue existant pour le problème auquel vous êtes confronté. Pourtant, dans le cas d’un écrasement de pile, ces trames (noms de fonction) sont probablement devenues mutilées et ne sont donc plus utilisables de la même manière. Si vous voyez un message d’assertion (un développeur a institué une assertion dans le code) de quelque nature que ce soit, recherchez-le également.

Enregistrez toujours un nouveau rapport de bogue si le problème ne semble pas encore être enregistré en ligne (vous aidez peut-être d’autres personnes qui voient le même problème !) et fournissez autant d’informations que possible sur le problème. Des milliers de rapports de bogues concernant autant d’applications sont enregistrés en ligne chaque jour. Espérons que l’équipe d’assistance pour votre application de destruction de pile soit à portée de main pour vous aider rapidement.

Vous pouvez également lire notre article Débogage avec GDB : Mise en route ensuite, car il s’appuie davantage sur la façon dont les programmes C et C++ (et autres) peuvent être débogués avec le débogueur GDB. Il explique également en détail les concepts d’une pile.