[RESOLU] Tests sécurité: autoriser les débordements de tampon.

MrFaelivrin · Le 09/08/2013, à 11:38

Bonjour à tous,

Je suis en train d'effectuer des tests sur ma machine en m'initiant à la sécurité informatique.
J'essaie sur ma machine:
Linux azerty-D567P 3.5.0-34-generic #55-Ubuntu SMP Thu Jun 6 20:18:19 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Pour la suite mon intention était de créer un débordement de tampon puis par injection d'un shellcode, obtenir le root acces.

Évidemment, je m'attendais quand même à un minimum de sécurité et il semblerait que ma machine détecte une simple réécriture sur les octets suivants mon tableau. Il détecte le débordement. Voici le message d'erreur:

$./overflow AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Erreur de segmentation (core dumped)

(En argument on était censés accepter un tableau de 10 char. )

J'ai vu sur certains topics qu'il suffisait que je compile mes codes qui sont écrits en C et que je compile avec gcc, avec l'option -fno-stack-protector.

gcc -o overflow overflow.c -fno-stack-protector

Mais aucun changement..

N'y aurait-il pas des options du kernel à modifier?
Merci pour votre aide..
C'est un peu handicapant d'apprendre la sécurité informatique et ne pas pouvoir la pratiquer.

Dernière modification par MrFaelivrin (Le 19/08/2013, à 14:11)

telliam · Le 09/08/2013, à 19:13

Je vois rien d'anormal a tout ca‚ tu ecrases bcp trop donc le système est capable de détecter l'écrasement de ta pile. Tente déjà d'écraser un octet sans que ton système le détecte.

grim7reaper · Le 09/08/2013, à 20:50

Surtout que, du peu que je me souvienne (il faudrait que je me replonge un peu sur les doc’ que j’ai à ce sujet), il ne s’agit pas de faire un bête buffer overflow.
Il faut qu’il soit de la bonne taille pour juste écraser l’adresse de retour de ta fonction et faire sauter le processeur sur ton shellcode (ainsi, il l’exécutera).
Faire un buffer overflow à l’arrache, oui en général ça plante car tu va faire pointer le CPU sur des trucs qui ne codent pour aucune instructions ou ça va pointer n’importe où (genre en dehors de l’espace mémoire de ton processus) et là l’OS va te tuer sans ménagement.

telliam · Le 10/08/2013, à 10:18

Oui c tout a fait ça. Et encore il faut être sûr que cette adresse de retour est bien stocké en pile et non pas dans un registre, ça va dépendre de ton hardware et des options de compilation.

MrFaelivrin · Le 10/08/2013, à 10:33

lol

Pardon, en faisant moins "à l'arrache" mon débordement je me rends compte que ça marche..

Mais donc ça veut dire que si sur une machine l'option -fno-stack-protector de gcc est activée, il est possible d'injecter un shell code qui génère un shell en root?
J'aimerais bien y parvenir en exécutant les scripts du bouquin que j'utilise.

Là, je me suis replongé dans le livre de Jon Erickson, The Art of Exploitation qui est d'ailleurs un excellent livre que je conseille! Mais c'est vraiment galère de s'y remettre quelques années plus tard sans pratiquer l'asm. J'aime bien tout comprendre, tout maîtriser et là je suis obligé de refaire l'effort à chaque fois de suivre tout le déroulement des débogages de tous les programmes.

J'avais une autre question sur d'autres programmes que je compile.
Lors de la compilation, j'ai ce message d'erreur:

 attention : le format n'est pas une chaîne littérale et pas d'argument de format [-Wformat-security]

(Ce message n'empêche pas l’exécutable d'être crée.)

Du coup, par réflexe, j'ajoute l'option -Wformat-security à la commande gcc. (ajouter une sécurité pour éviter les printf(mavariable);?)
Le message d'erreur est toujours affiché quand j'ajoute cette option.
J'ai pas l'habitude d'utiliser d'autres options que (-o ou -g) et le manuel n'en dit pas plus sur cette option.

Dernière modification par MrFaelivrin (Le 10/08/2013, à 10:35)

Melrock · Le 14/08/2013, à 03:19

Bonjour,
tu pourrais donner la ligne de code qui produit ton warning ?

pingouinux · Le 14/08/2013, à 06:29

Bonjour,
Ce message apparaît par exemple avec ces lignes :

char * fmt="Texte\n";
printf(fmt);

Pour supprimer le Warning, ajouter l'option -Wno-format-security à la compilation.

