Je veux exploiter un dépassement tampon basé sur la pile à des fins éducatives.
Il existe une fonction typique appelée un paramètre à partir de MAIN, qui est donnée en entrée du programme un tampon local où le paramètre est enregistré. Compte tenu d'une entrée telle que Après le débogage avec GDB, j'ai trouvé l'adresse du code shell car elle passera en tant que paramètre, et juste après le puis L'adresse de retour a la valeur que je vouloir. Toute idée ce qui se passe? aussi lorsque je l'exécute, j'ai eu une erreur de segmentation et je l'ai compilée avec NOPS + shellcode + adresse_shellcode , je vais l'exploiter. Strcpy J'examine la pile et le EBP +8 Quelle est l'adresse de retour a écrasé avec succès avec l'adresse du code shell. Donc j'ai ce que je veux. Mais quand je faisais avancé l'exécution, j'ai obtenu: -g -fno-pile-protecteur . Pourquoi?
5 Réponses :
En supposant que votre distro Linux est récente et que vous travaillez sur une architecture x86ish, vous ne pouvez plus exécuter de code shell à partir de la mémoire d'espace utilisateur (cela s'applique également à d'autres architectures, je ne suis tout simplement pas aussi familier avec eux). Il existe un certain nombre de raisons, dans votre cas probablement le cadre du bit NX. Accédez à vos pages de Security Homme Linux et vous verrez un grand nombre de mesures de sécurité activées par défaut; et Google "brisant la pile pour s'amuser en 2011" pour les moyens possibles. Compiler avec '-Fno-Stack-protector' uniquement signifie ne pas définir une valeur de canarice; Mais cela ne suffit pas. Si vous voulez faire cela à des fins éducatives, je vous suggère d'installer une VM comme VirtualBox et une ancienne distribution sur elle.
Cela pourrait expliquer pourquoi essayer d'exécuter un code inapproprié pourrait avoir une violation d'accès. Comment explique-t-il le message "Impossible de trouver la fonction en cours", ce qui est apparemment un message du débogueur?
Vous exécutez du code sur la pile et demandez à GDB quelle fonction vous êtes.
De toute évidence, GDB est confus, car vous n'êtes pas dans aucune fonction. Donc, il montre l'adresse et "??"
Vous devez compiler avec -NO-Stack-protecteur, car Stack-protecteur vous protège de exactement ce que vous essayez de faire.
Je ne dis pas qu'il n'y a aucun moyen de le contourner, mais cela prend plus d'efforts et une bonne compréhension de son mécanisme de protection.
Pourquoi je ne suis pas dans aucune fonction? Je suis à l'intérieur de la mycancée qui a été appelé par Main.Et j'ai changé l'adresse RET de la myopathie avec une adresse à la pile où les NOPS sont et le shellcode.IJ'ai la compilation de -fno-Stack-protector.J'ai déjà mentionné cela.
Une fois que vous avez modifié l'adresse de retour à la coquille, et l'opération de retour a sauté là-bas, vous êtes dans la coquille, pas dans une fonction. Je pensais que vous demandiez pourquoi vous devez compiler avec No-Stack-protecteur et répondre.
Il n'y a pas d'autre moyen aussi loin que je sache de frayer la coquille autre que d'écraser l'adresse RET avec l'adresse du coquille précédant les instructions NOPS précédentes.Am je me trompe?
Il y a plusieurs façons. Vous pouvez faire varier l'emplacement de la coquille - la pile, le tas ou même utiliser le code LIBC existant ("Aller à libc"). Vous pouvez également utiliser différentes méthodes pour passer à elle - dépasser un pointeur de fonction, le VFT (en C ++), les structures de contrôle MALLOC. Et le code que vous sautez pour peut varier beaucoup. Et un pirailleur sérieux pourrait en ajouter beaucoup plus.
Je voulais le transmettre comme un argument d'entrée sur le PROG qui serait le paramètre à la fonction vulnérable
Qui a voté cela et pourquoi? Ceci est la seule réponse jusqu'à présent qui répond au message qui semble provenir du débogueur, "ne peut pas trouver lié la fonction actuelle". Cette réponse correspond au comportement observé: le débordement de la mémoire tampon a corrompu des données que le débogueur utilise pour interpréter la pile et déterminer quelle fonction est exécutée. Cette corruption entraîne le débogueur incapable de faire son travail et d'afficher le message d'erreur.
Très probablement, vous avez un problème de dépassement de tampon quelque part dans la fonction (ou quelque chose comme ça). Il écrase le cadre de pile actuel de votre fonction avec des données non pertinentes et détruit l'adresse de retour dans le processus, ce qui est normalement stocké y compris entre autres choses. Le résultat est que le code "retourne" à un endroit imprévisible et ne peut pas comprendre où il est retourné. C'est ce qui provoque le message d'erreur.
Le débogueur a des connaissances sur l'endroit où le code des fonctions de votre programme commence et finissez, soit parce que ces informations sont fournies dans les données de débogage ou, car elles utilisent des symboles externes visibles dans l'exécutable pour fournir des informations rudimentaires.
Lorsque la pile est dans un état approprié, elle contient une adresse de retour à la fonction d'appel et, quelque part au-dessus de celle-ci, une adresse de retour à une fonction d'appel de niveau supérieur, etc. Pendant que vous exécutez diverses commandes de débogueur, il utilise ces adresses de retour (et d'autres informations sur la pile et dans l'état du processus) pour vous montrer les noms de ces fonctions. Cela nécessite de rechercher l'adresse de retour dans les connaissances du débogueur sur l'emplacement des fonctions.
Une fois que vous débordez un tampon et corrompre la pile, l'adresse de retour appropriée est détruite. Au lieu de cela, vous avez une adresse différente (on pointant sur votre coquillage si votre exploit a fonctionné). Lorsque le débogueur tente de déterminer quelle fonction cette adresse est entrée, elle échoue, car l'adresse n'est dans aucune des fonctions de votre programme.
Lorsque cette échec survient, le débogueur imprime le message d'erreur que vous voyez.
Habituellement, le débogueur peut toujours effectuer des fonctions de base: il peut vous montrer que vous enregistrez des registres et de la mémoire dans votre programme, il peut encore encore une étape et de définir des points d'arrêt, etc. Cela aura du mal à faire des choses qui nécessitent une interprétation plus compliquée: il ne peut pas comprendre où les cadres de pile sont, il ne peut pas trouver de variables locales par son nom, etc.
Vous avez corrompu le registre avec l'adresse de retour de la fonction. L'adresse de retour est maintenant illégale et le débogueur ne peut pas y accéder. Ergo le message.
Jetez un coup d'œil à Stackoverflow.com/questions/2420813/... , il explique que" Impossible de trouver des limites de la fonction en cours "signifie que GDB n'a pas de débogage des informations de débogage pour l'instruction actuelle pointeur, et que c'est mécontent de cet état de choses. Mais vous avez probablement un autre problème en plus de cela.
Comment puis-je ajouter des informations de débogage pour l'instruction NOP, qui est suivie par d'autres NOPS et à la fin avec Shellcode?
Je ne sais pas exactement comment fonctionne GDB, mais je m'attends à ce que vous ne puissiez pas. GDB lève l'adresse du pointeur d'instructions dans sa grande vieille table d'informations de débogage, qu'elle a chargé des exécutables qu'elle connaît. Mais le pointeur d'instructions est sur la pile, il n'est pas couvert par aucune information de débogage. Peut-être en théorie que vous pourriez synthétiser certaines données de nain autour de l'adresse de pile actuelle et chargez cela dans GDB, mais je ne sais pas comment.
Je ne le pense pas. Il s'agit d'une exploitement de débordement tampon basé sur une pile simple. Je manque qc sinon