Adresse des variables d'environnement ?

[welc0me]

Bonsoir,

J'ai vu un peu partout que l'adresse d'une variable d'environnement était facile à déterminer précisément.

J'ai fais un petit programme très simple (compilé en 32 bits) :

Code :

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

int main(int argc, char **argv) {
     printf("%s est à l'adresse : %p\n", argv[1], getenv(argv[1]));
}

Mais quand je le lance à plusieurs reprises j'obtiens :

Code :

./getenv PATH
PATH est à l'adresse : 0xfff20cf9
./getenv PATH
PATH est à l'adresse : 0xffc72cf9
./getenv PATH
PATH est à l'adresse : 0xffbaacf9
./getenv PATH
PATH est à l'adresse : 0xff82acf9

L'adresse varie tout le temps, comment cela se fait-il ?

De plus, j'ai lu que les variables d'environnement se situaient dans la partie userland, entre les adresses 0x0 et 0xbfffffff.
Mais ici, les adresses sont toujours entre 0xbfffffff et 0xffffffff dans l'espace kernelland. Pourquoi ?

Merci

[supersnail]

Bonjour,

Déjà, par défaut t'as un truc qui s'appelle l'ASLR, qui a pour but de faire changer l'adresse des variables d'environnement (plus généralement de la "stack"), afin de complexifier la prédiction de l'adresse de la variable (ça fait partie des protections ajoutées au kernel).

Sinon, pour ce qui est des adresses en 0xff l'hypothèse la plus plausible selon moi serait l'émulation 32bits (il me semble que tu tournes sur un système 64 bits), du coup il se peut que le schéma des adresses soit chamboulé

[b0fh]

Pour reprendre ce que dit mon estimé collègue, sous linux tu peux désactiver l'aslr avec

Code :

echo 0 >/proc/sys/kernel/randomize_va_space

[welc0me]

J'avais désactivé l'ASLR au début de mon étude sur les buffers overflows, je viens de regarder et en fait je l'avais remise (je ne sais pas quand et je ne sais pas pourquoi). Bref c'est donc une erreur d'inatention de ma part x)

Au final j'ai compilé en 32bits et 64bits et l'exécution dans les deux cas est tout à fait plausible pour l'info. Donc pas de chamboulement d'adresse

Merci pour ton aide !

EDIT:
Je viens d'effectuer ça, merci à toi b0fh

[welc0me]

De plus, j'ai lu que les variables d'environnement se situaient dans la partie userland, entre les adresses 0x0 et 0xbfffffff.
Mais ici, les adresses sont toujours entre 0xbfffffff et 0xffffffff dans l'espace kernelland. Pourquoi ?

Juste, quelqu'un a une idée ? :x

[supersnail]

Ce que je voulais dire, c'est que la "logique" des adresses change si tu es en x86 ou en x64 (je parle de l'architecture de ton NOYAU, pas de l'architecture avec laquelle tu compiles ton application), et je pense que c'est l'émulation x86 qui fait ce changement d'adresse

Si tu exécutes la version 32 bits de ton programme sur un noyau 32 bits, tu te retrouves bien avec une adresse en 0xbfff... Sinon j'aimerais bien voir la tronche de ton adresse sur ton prog compilé en 64 bits :> (j'ai pas de kernel 64bits sous la main)

[welc0me]

Ahhhh d'accooooord ! J'avais mal pigé le truc...
J'vais télécharger une distrib 32 bits alors, ça à l'air plus simple pour tout ! x)
Merci !

[welc0me]

Ah, ben c'est pas si résolu que ça !
J'ai réinstallé linux en x86, et quand j'essaie de déterminer l'adresse d'une variable d'environnement, je tombe toujours un peu à côté. J'me suis vraiment creusé la tête mais là je vois vraiment pas pourquoi...

J'essaie de le faire de deux façons.

Première façon :

Code :

ptr = getenv(argv[1]);
ptr += (strlen(argv[0]) - strlen(argv[2])) * 2

Avec argv[2] le nom du programme cible et argv[1] le nom de la variable d'environnement.

Deuxième façon :

Code :

ret = 0xbffffffa - strlen(argv[1]) - strlen("/home/test/buffer_overflow");

J'obtiens d'ailleurs 2 résultats différents :

Code :

SHELLCODE is at 0xbffff50f
SHELLCODE is at 0xbfffffd8

Voilà, si quelqu'un sait pourquoi ça fait ça...