grim7reaper · Le 14/08/2013, à 08:20

MrFaelivrin a écrit :

Lors de la compilation, j'ai ce message d'erreur:
 attention : le format n'est pas une chaîne littérale et pas d'argument de format [-Wformat-security]
(Ce message n'empêche pas l’exécutable d'être crée.)

C’est un avertissement, pas une erreur.
C’est pour ça que ça n’empêche pas le création de l’exécutable.

MrFaelivrin a écrit :

Du coup, par réflexe, j'ajoute l'option -Wformat-security à la commande gcc. (ajouter une sécurité pour éviter les printf(mavariable);?)
Le message d'erreur est toujours affiché quand j'ajoute cette option.

C’est cette option qui produit le warning, évidemment que si tu l‘ajoute une fois de plus (car activée par défaut depuis Ubuntu 8.10) ça ne va pas retirer le warning.

MrFaelivrin a écrit :

le manuel n'en dit pas plus sur cette option.

On ne doit pas avoir le même manuel alors…

man 1 gcc a écrit :

-Wformat-security
If -Wformat is specified, also warn about uses of format functions that represent possible security problems. At present, this warns about calls to "printf" and "scanf" functions where the format string is not a string literal and there are no format arguments, as in "printf (foo);". This may be a security hole if the format string came from untrusted input and contains %n. (This is currently a subset of what -Wformat-nonliteral warns about, but in future warnings may be added to -Wformat-security that are not included in -Wformat-nonliteral.)
NOTE: In Ubuntu 8.10 and later versions this option is enabled by default for C, C++, ObjC, ObjC++. To disable, use -Wno-format-security, or disable all format warnings with -Wformat=0. To make format security warnings fatal, specify -Werror=format-security.

pingouinux a écrit :

Bonjour,
Ce message apparaît par exemple avec ces lignes :
char * fmt="Texte\n";
printf(fmt);
Pour supprimer le Warning, ajouter l'option -Wno-format-security à la compilation.

Non, non, non et NON !
Pour supprimer un warning, il faut corriger son code. À plus fortes raisons quand le warning concerne la sécurité…
Dans ton exemple, tu as une utilisation de printf qui viole sa sémantique, le compilo’ te met en garde.
La bonne façon de supprimer le warning est d’écrire le code d’une façon correcte :

char * fmt="Texte\n";
fputs(fmt, stdout);

La mauvaise façon, c’est supprimer le warning sans rien y comprendre.

Après, ici étant un cas particulier, si les programmes qu’il compile contiennent ce genres de trou de sécurité (justement parce que ce sont des exemples de failles), pas besoin de supprimer le warning, le code généré sera le même…

Dernière modification par grim7reaper (Le 14/08/2013, à 08:28)

pingouinux · Le 14/08/2013, à 08:38

@grim7reaper :
MrFaelivrin demandait en #5 s'il existait une option pour supprimer le Warning que générait son code, et je la lui ai indiquée; libre à lui de l'utiliser ou pas. Il est sûr qu'il est préférable de corriger le code comme tu l'indiques en #8.

Melrock · Le 14/08/2013, à 23:30

En l'occurence, le warning est dû au fait que printf s'attend, pour son premier argument (format), à avoir une chaîne constante.

La façon correcte de l'écrire est:
ou bien :

char * fmt ="Texte\n";
printf ("%s", fmt);

ou bien :

const char * fmt ="Texte\n";
printf (fmt);

A+

pingouinux · Le 15/08/2013, à 06:46

Bonjour Melrock ,
J'obtiens aussi le warning avec ton exemple n°2.

grim7reaper · Le 15/08/2013, à 08:28

Ce qui est tout à fait normal, vu que l’usage de printf dans son exemple 2 est mauvais.
printf c’est pour afficher du texte formaté (d’où le f), pour afficher une bête chaîne de caractère, c’est puts (ou fputs) qu’il faut utiliser. Utiliser printf dans ces cas là est faux d’un point de vue sémantique.

Encore une fois, pas de surprise ce comportement est bel est bien indiqué dans la documentation de l’option :

man 1 gcc a écrit :

At present, this warns about calls to "printf" and "scanf" functions where the format string is not a string literal and there are no format arguments, as in "printf (foo);"

Au passage, appeler fmt une chaîne qui n’est pas un format c’est au minimum stupide…

Pour en rajouter une couche au sujet de « printf c’est pour des sorties formatées, l’utiliser pour du texte simple c’est de la connerie (il y a puts/fputs pour ça) ».
Le code suivant :

