Salut je voudrais pouvoir créer un shellcode pour freebsd .
Donc je commence par desassembler mon fichier ce qui me donne:
bash-2.05b$ objdump -d hello
Donc mon programme c'est un simple hello world:
bash-2.05b$ ./hello
Hello, world!
bash-2.05b$
Prochaine etape je veux donc créer le shellcode ce qui me donne:
bash-2.05b$ cat shellcode.c
char codeshell[] =
"\x68\x0e\x00\x00\x00\x68\x80\x80\x04\x08\x68\x01\x00\x00\x00\xb8\x04\x00\x00\x00\xe8\xe4\xff\xff\xff\x81\xc4\x0c\x00\x00\x00\x68\x00\x00\x00\x00\xb8\x01\x00\x00\x00\xe8\xcf\xff\xff\xff";
int main()
{
int *ret;
*((int *)&ret+2)=(int)codeshell;
}
bash-2.05b$ gcc shellcode.c -o shellcode
bash-2.05b$ ./shellcode
Segmentation fault (core dumped)
bash-2.05b$
Voila :(
Je me suis surement trompé pour recuperer le code hexa mais je ne sais pas
trop où ?
Il semblerait que j'ai pris des instructions en trop car:
bash-2.05b$ gdb shellcode
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
(no debugging symbols found)...
(gdb) r
Starting program: /usr/home/delete/programmation/asm/shellcode/shellcode
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x080495bd in p.0 ()
(gdb) core shellcode.core
A program is being debugged already. Kill it? (y or n) y
Core was generated by `shellcode'.
Program terminated with signal 11, Segmentation fault.
Symbols already loaded for /usr/lib/libc.so.5
Symbols already loaded for /usr/libexec/ld-elf.so.1
#0 0x080495bd in p.0 ()
(gdb)
--
Les seuls limites que nous avons sont celles que nous nous imposons !!!
Comment on exploite un buffer overflow de tas, au fait?
On fait sauter le code dans un endroit bien choisi, genre la libc. Par exemple, la fonction execl() peut lancer un programme, dont le path est fourni en paramètre. L'attaquant écrase une partie de la pile pour que non seulement l'exécution saute vers cette fonction execl() mais qu'en plus la pile présente la bonne forme à ce moment-là pour simuler un appel à execl() avec comme paramètre "/bin/sh".
Ceci ne fonctionne que si l'adresse de la libc est prévisible par l'attaquant ; c'est vrai, sauf si l'OS contient des contremesures, genre charger les bibliothèques partagées à des adresses aléatoires (ceci se fait au détriment de l'espace d'adressage disponible)(et ça ne marche pas pour les binaires statiques).
--Thomas Pornin
According to Emmanuel Dreyfus <manu@netbsd.org>:
Comment on exploite un buffer overflow de tas, au fait?
On fait sauter le code dans un endroit bien choisi, genre la libc. Par
exemple, la fonction execl() peut lancer un programme, dont le path est
fourni en paramètre. L'attaquant écrase une partie de la pile pour que
non seulement l'exécution saute vers cette fonction execl() mais qu'en
plus la pile présente la bonne forme à ce moment-là pour simuler un
appel à execl() avec comme paramètre "/bin/sh".
Ceci ne fonctionne que si l'adresse de la libc est prévisible par
l'attaquant ; c'est vrai, sauf si l'OS contient des contremesures, genre
charger les bibliothèques partagées à des adresses aléatoires (ceci se
fait au détriment de l'espace d'adressage disponible)(et ça ne marche
pas pour les binaires statiques).
Comment on exploite un buffer overflow de tas, au fait?
On fait sauter le code dans un endroit bien choisi, genre la libc. Par exemple, la fonction execl() peut lancer un programme, dont le path est fourni en paramètre. L'attaquant écrase une partie de la pile pour que non seulement l'exécution saute vers cette fonction execl() mais qu'en plus la pile présente la bonne forme à ce moment-là pour simuler un appel à execl() avec comme paramètre "/bin/sh".
Ceci ne fonctionne que si l'adresse de la libc est prévisible par l'attaquant ; c'est vrai, sauf si l'OS contient des contremesures, genre charger les bibliothèques partagées à des adresses aléatoires (ceci se fait au détriment de l'espace d'adressage disponible)(et ça ne marche pas pour les binaires statiques).
--Thomas Pornin
Julien Bordet
Ah. J'etais pourtant persuade que .data serait marque non-executable pour les 386 sous Free. Merci de ta precision.
Le fait que cela soit marqué dans le binaire n'implique pas que cela soit géré au niveau du noyau, que ce soit du fait du noyau lui-même ou du processeur sur lequel tourne le-dit noyau.
Ah. J'etais pourtant persuade que .data serait marque non-executable
pour les 386 sous Free. Merci de ta precision.
Le fait que cela soit marqué dans le binaire n'implique pas que cela
soit géré au niveau du noyau, que ce soit du fait du noyau lui-même ou
du processeur sur lequel tourne le-dit noyau.
Ah. J'etais pourtant persuade que .data serait marque non-executable pour les 386 sous Free. Merci de ta precision.
Le fait que cela soit marqué dans le binaire n'implique pas que cela soit géré au niveau du noyau, que ce soit du fait du noyau lui-même ou du processeur sur lequel tourne le-dit noyau.
Marwan FeanoR/var Burelle
On Mon, 1 Dec 2003 22:51:23 +0100 (Xavier) wrote:
Parce que de nouvelles fonctionnalités dans le noyau, on peut en trouver jusqu'à 1.6ZZZZZ et ne jamais avoir 2.0.
Mais non, Manu nous a affirmé que ... ah oui, c'est vrai, ça n'engage que lui et on ne peut pas répéter et déformer ;)
On en a déja parlé ici meme, et je reste sur ma position décrite en (également disponible en http://groups.google.fr/groups?selm=slrnbqhoh7.jrc.miod%40vetre.gentiane.org
Y a-t-il eu du nouveau depuis ?
Il le fait pour la pile, ce qui est de loin le plus souvent exploité. Pour le tas ca n'est pas encore fait, Chuck y travaille justement en ce moment (cf posts sur tech-kern). Comment on exploite un buffer overflow de tas, au fait?
Après consultation desdits messages, il s'avère que NetBSD n'a pour le moment que la pile non exécutable sur les architectures kivonbien (c) (r) (tm).
Il me semblait qu'il en avait commité un peu plus. On est encore loin de W^X.
Sur l'exploitation du tas, je n'ai rajouter à la réponse de TP.
[NetBSD et W^X]
FWIW rien du tout.
On en a déja parlé ici meme, et je reste sur ma position décrite en
<slrnbqhoh7.jrc.miod@vetre.gentiane.org> (également disponible en
http://groups.google.fr/groups?selm=slrnbqhoh7.jrc.miod%40vetre.gentiane.org
Y a-t-il eu du nouveau depuis ?
Il le fait pour la pile, ce qui est de loin le plus souvent exploité.
Pour le tas ca n'est pas encore fait, Chuck y travaille justement en ce
moment (cf posts sur tech-kern). Comment on exploite un buffer overflow
de tas, au fait?
Après consultation desdits messages, il s'avère que NetBSD n'a pour le
moment que la pile non exécutable sur les architectures kivonbien (c)
(r) (tm).
Il me semblait qu'il en avait commité un peu plus. On est encore loin de
W^X.
Sur l'exploitation du tas, je n'ai rajouter à la réponse de TP.
On en a déja parlé ici meme, et je reste sur ma position décrite en (également disponible en http://groups.google.fr/groups?selm=slrnbqhoh7.jrc.miod%40vetre.gentiane.org
Y a-t-il eu du nouveau depuis ?
Il le fait pour la pile, ce qui est de loin le plus souvent exploité. Pour le tas ca n'est pas encore fait, Chuck y travaille justement en ce moment (cf posts sur tech-kern). Comment on exploite un buffer overflow de tas, au fait?
Après consultation desdits messages, il s'avère que NetBSD n'a pour le moment que la pile non exécutable sur les architectures kivonbien (c) (r) (tm).
Il me semblait qu'il en avait commité un peu plus. On est encore loin de W^X.
Sur l'exploitation du tas, je n'ai rajouter à la réponse de TP.
pornin
According to Emmanuel Dreyfus :
Comment on exploite un buffer overflow de tas, au fait?
À la réflexion, je me demande si j'ai bien compris cette question. Mon autre réponse dit (succintement) comment on exploite un buffer overflow quand le buffer overflow est dans la pile mais que la pile n'est pas exécutable.
Pour ce qui est d'un buffer overflow quand le buffer n'est pas dans la pile, l'exploitation est beaucoup plus aléatoire. Tout dépend de ce qu'on peut arriver à écraser. Si on est dans un bloc alloué avec malloc(), on peut éventuellement arriver à écraser des informations de contrôle utilisées par malloc() pour faire son boulot, et donc faire partir l'application plus ou moins dans l'espace lors d'un prochain malloc() ou free(). Si l'attaquant a beaucoup de chance, il peut écraser un pointeur vers fonction et se ramener au cas précédent (faire sauter l'exécution où il veut).
Quand on programme en C, les pointeurs vers fonction sont assez rares ; en revanche, on en a pas mal en C++ (l'implémentation des méthodes "virtual" passe classiquement par des indirections de ce genre). Ceci peut être un argument (de très mauvaise foi, certes, mais un argument quand même) pour dire que le C++ favorise les attaques...
--Thomas Pornin
According to Emmanuel Dreyfus <manu@netbsd.org>:
Comment on exploite un buffer overflow de tas, au fait?
À la réflexion, je me demande si j'ai bien compris cette question.
Mon autre réponse dit (succintement) comment on exploite un buffer
overflow quand le buffer overflow est dans la pile mais que la pile
n'est pas exécutable.
Pour ce qui est d'un buffer overflow quand le buffer n'est pas dans
la pile, l'exploitation est beaucoup plus aléatoire. Tout dépend de
ce qu'on peut arriver à écraser. Si on est dans un bloc alloué avec
malloc(), on peut éventuellement arriver à écraser des informations de
contrôle utilisées par malloc() pour faire son boulot, et donc faire
partir l'application plus ou moins dans l'espace lors d'un prochain
malloc() ou free(). Si l'attaquant a beaucoup de chance, il peut écraser
un pointeur vers fonction et se ramener au cas précédent (faire sauter
l'exécution où il veut).
Quand on programme en C, les pointeurs vers fonction sont assez rares ;
en revanche, on en a pas mal en C++ (l'implémentation des méthodes
"virtual" passe classiquement par des indirections de ce genre). Ceci
peut être un argument (de très mauvaise foi, certes, mais un argument
quand même) pour dire que le C++ favorise les attaques...
Comment on exploite un buffer overflow de tas, au fait?
À la réflexion, je me demande si j'ai bien compris cette question. Mon autre réponse dit (succintement) comment on exploite un buffer overflow quand le buffer overflow est dans la pile mais que la pile n'est pas exécutable.
Pour ce qui est d'un buffer overflow quand le buffer n'est pas dans la pile, l'exploitation est beaucoup plus aléatoire. Tout dépend de ce qu'on peut arriver à écraser. Si on est dans un bloc alloué avec malloc(), on peut éventuellement arriver à écraser des informations de contrôle utilisées par malloc() pour faire son boulot, et donc faire partir l'application plus ou moins dans l'espace lors d'un prochain malloc() ou free(). Si l'attaquant a beaucoup de chance, il peut écraser un pointeur vers fonction et se ramener au cas précédent (faire sauter l'exécution où il veut).
Quand on programme en C, les pointeurs vers fonction sont assez rares ; en revanche, on en a pas mal en C++ (l'implémentation des méthodes "virtual" passe classiquement par des indirections de ce genre). Ceci peut être un argument (de très mauvaise foi, certes, mais un argument quand même) pour dire que le C++ favorise les attaques...
--Thomas Pornin
Miod Vallat
Quand on programme en C, les pointeurs vers fonction sont assez rares ;
atexit est tout de même pas mal utilisé.
Quand on programme en C, les pointeurs vers fonction sont assez rares ;
Quand on programme en C, les pointeurs vers fonction sont assez rares ;
atexit est tout de même pas mal utilisé.
pornin
According to Miod Vallat :
atexit est tout de même pas mal utilisé.
Ça reste relativement mineur comme usage. Les pointeurs de fonction correspondants sont regroupés. Dans le cas d'un FreeBSD, les 32 premiers pointeurs (les seuls garantis par ISO C et Single Unix) sont dans une zone de mémoire statique, pas forcément le plus facile à atteindre par un buffer overflow.
--Thomas Pornin
According to Miod Vallat <miod@online.fr>:
atexit est tout de même pas mal utilisé.
Ça reste relativement mineur comme usage. Les pointeurs de fonction
correspondants sont regroupés. Dans le cas d'un FreeBSD, les 32 premiers
pointeurs (les seuls garantis par ISO C et Single Unix) sont dans une
zone de mémoire statique, pas forcément le plus facile à atteindre par
un buffer overflow.
Ça reste relativement mineur comme usage. Les pointeurs de fonction correspondants sont regroupés. Dans le cas d'un FreeBSD, les 32 premiers pointeurs (les seuls garantis par ISO C et Single Unix) sont dans une zone de mémoire statique, pas forcément le plus facile à atteindre par un buffer overflow.
--Thomas Pornin
espie
In article <bqigcl$22d9$, Thomas Pornin wrote:
Quand on programme en C, les pointeurs vers fonction sont assez rares ; en revanche, on en a pas mal en C++ (l'implémentation des méthodes "virtual" passe classiquement par des indirections de ce genre). Ceci peut être un argument (de très mauvaise foi, certes, mais un argument quand même) pour dire que le C++ favorise les attaques...
Bof, non, celui-ci il est a peu pres raisonnable, en fait. Mais bon, a cote de ca, le C++ est cense te fournir une interface a peu pres propre `contre' les buffer overflow, entre std::string et std::vector, et std::list, autant de trucs de base en moins a recoder sur lesquels ne pas se tromper...
Ah, oops, evidemment, on veut utiliser le vieux code en C, et donc on a plein de char * quand meme. Damned, encore rate...
In article <bqigcl$22d9$1@biggoron.nerim.net>,
Thomas Pornin <pornin@nerim.net> wrote:
Quand on programme en C, les pointeurs vers fonction sont assez rares ;
en revanche, on en a pas mal en C++ (l'implémentation des méthodes
"virtual" passe classiquement par des indirections de ce genre). Ceci
peut être un argument (de très mauvaise foi, certes, mais un argument
quand même) pour dire que le C++ favorise les attaques...
Bof, non, celui-ci il est a peu pres raisonnable, en fait.
Mais bon, a cote de ca, le C++ est cense te fournir une interface
a peu pres propre `contre' les buffer overflow, entre std::string
et std::vector, et std::list, autant de trucs de base en moins a recoder
sur lesquels ne pas se tromper...
Ah, oops, evidemment, on veut utiliser le vieux code en C, et donc on
a plein de char * quand meme. Damned, encore rate...
Quand on programme en C, les pointeurs vers fonction sont assez rares ; en revanche, on en a pas mal en C++ (l'implémentation des méthodes "virtual" passe classiquement par des indirections de ce genre). Ceci peut être un argument (de très mauvaise foi, certes, mais un argument quand même) pour dire que le C++ favorise les attaques...
Bof, non, celui-ci il est a peu pres raisonnable, en fait. Mais bon, a cote de ca, le C++ est cense te fournir une interface a peu pres propre `contre' les buffer overflow, entre std::string et std::vector, et std::list, autant de trucs de base en moins a recoder sur lesquels ne pas se tromper...
Ah, oops, evidemment, on veut utiliser le vieux code en C, et donc on a plein de char * quand meme. Damned, encore rate...
Arnaud Launay
Le Tue, 2 Dec 2003 18:52:43 +0000 (UTC), Marc Espie écrivit:
Ah, oops, evidemment, on veut utiliser le vieux code en C, et donc on a plein de char * quand meme. Damned, encore rate...
Marc, tu es chafouin.
Arnaud.
Le Tue, 2 Dec 2003 18:52:43 +0000 (UTC), Marc Espie écrivit:
Ah, oops, evidemment, on veut utiliser le vieux code en C, et
donc on a plein de char * quand meme. Damned, encore rate...
