Bonjours,
Je commence a etudier la conception de shellcode et afin de le tester ,
j'ai le code suivant:
char sh[]="les instructions a realiser"
int main()
{
(*(void (*)()) sh)();
return (0);
}
Je ne comprend pas tres bien la ligne l'instruction qui permet "l'appel"
au shellcode a proprement parle.
J'ai l'impression que c'est un appel via un pointeur de fonction mais qui
n'aurait pas de nom.
Pourrais je avoir quelques explications ?
Merci.
Ca se pourrait. Linux a pas mal tendance, lorsqu'il y a un choix entre securite et utilisabilite, a faire pencher la balance du cote utilisabilite.
Il y a pas mal de trucs qui ont un cout, cote securite. Typiquement, si tu actives certaines fonctionnalites, il y a des trucs qui se mettent a merder, et pas qu'un peu... et ca reclame du temps ET beaucoup d'energie pour les corriger.
buffer overflow, protection memoire: tout ca casse des trucs... qui sont programmes avec les pieds et il faut les reparer.
J'ai une (trop) longue experience de la chose: du cote OpenBSD, a *chaque fois* qu'on a mis en place une mesure de securite supplementaire, ca a casse des trucs: il a fallu corriger des bugs jusque dans le serveur X et le compilateur pour eviter certains buffer overflows. Openoffice a arrete de compiler quand on a mis des pages de garde devant les allocations memoire: dmake faisait des buffer underflov un peu partout. Et il a fallu corriger des problemes jusque dans l'editeur de liens pour faire W^X: certain logiciel tres connu, un certain emacs, faisait des trucs tres, tres gore avec son segment de donnees (precisement: il supposait qu'il n'avait qu'un segment de donnees, ce qui n'est plus tres possible avec W^X).
Bref... il y a la theorie, qui va te donner des jolis systemes soit-disant secure a la SElinux... avec trois tonnes de boutons a tourner dans un sens ou dans l'autre, et des TONNES de settings que tu seras oblige de desactiver pour faire fonctionner le moindre programme un peu consequent et mal debuggue. et la realite, ou quand tu veux de la securite en plus, ben faut etre pret a mettre les mains dans le cambouis et corriger les bugs.
Quoique certains en disent, linux debian est toujours SURTOUT du premier cote...
In article <4ae5c5b6$0$999$ba4acef3@news.orange.fr>,
kregg3r <kregg3r@gmail.com> wrote:
On Mon, 26 Oct 2009 15:49:22 +0000, Marc Espie wrote:
In article <4ae5c3d9$0$999$ba4acef3@news.orange.fr>, kregg3r
<kregg3r@gmail.com> wrote:
Ca se pourrait. Linux a pas mal tendance, lorsqu'il y a un choix entre
securite et utilisabilite, a faire pencher la balance du cote utilisabilite.
Il y a pas mal de trucs qui ont un cout, cote securite. Typiquement, si tu
actives certaines fonctionnalites, il y a des trucs qui se mettent a merder,
et pas qu'un peu... et ca reclame du temps ET beaucoup d'energie pour les
corriger.
buffer overflow, protection memoire: tout ca casse des trucs... qui sont
programmes avec les pieds et il faut les reparer.
J'ai une (trop) longue experience de la chose: du cote OpenBSD, a *chaque
fois* qu'on a mis en place une mesure de securite supplementaire, ca a
casse des trucs: il a fallu corriger des bugs jusque dans le serveur X
et le compilateur pour eviter certains buffer overflows. Openoffice a arrete
de compiler quand on a mis des pages de garde devant les allocations memoire:
dmake faisait des buffer underflov un peu partout. Et il a fallu corriger
des problemes jusque dans l'editeur de liens pour faire W^X: certain
logiciel tres connu, un certain emacs, faisait des trucs tres, tres gore
avec son segment de donnees (precisement: il supposait qu'il n'avait qu'un
segment de donnees, ce qui n'est plus tres possible avec W^X).
Bref... il y a la theorie, qui va te donner des jolis systemes soit-disant
secure a la SElinux... avec trois tonnes de boutons a tourner dans un
sens ou dans l'autre, et des TONNES de settings que tu seras oblige de
desactiver pour faire fonctionner le moindre programme un peu consequent
et mal debuggue. et la realite, ou quand tu veux de la securite en plus,
ben faut etre pret a mettre les mains dans le cambouis et corriger les
bugs.
Quoique certains en disent, linux debian est toujours SURTOUT du premier
cote...
Ca se pourrait. Linux a pas mal tendance, lorsqu'il y a un choix entre securite et utilisabilite, a faire pencher la balance du cote utilisabilite.
Il y a pas mal de trucs qui ont un cout, cote securite. Typiquement, si tu actives certaines fonctionnalites, il y a des trucs qui se mettent a merder, et pas qu'un peu... et ca reclame du temps ET beaucoup d'energie pour les corriger.
buffer overflow, protection memoire: tout ca casse des trucs... qui sont programmes avec les pieds et il faut les reparer.
J'ai une (trop) longue experience de la chose: du cote OpenBSD, a *chaque fois* qu'on a mis en place une mesure de securite supplementaire, ca a casse des trucs: il a fallu corriger des bugs jusque dans le serveur X et le compilateur pour eviter certains buffer overflows. Openoffice a arrete de compiler quand on a mis des pages de garde devant les allocations memoire: dmake faisait des buffer underflov un peu partout. Et il a fallu corriger des problemes jusque dans l'editeur de liens pour faire W^X: certain logiciel tres connu, un certain emacs, faisait des trucs tres, tres gore avec son segment de donnees (precisement: il supposait qu'il n'avait qu'un segment de donnees, ce qui n'est plus tres possible avec W^X).
Bref... il y a la theorie, qui va te donner des jolis systemes soit-disant secure a la SElinux... avec trois tonnes de boutons a tourner dans un sens ou dans l'autre, et des TONNES de settings que tu seras oblige de desactiver pour faire fonctionner le moindre programme un peu consequent et mal debuggue. et la realite, ou quand tu veux de la securite en plus, ben faut etre pret a mettre les mains dans le cambouis et corriger les bugs.
Quoique certains en disent, linux debian est toujours SURTOUT du premier cote...
kregg3r
On Mon, 26 Oct 2009 17:01:41 +0000, Marc Espie wrote:
In article <4ae5c5b6$0$999$, kregg3r wrote:
On Mon, 26 Oct 2009 15:49:22 +0000, Marc Espie wrote:
In article <4ae5c3d9$0$999$, kregg3r wrote:
Effectivement je ne comprend pas pourquoi il est possible d'éxécuter ces instructions. De plus j'ai vérifié, à l'aide d'objdump, ma chaine est bien dans le segment .data (ou .rodata selon la déclaration de la chaine). Alors que se passe-t-il ? Le segment .data n'est pas vraiment un segment de données ? J'ai involontairement changé le comportement par défaut dont parlait Marc Espie ?
Peut-etre que tu ne travailles pas avec un systeme decent ?
Debian lenny avec juste les dépôts stable. C'est indécent ?
Ca se pourrait. Linux a pas mal tendance, lorsqu'il y a un choix entre securite et utilisabilite, a faire pencher la balance du cote utilisabilite.
Il y a pas mal de trucs qui ont un cout, cote securite. Typiquement, si tu actives certaines fonctionnalites, il y a des trucs qui se mettent a merder, et pas qu'un peu... et ca reclame du temps ET beaucoup d'energie pour les corriger.
buffer overflow, protection memoire: tout ca casse des trucs... qui sont programmes avec les pieds et il faut les reparer.
J'ai une (trop) longue experience de la chose: du cote OpenBSD, a *chaque fois* qu'on a mis en place une mesure de securite supplementaire, ca a casse des trucs: il a fallu corriger des bugs jusque dans le serveur X et le compilateur pour eviter certains buffer overflows. Openoffice a arrete de compiler quand on a mis des pages de garde devant les allocations memoire: dmake faisait des buffer underflov un peu partout. Et il a fallu corriger des problemes jusque dans l'editeur de liens pour faire W^X: certain logiciel tres connu, un certain emacs, faisait des trucs tres, tres gore avec son segment de donnees (precisement: il supposait qu'il n'avait qu'un segment de donnees, ce qui n'est plus tres possible avec W^X).
Bref... il y a la theorie, qui va te donner des jolis systemes soit-disant secure a la SElinux... avec trois tonnes de boutons a tourner dans un sens ou dans l'autre, et des TONNES de settings que tu seras oblige de desactiver pour faire fonctionner le moindre programme un peu consequent et mal debuggue. et la realite, ou quand tu veux de la securite en plus, ben faut etre pret a mettre les mains dans le cambouis et corriger les bugs.
Quoique certains en disent, linux debian est toujours SURTOUT du premier cote...
Merci beaucoup pour ces explications, je commence à y voir plus clair.
On Mon, 26 Oct 2009 17:01:41 +0000, Marc Espie wrote:
In article <4ae5c5b6$0$999$ba4acef3@news.orange.fr>, kregg3r
<kregg3r@gmail.com> wrote:
On Mon, 26 Oct 2009 15:49:22 +0000, Marc Espie wrote:
In article <4ae5c3d9$0$999$ba4acef3@news.orange.fr>, kregg3r
<kregg3r@gmail.com> wrote:
Effectivement je ne comprend pas pourquoi il est possible d'éxécuter
ces instructions. De plus j'ai vérifié, à l'aide d'objdump, ma chaine
est bien dans le segment .data (ou .rodata selon la déclaration de la
chaine). Alors que se passe-t-il ? Le segment .data n'est pas vraiment
un segment de données ? J'ai involontairement changé le comportement
par défaut dont parlait Marc Espie ?
Peut-etre que tu ne travailles pas avec un systeme decent ?
Debian lenny avec juste les dépôts stable. C'est indécent ?
Ca se pourrait. Linux a pas mal tendance, lorsqu'il y a un choix entre
securite et utilisabilite, a faire pencher la balance du cote
utilisabilite.
Il y a pas mal de trucs qui ont un cout, cote securite. Typiquement, si
tu actives certaines fonctionnalites, il y a des trucs qui se mettent a
merder, et pas qu'un peu... et ca reclame du temps ET beaucoup d'energie
pour les corriger.
buffer overflow, protection memoire: tout ca casse des trucs... qui sont
programmes avec les pieds et il faut les reparer.
J'ai une (trop) longue experience de la chose: du cote OpenBSD, a
*chaque fois* qu'on a mis en place une mesure de securite
supplementaire, ca a casse des trucs: il a fallu corriger des bugs
jusque dans le serveur X et le compilateur pour eviter certains buffer
overflows. Openoffice a arrete de compiler quand on a mis des pages de
garde devant les allocations memoire: dmake faisait des buffer underflov
un peu partout. Et il a fallu corriger des problemes jusque dans
l'editeur de liens pour faire W^X: certain logiciel tres connu, un
certain emacs, faisait des trucs tres, tres gore avec son segment de
donnees (precisement: il supposait qu'il n'avait qu'un segment de
donnees, ce qui n'est plus tres possible avec W^X).
Bref... il y a la theorie, qui va te donner des jolis systemes
soit-disant secure a la SElinux... avec trois tonnes de boutons a
tourner dans un sens ou dans l'autre, et des TONNES de settings que tu
seras oblige de desactiver pour faire fonctionner le moindre programme
un peu consequent et mal debuggue. et la realite, ou quand tu veux de la
securite en plus, ben faut etre pret a mettre les mains dans le cambouis
et corriger les bugs.
Quoique certains en disent, linux debian est toujours SURTOUT du premier
cote...
Merci beaucoup pour ces explications, je commence à y voir plus clair.
On Mon, 26 Oct 2009 17:01:41 +0000, Marc Espie wrote:
In article <4ae5c5b6$0$999$, kregg3r wrote:
On Mon, 26 Oct 2009 15:49:22 +0000, Marc Espie wrote:
In article <4ae5c3d9$0$999$, kregg3r wrote:
Effectivement je ne comprend pas pourquoi il est possible d'éxécuter ces instructions. De plus j'ai vérifié, à l'aide d'objdump, ma chaine est bien dans le segment .data (ou .rodata selon la déclaration de la chaine). Alors que se passe-t-il ? Le segment .data n'est pas vraiment un segment de données ? J'ai involontairement changé le comportement par défaut dont parlait Marc Espie ?
Peut-etre que tu ne travailles pas avec un systeme decent ?
Debian lenny avec juste les dépôts stable. C'est indécent ?
Ca se pourrait. Linux a pas mal tendance, lorsqu'il y a un choix entre securite et utilisabilite, a faire pencher la balance du cote utilisabilite.
Il y a pas mal de trucs qui ont un cout, cote securite. Typiquement, si tu actives certaines fonctionnalites, il y a des trucs qui se mettent a merder, et pas qu'un peu... et ca reclame du temps ET beaucoup d'energie pour les corriger.
buffer overflow, protection memoire: tout ca casse des trucs... qui sont programmes avec les pieds et il faut les reparer.
J'ai une (trop) longue experience de la chose: du cote OpenBSD, a *chaque fois* qu'on a mis en place une mesure de securite supplementaire, ca a casse des trucs: il a fallu corriger des bugs jusque dans le serveur X et le compilateur pour eviter certains buffer overflows. Openoffice a arrete de compiler quand on a mis des pages de garde devant les allocations memoire: dmake faisait des buffer underflov un peu partout. Et il a fallu corriger des problemes jusque dans l'editeur de liens pour faire W^X: certain logiciel tres connu, un certain emacs, faisait des trucs tres, tres gore avec son segment de donnees (precisement: il supposait qu'il n'avait qu'un segment de donnees, ce qui n'est plus tres possible avec W^X).
Bref... il y a la theorie, qui va te donner des jolis systemes soit-disant secure a la SElinux... avec trois tonnes de boutons a tourner dans un sens ou dans l'autre, et des TONNES de settings que tu seras oblige de desactiver pour faire fonctionner le moindre programme un peu consequent et mal debuggue. et la realite, ou quand tu veux de la securite en plus, ben faut etre pret a mettre les mains dans le cambouis et corriger les bugs.
Quoique certains en disent, linux debian est toujours SURTOUT du premier cote...
Merci beaucoup pour ces explications, je commence à y voir plus clair.
YBM
Marc Espie a écrit : ...
Ca se pourrait. Linux a pas mal tendance, lorsqu'il y a un choix entre securite et utilisabilite, a faire pencher la balance du cote utilisabilite.
Dans le genre, que penser de ça ? http://www.catonmat.net/blog/ldd-arbitrary-code-execution/
Marc Espie a écrit :
...
Ca se pourrait. Linux a pas mal tendance, lorsqu'il y a un choix entre
securite et utilisabilite, a faire pencher la balance du cote utilisabilite.
Dans le genre, que penser de ça ?
http://www.catonmat.net/blog/ldd-arbitrary-code-execution/