#include <stdio.h>

int main(void)
{
    const char* txt = "Texte";
    printf("%s\n", txt);
    return 0;
}

Compilé avec GCC en O2 :

main:
.LFB11:
	.cfi_startproc
	subq	$8, %rsp
	.cfi_def_cfa_offset 16
	movl	$.LC0, %edi
	call	puts
	xorl	%eax, %eax
	addq	$8, %rsp
	.cfi_def_cfa_offset 8
	ret
	.cfi_endproc

Compilé avec clang en O2 :

main:                                   # @main
	.cfi_startproc
# BB#0:
	pushq	%rax
.Ltmp1:
	.cfi_def_cfa_offset 16
	movl	$.L.str, %edi
	callq	puts
	xorl	%eax, %eax
	popq	%rdx
	ret
.Ltmp2:
	.size	main, .Ltmp2-main
	.cfi_endproc

Hop, sur des cas triviaux comme celui-ci, le compilo’ remarque un appel injustifié de printf et va appeler puts à la place.

MrFaelivrin · Le 16/08/2013, à 19:03

Merci pour toutes ces réponses!
J'en attendais pas autant et désolé pour le retard.

Cela dit je n'ai pas compris:

grim7reaper a écrit :

« printf c’est pour des sorties formatées, l’utiliser pour du texte simple c’est de la connerie (il y a puts/fputs pour ça) »

C'est quoi la différence entre une chaîne formatée et du texte simple?

Je n'ai jamais utilisé cette syntaxe d'assembleur (O2) ni ce compilateur clang, je devrais?
Pourquoi vous l'utilisez?

Dernière modification par MrFaelivrin (Le 16/08/2013, à 19:05)

Haleth · Le 16/08/2013, à 19:29

O2, c'est l'activation de certaines optimisations par gcc

Texte simple : "Toto"
Texte formaté : "Toto : %s"

Un texte simple est prêt à l'emploi, un texte formaté devrait être parsé et modifié avant utilisation

grim7reaper · Le 17/08/2013, à 05:21

MrFaelivrin a écrit :

C'est quoi la différence entre une chaîne formatée et du texte simple?

Comme Haleth l’a expliqué, ce que j’appelle du texte simple c’est une chaîne de caractères qui va être affichée telle quelle.
Une chaîne formatée est une chaîne qui contient des instructions de formatage qui vont être substituées par le contenu de variables.

MrFaelivrin a écrit :

Je n'ai jamais utilisé cette syntaxe d'assembleur (O2) ni ce compilateur clang, je devrais?

Comme l’a dit Halet, l’option O2 est juste là pour activer des optimisations de GCC.
Pour avoir la sortie assembleur, il suffit d’ajouter l’options -S

gcc -O2 -S toto.c

Va générer un fichier toto.s qui va contenir le code assembleur.

Pour clang, c’est à toi de voir. Pour ma part j’aime bien utiliser les deux, mais j’ai une petite préférence pour clang (code et architecture plus propre).
De toutes façons, ils génèrent du code à peu près équivalent (du moins sur architecture Intel). GCC génère encore peut-être du code un peu plus performant mais l’écart avec clang diminue version après version.

MrFaelivrin a écrit :

Pourquoi vous l'utilisez?

C’est toujours intéressant d’utiliser des compilateurs différents pour compiler un même code. Ça permet de lever certains UB (undefined behavior).
Fût un temps où clang avait des messages d’erreurs bien plus clair (surtout avec le template en C++, mais c’était vrai de manière générale) que ceux de GCC. Depuis GCC à bien progressé.

MrFaelivrin · Le 18/08/2013, à 20:58

Tout ça semble très clair désormais!

Merci pour tout!

Maintenant je compilerai toujours avec ces options! (-O2)

Après pour 'récupérer' le code en assembleur, rien ne vaut un débogueur type gdb ou objdump?

-S est encore une option pour les malades qui tentent d'optimiser du code déjà pas mal optimisé, non? Lorsque les directives de préprocesseur ne suffisent plus au programmeur!! Ahahahaahah!
Mais d'ailleurs on peut ajouter facilement du code en ASM dans du C..
Aaah la magie de ce beau langage procédural!

Dernière modification par MrFaelivrin (Le 18/08/2013, à 20:59)

grim7reaper · Le 19/08/2013, à 03:00

MrFaelivrin a écrit :

Maintenant je compilerai toujours avec ces options! (-O2)

