Désactivez la protection de la pile sur Ubuntu pour le débordement de la mémoire tampon sans les indicateurs du compilateur C

10

Je voudrais essayer quelques codes shell et je souhaite désactiver les protections Linux.

Je sais que je pourrais compiler à l'aide de drapeaux, mais je sais qu'il existe un autre moyen de désactiver ces protections en général, je ne m'en souviens tout simplement pas. Pouvez-vous m'aider?

linux security compiling

— Phate
source

6

La protection de la pile est effectuée par le compilateur (ajoutez des données supplémentaires à la pile et en cachez-en sur appel, vérifiez la santé mentale au retour). Impossible de désactiver cela sans recompiler. Cela fait partie du point, vraiment ...

— vonbrand
source

6

ASLR nécessite que le système d'exploitation le fasse au moment de l'exécution. Les bits NX nécessitent également la prise en charge du système. Quelle partie ne peut pas être désactivée lors de l'exécution?

— Jeff Ferland

25

Pour développer ce que vonbrand a dit (correctement, +1), la protection de la pile de Linux comporte deux parties.

Empiler les canaris

Les canaris de pile sont la fonctionnalité imposée par le compilateur à laquelle vonbrand fait référence. Ceux-ci ne peuvent pas être désactivés sans recompilation.

Pour vous le prouver et voir comment ils fonctionnent, prenez le code suivant:

#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>

int mybadfunction(char* a_bad_idea)
{
    char what[100];
    strcpy(what, a_bad_idea);
    printf("You passed %s\n", what);
}

int main(int argc, char** argv)
{
    printf("Tralalalaala\n");
    mybadfunction(argv[1]);
}

Maintenant, compilez cela ( gcc -fstack-protector -masm=intel -S test.c) en quelque chose de gnu comme il serait heureux d'assembler et de lire la sortie. Le point important est qu'à la sortie de la mybadfunctionfonction, il y a ce petit bout de code:

    mov edx, DWORD PTR [ebp-12]
    xor edx, DWORD PTR gs:20
    je  .L2
    call    __stack_chk_fail

Comme vous pouvez le deviner, cela prend un cookie de pile [ebp-12]et le compare à la valeur de gs:20. Ne correspond pas? Il appelle ensuite une fonction __stack_chk_faildans glibc qui tue votre programme juste là.

Il existe des moyens de contourner ce problème en termes d'écriture d'exploits, mais le moyen le plus simple pour construire un scénario de test shellcode est de compiler votre programme avec -fno-stack-protector.

Pages non exécutables

Il existe d'autres considérations sur les systèmes Linux modernes. Si vous prenez le talon de test de shellcode habituel:

char buffer[] = {...};

typedef void (* func)(void);

int main(int argc, char** argv)
{
    func f = (func) buffer;
    f();
    return 0;
}

GCC / Linux moderne mappera la .rodatasection du fichier PE en lecture seule sans autorisation d'exécution. Vous devez désactiver cela, ce qui peut être fait en utilisant l'exemple de code de ce billet de blog . Idée de base: vous utilisez mprotectpour ajouter les autorisations souhaitées aux pages dans lesquelles résident les données du shellcode.

Piles non exécutables

Si vous allez tester un scénario d'exploitation traditionnel, par exemple mon mauvais code ci-dessus, avec votre shellcode, vous devez également vous assurer que la pile est exécutable pour les cas simples. Le format de fichier PE contient un champ pour déterminer si la pile est exécutable - vous pouvez interroger et contrôler cela avec execstack . Pour activer une pile exécutable, exécutez

execstack -s /path/to/myprog

Cela peut être fait sur des programmes arbitraires sans avoir besoin d'une recompilation, mais ne désactivera pas automatiquement les canaris de la pile car ceux-ci sont intégrés à la compilation.

Bonus supplémentaire: aslr:

Pour éteindre ça, echo 0 > /proc/sys/kernel/randomize_va_space.

Vous venez de dire à quelqu'un comment exploiter mon précieux pingouin?

Non. Tout exploit doit contourner les canaris de pile (très peu triviaux) et soit trouver un programme avec execstackset, soit le définir (ce qui signifie qu'il peut déjà exécuter des commandes arbitraires de toute façon) ou encore utiliser des techniques plus difficiles, telles que le retour à libc / return programmation orientée.

— Jonathan Leffler
source

0

Vous pouvez désactiver certaines protections (détection d'écrasement de pile et rendre la pile exécutable) avec ces options.

--z execstack
-f no-stack-protector

Vous pouvez également désactiver ASLR (randomisation de la disposition de l'espace d'adressage) avec Bash avec la commande:

echo 0 > /proc/sys/kernel/randomize_va_space

— gotoat
source