Toujours, non.
Par exemple, quand tu débogues un programmes les optimisations ont tendance à être gênantes (des variables peuvent être supprimées ou, comme dans mon exemple, un appel de fonction est remplacé par un autre).
Mais pour compilé une version que tu veux distribuer, oui c’est souhaitable.

MrFaelivrin a écrit :

Après pour 'récupérer' le code en assembleur, rien ne vaut un débogueur type gdb ou objdump?

Pour gdb, tu peux peut-être avoir un truc équivalent.
Mais objdump ne va pas te sortir un assembleur aussi « clair » (car il a moins d’info’ que le compilateur).
Du genre, quand gcc te sort :

call	puts

objdump va te sortir un truc du genre :

callq  *(%r12,%rbx,8)

Ce qui est tout de suite moins évident
Donc je pense que si tu as le code source, mieux vaux passer par gcc. Si tu as seulement l’exécutable, oui gdb et objdump sont de bonnes solutions

MrFaelivrin a écrit :

-S est encore une option pour les malades qui tentent d'optimiser du code déjà pas mal optimisé, non? Lorsque les directives de préprocesseur ne suffisent plus au programmeur!! Ahahahaahah!
Mais d'ailleurs on peut ajouter facilement du code en ASM dans du C.

Surtout que, si c’est dans le but d’optimiser du code, ajouter de l’assembleur à la main (ou modifier celui généré par le compilateur) c’est souvent contre-productif. Les architectures modernes sont très compliqués, les compilateurs gèrent cela mieux qu’un être humain dans les cas généraux (le code optimal étant rarement le code instinctif). Pis encore, en ajoutant du code assembleur à la main, on rend le travail d’optimisation du compilateur plus difficile (en augmentant la pression sur les registres par exemple).

Donc sauf cas particuliers (embarqué, utilisation d’instructions spéciales que le compilateur n’utilisent pas), qui dans tout les cas nécessitent une connaissance fine de l’architecture sous-jacente, il ne veux mieux pas ajouter de l’assembleur (ou modifier celui généré) dans un but de performance.

MrFaelivrin · Le 19/08/2013, à 14:17

Très bonne explication, claire et concise.

Merci.

J'ai mis le topic en "RESOLU".

A bientôt!

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 09/08/2013, à 11:38

[RESOLU] Tests sécurité: autoriser les débordements de tampon.

#2 Le 09/08/2013, à 19:13

Re : [RESOLU] Tests sécurité: autoriser les débordements de tampon.

#3 Le 09/08/2013, à 20:50

Re : [RESOLU] Tests sécurité: autoriser les débordements de tampon.

#4 Le 10/08/2013, à 10:18

Re : [RESOLU] Tests sécurité: autoriser les débordements de tampon.

#5 Le 10/08/2013, à 10:33

Re : [RESOLU] Tests sécurité: autoriser les débordements de tampon.

#6 Le 14/08/2013, à 03:19

Re : [RESOLU] Tests sécurité: autoriser les débordements de tampon.

#7 Le 14/08/2013, à 06:29

Re : [RESOLU] Tests sécurité: autoriser les débordements de tampon.

#8 Le 14/08/2013, à 08:20

Re : [RESOLU] Tests sécurité: autoriser les débordements de tampon.

#9 Le 14/08/2013, à 08:38

Re : [RESOLU] Tests sécurité: autoriser les débordements de tampon.

#10 Le 14/08/2013, à 23:30

Re : [RESOLU] Tests sécurité: autoriser les débordements de tampon.

#11 Le 15/08/2013, à 06:46

Re : [RESOLU] Tests sécurité: autoriser les débordements de tampon.

#12 Le 15/08/2013, à 08:28

Re : [RESOLU] Tests sécurité: autoriser les débordements de tampon.

#13 Le 16/08/2013, à 19:03

Re : [RESOLU] Tests sécurité: autoriser les débordements de tampon.

#14 Le 16/08/2013, à 19:29

Re : [RESOLU] Tests sécurité: autoriser les débordements de tampon.

#15 Le 17/08/2013, à 05:21

Re : [RESOLU] Tests sécurité: autoriser les débordements de tampon.

#16 Le 18/08/2013, à 20:58

Re : [RESOLU] Tests sécurité: autoriser les débordements de tampon.

#17 Le 19/08/2013, à 03:00

Re : [RESOLU] Tests sécurité: autoriser les débordements de tampon.

#18 Le 19/08/2013, à 14:17

Re : [RESOLU] Tests sécurité: autoriser les débordements de tampon.

Pied de page des forums