Attention, ceci n'est pas un troll, je considere que chaque distribution
(même les plus critiqué) ont leur avantage et leur problème.
Voila, je cherche une distribution qui me conviendrait.
En faite, j'ai dejà chez moi un server en mode texte qui tourne sous Debian.
J'aime beaucoup Debian, mais voila, je souhaite aujourd'hui passer ma
station de travail (qui était encore sous Windows, car j'était étudiant
et on nous obligait a utiliser des logiciel qui n'existait pas sous
linux) sous Linux.
Bon, j'aimerais avoir de l'XGL le plus rapidement possible et un Desktop
joile a voir et bien stylé.
Mes principale application sont Firefox, OpenOffice, Thunderbird....
Ensuite, je fait beaucoup de dévellopement avec Scite, mais toute les
distrib me le permettrons sans problème.
Avant de poster ici, j'ai fait ma petite recherche et voici mes points
de vue, j'aimerais que vous me les commentiez :
Mon matos d'abord :
CM : Asus P4C800-E Delux
CPU : P4c 2.8GHz
Disque dure SERIAL ATA
GPU : NVidia GeForce 6
Debian Sarge : Trop dépasser pour XGL
Debian Etch : Impossible de l'installer depuis deja 2 semaine : je pense
que le problème est dut au disque Serial ATA, le noyaux se perd les
pedale dans le nom du disque (/dev/hda puis /dev/sdb) du coup, Fatal
error lors de l'installation de Grub.... si je ruse, que j'install une
vielle testing du moi de juillet et que j'upgrade, le noyaux ne demare
plus a cause d'un pb de udev....... Dommage, j'adore Debian....
Ubduntu : Alors, pourquoi pas ubuntu... oui mais je deteste son principe
de sudo.... alors....
Debian unstable : N'est ce pas trop instable ?? je suis pret a essayer..
Gentoo : La, je m'y interesse depuis une semaine, pourquoi pas..... mais
pourrais-je faire du XGL avec ? Sans trop trop me prendre la tête ?
Installer en Stage1 2 ou 3 ?????
Slackware : pourquoi pas, mais je ne connais pas
Suse : Pourquoi pas.... mais j'aimais bien les .deb.... enfin, je suis
tres ouvert donc
Mandriva : Le live CD m'a plus au niveau interface graphique et XGL....
mais avant je connaissait bien Mandrake jusqu'a la 6; et je n'aimais pas
trop les package RPM.... de plus, compiler un noyau sous debian est un
jeu d'enfant... sous Mandrake, je n'y était jamais arrivé...
Autre ??
J'aimerais vos point de vu OBJECTIF (en gros, les debian ça pu, Gentoo
c'est mieu sans argument, --->DEHORS ;-) )
un programme "pirate" qui vient modifier le pointeur de retour du programme "root" pour executer ce que tu veux
jusque là on est d'accord oui/non ?
si oui cela ne fct que si les deux programmes sont dans le meme espace d'adressage en gros la meme page que le gestionnaire de piles a demander via la mmu
si je ne suis pas dans la meme page il y a une exception qui est levee par la mmu oui /non
et meme si je suis dans la meme page il faut encore le trouver le fameux pointeur
alors oui mais cela ne s'appelle pas un exploit pour rien par contre creer un joyeux bordel oui mais l'autre option cela s'apparente plus a avoir du cul
Tu n'as rien compris, il n'y a pas deux programmes, il n'y en a qu'un seul, ton programme originel. Donc un seul espace d'adressage et jamais besoin de savoir l'adresse physique des choses. Dans ton programme, on remplace l'adresse de retour d'une fonction par l'adresse d'une autre fonction qu'on a introduite dans un buffer du même programme. Cette fonction se contente grosso modo d'appeler /bin/sh, si bien qu'on se trouve devant le fait que ton programme se transforme en un shell root, s'il était suid root. C'est d'une simplicité désarmante, je ne comprends pas que tu t'obstines à discourir là dessus si tu n'en connais pas le B-A-BA.
--
Michel TALON
remy <remy@fctpas.fr> wrote:
un programme "pirate"
qui vient modifier le pointeur de retour du programme "root"
pour executer ce que tu veux
jusque là on est d'accord oui/non ?
si oui cela ne fct que si les deux programmes sont dans le meme
espace d'adressage en gros la meme page que le gestionnaire de piles
a demander via la mmu
si je ne suis pas dans la meme page il y a une exception qui est levee
par la mmu oui /non
et meme si je suis dans la meme page il faut encore le trouver le fameux
pointeur
alors oui mais cela ne s'appelle pas un exploit pour rien
par contre creer un joyeux bordel oui mais l'autre option
cela s'apparente plus a avoir du cul
Tu n'as rien compris, il n'y a pas deux programmes, il n'y en a qu'un seul,
ton programme originel. Donc un seul espace d'adressage et jamais besoin de
savoir l'adresse physique des choses. Dans ton programme, on remplace
l'adresse de retour d'une fonction par l'adresse d'une autre fonction qu'on a
introduite dans un buffer du même programme. Cette fonction se contente grosso
modo d'appeler /bin/sh, si bien qu'on se trouve devant le fait que ton
programme se transforme en un shell root, s'il était suid root. C'est d'une
simplicité désarmante, je ne comprends pas que tu t'obstines à discourir là
dessus si tu n'en connais pas le B-A-BA.
un programme "pirate" qui vient modifier le pointeur de retour du programme "root" pour executer ce que tu veux
jusque là on est d'accord oui/non ?
si oui cela ne fct que si les deux programmes sont dans le meme espace d'adressage en gros la meme page que le gestionnaire de piles a demander via la mmu
si je ne suis pas dans la meme page il y a une exception qui est levee par la mmu oui /non
et meme si je suis dans la meme page il faut encore le trouver le fameux pointeur
alors oui mais cela ne s'appelle pas un exploit pour rien par contre creer un joyeux bordel oui mais l'autre option cela s'apparente plus a avoir du cul
Tu n'as rien compris, il n'y a pas deux programmes, il n'y en a qu'un seul, ton programme originel. Donc un seul espace d'adressage et jamais besoin de savoir l'adresse physique des choses. Dans ton programme, on remplace l'adresse de retour d'une fonction par l'adresse d'une autre fonction qu'on a introduite dans un buffer du même programme. Cette fonction se contente grosso modo d'appeler /bin/sh, si bien qu'on se trouve devant le fait que ton programme se transforme en un shell root, s'il était suid root. C'est d'une simplicité désarmante, je ne comprends pas que tu t'obstines à discourir là dessus si tu n'en connais pas le B-A-BA.
--
Michel TALON
remy
Oublie ces histoires de MMU, de zone memoire etc..
je ne suis meme pas sur que le gestionnaire de piles autorise les melanges entre un code usr et un code root
si tu as une linuxette sous la main
lance un process usr puis cat /proc/[pid]/maps et le meme ou un autre process avec des droits root puis cat /proc/[pid]/maps
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception la preuve http://remyaumeunier.chez-alice.fr/ remy
Oublie ces histoires de MMU, de zone memoire etc..
je ne suis meme pas sur que le gestionnaire de piles
autorise les melanges entre un code usr et un code
root
si tu as une linuxette sous la main
lance un process usr puis cat /proc/[pid]/maps
et le meme ou un autre process avec des droits root
puis cat /proc/[pid]/maps
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
la preuve http://remyaumeunier.chez-alice.fr/
remy
Oublie ces histoires de MMU, de zone memoire etc..
je ne suis meme pas sur que le gestionnaire de piles autorise les melanges entre un code usr et un code root
si tu as une linuxette sous la main
lance un process usr puis cat /proc/[pid]/maps et le meme ou un autre process avec des droits root puis cat /proc/[pid]/maps
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception la preuve http://remyaumeunier.chez-alice.fr/ remy
remy
remy wrote:
un programme "pirate" qui vient modifier le pointeur de retour du programme "root" pour executer ce que tu veux
jusque là on est d'accord oui/non ?
si oui cela ne fct que si les deux programmes sont dans le meme espace d'adressage en gros la meme page que le gestionnaire de piles a demander via la mmu
si je ne suis pas dans la meme page il y a une exception qui est levee par la mmu oui /non
et meme si je suis dans la meme page il faut encore le trouver le fameux pointeur
alors oui mais cela ne s'appelle pas un exploit pour rien par contre creer un joyeux bordel oui mais l'autre option cela s'apparente plus a avoir du cul
Tu n'as rien compris, il n'y a pas deux programmes, il n'y en a qu'un seul, ton programme originel. Donc un seul espace d'adressage et jamais besoin de savoir l'adresse physique des choses. Dans ton programme, on remplace l'adresse de retour d'une fonction par l'adresse d'une autre fonction qu'on a introduite dans un buffer du même programme. Cette fonction se contente grosso modo d'appeler /bin/sh, si bien qu'on se trouve devant le fait que ton programme se transforme en un shell root, s'il était suid root. C'est d'une simplicité désarmante, je ne comprends pas que tu t'obstines à discourir là dessus si tu n'en connais pas le B-A-BA.
donc si je te comprend
tu propose de remplacer un programme sur le disque par un autre programme root bien sur
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception la preuve http://remyaumeunier.chez-alice.fr/ remy
remy <remy@fctpas.fr> wrote:
un programme "pirate"
qui vient modifier le pointeur de retour du programme "root"
pour executer ce que tu veux
jusque là on est d'accord oui/non ?
si oui cela ne fct que si les deux programmes sont dans le meme
espace d'adressage en gros la meme page que le gestionnaire de piles
a demander via la mmu
si je ne suis pas dans la meme page il y a une exception qui est levee
par la mmu oui /non
et meme si je suis dans la meme page il faut encore le trouver le fameux
pointeur
alors oui mais cela ne s'appelle pas un exploit pour rien
par contre creer un joyeux bordel oui mais l'autre option
cela s'apparente plus a avoir du cul
Tu n'as rien compris, il n'y a pas deux programmes, il n'y en a qu'un seul,
ton programme originel. Donc un seul espace d'adressage et jamais besoin de
savoir l'adresse physique des choses. Dans ton programme, on remplace
l'adresse de retour d'une fonction par l'adresse d'une autre fonction qu'on a
introduite dans un buffer du même programme. Cette fonction se contente grosso
modo d'appeler /bin/sh, si bien qu'on se trouve devant le fait que ton
programme se transforme en un shell root, s'il était suid root. C'est d'une
simplicité désarmante, je ne comprends pas que tu t'obstines à discourir là
dessus si tu n'en connais pas le B-A-BA.
donc si je te comprend
tu propose de remplacer un programme sur le disque par un autre
programme root bien sur
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
la preuve http://remyaumeunier.chez-alice.fr/
remy
un programme "pirate" qui vient modifier le pointeur de retour du programme "root" pour executer ce que tu veux
jusque là on est d'accord oui/non ?
si oui cela ne fct que si les deux programmes sont dans le meme espace d'adressage en gros la meme page que le gestionnaire de piles a demander via la mmu
si je ne suis pas dans la meme page il y a une exception qui est levee par la mmu oui /non
et meme si je suis dans la meme page il faut encore le trouver le fameux pointeur
alors oui mais cela ne s'appelle pas un exploit pour rien par contre creer un joyeux bordel oui mais l'autre option cela s'apparente plus a avoir du cul
Tu n'as rien compris, il n'y a pas deux programmes, il n'y en a qu'un seul, ton programme originel. Donc un seul espace d'adressage et jamais besoin de savoir l'adresse physique des choses. Dans ton programme, on remplace l'adresse de retour d'une fonction par l'adresse d'une autre fonction qu'on a introduite dans un buffer du même programme. Cette fonction se contente grosso modo d'appeler /bin/sh, si bien qu'on se trouve devant le fait que ton programme se transforme en un shell root, s'il était suid root. C'est d'une simplicité désarmante, je ne comprends pas que tu t'obstines à discourir là dessus si tu n'en connais pas le B-A-BA.
donc si je te comprend
tu propose de remplacer un programme sur le disque par un autre programme root bien sur
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception la preuve http://remyaumeunier.chez-alice.fr/ remy
Nicolas George
remy , dans le message <efj3p3$6k7$, a écrit :
je ne suis meme pas sur que le gestionnaire de piles autorise les melanges entre un code usr et un code root
Ça ne veut strictement rien dire. Reviens quand tu sauras comment fonctionne un processeur.
remy , dans le message <efj3p3$6k7$1@s1.news.oleane.net>, a écrit :
je ne suis meme pas sur que le gestionnaire de piles
autorise les melanges entre un code usr et un code
root
Ça ne veut strictement rien dire. Reviens quand tu sauras comment fonctionne
un processeur.
je ne suis meme pas sur que le gestionnaire de piles autorise les melanges entre un code usr et un code root
Ça ne veut strictement rien dire. Reviens quand tu sauras comment fonctionne un processeur.
remy
je ne suis meme pas sur que le gestionnaire de piles autorise les melanges entre un code usr et un code root
Ça ne veut strictement rien dire. Reviens quand tu sauras comment fonctionne un processeur. un peu facile non ?
et au cas ou cela t'aurait échappe l'on ne parle pas du code exécutable mais des donnees non statiques variables locales et pointeur de retour des fct et c'est justement ce segment de memoire ou il est possible de faire un débordement mais pour que ce débordement soit possible il faut que cela soit dans la meme page et qu'en plus il existe la possibilité de mélanger des variables appartenant a 2 programmes différents qui n'ont pas les memes droits
d'ou justement ma question
mais je t'en pris n'hesites a parfaire mon ignorance
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception la preuve http://remyaumeunier.chez-alice.fr/ remy
je ne suis meme pas sur que le gestionnaire de piles
autorise les melanges entre un code usr et un code
root
Ça ne veut strictement rien dire. Reviens quand tu sauras comment fonctionne
un processeur.
un peu facile non ?
et au cas ou cela t'aurait échappe l'on ne parle pas
du code exécutable mais des donnees non statiques variables locales
et pointeur de retour des fct
et c'est justement ce segment de memoire ou il est possible
de faire un débordement mais pour que ce débordement soit possible
il faut que cela soit dans la meme page et qu'en plus il existe la
possibilité de mélanger des variables appartenant a 2 programmes
différents qui n'ont pas les memes droits
d'ou justement ma question
mais je t'en pris n'hesites a parfaire mon ignorance
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
la preuve http://remyaumeunier.chez-alice.fr/
remy
je ne suis meme pas sur que le gestionnaire de piles autorise les melanges entre un code usr et un code root
Ça ne veut strictement rien dire. Reviens quand tu sauras comment fonctionne un processeur. un peu facile non ?
et au cas ou cela t'aurait échappe l'on ne parle pas du code exécutable mais des donnees non statiques variables locales et pointeur de retour des fct et c'est justement ce segment de memoire ou il est possible de faire un débordement mais pour que ce débordement soit possible il faut que cela soit dans la meme page et qu'en plus il existe la possibilité de mélanger des variables appartenant a 2 programmes différents qui n'ont pas les memes droits
d'ou justement ma question
mais je t'en pris n'hesites a parfaire mon ignorance
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception la preuve http://remyaumeunier.chez-alice.fr/ remy
talon
remy wrote:
de faire un débordement mais pour que ce débordement soit possible il faut que cela soit dans la meme page et qu'en plus il existe la
Non il n'y a aucun besoin que ce soit dans la même page, retire toi ces conneries de la tête. Les seules adresses qui comptent sont les adresses virtuelles dans l'espace d'adressage d'un seul processus. Lis la documentation que je t'ai siganlée et reviens nous voir *quand tu auras compris* et pas sur la base de documents débiles parus sur des journaux français qui ne sont même pas bons à servir de papier chiotte.
possibilité de mélanger des variables appartenant a 2 programmes différents qui n'ont pas les memes droits
Il n'y a pas 2 programmes différents, jamais. Il n'y a pas deux systèmes de droits différents, jamais, et de toute façon tu ferais d'abord mieux de te renseigner pour savoir quels sont les systèmes de protection gérés par le hardware x86 sur une page.
d'ou justement ma question
En tout état de cause tu n'as aucune question à te poser puisque les programmes de débordement de pile existent et fonctionnent. Ca prouve bien que toutes les objections que tu fais sont fausses, si tu avais un peu de plomb dans la cervelle.
mais je t'en pris n'hesites a parfaire mon ignorance
--
Michel TALON
remy <remy@fctpas.fr> wrote:
de faire un débordement mais pour que ce débordement soit possible
il faut que cela soit dans la meme page et qu'en plus il existe la
Non il n'y a aucun besoin que ce soit dans la même page, retire toi ces
conneries de la tête. Les seules adresses qui comptent sont les adresses
virtuelles dans l'espace d'adressage d'un seul processus. Lis la documentation
que je t'ai siganlée et reviens nous voir *quand tu auras compris* et pas sur
la base de documents débiles parus sur des journaux français qui ne sont même
pas bons à servir de papier chiotte.
possibilité de mélanger des variables appartenant a 2 programmes
différents qui n'ont pas les memes droits
Il n'y a pas 2 programmes différents, jamais. Il n'y a pas deux systèmes de
droits différents, jamais, et de toute façon tu ferais d'abord mieux de te
renseigner pour savoir quels sont les systèmes de protection gérés par le
hardware x86 sur une page.
d'ou justement ma question
En tout état de cause tu n'as aucune question à te poser puisque les
programmes de débordement de pile existent et fonctionnent. Ca prouve bien que
toutes les objections que tu fais sont fausses, si tu avais un peu de plomb
dans la cervelle.
mais je t'en pris n'hesites a parfaire mon ignorance
de faire un débordement mais pour que ce débordement soit possible il faut que cela soit dans la meme page et qu'en plus il existe la
Non il n'y a aucun besoin que ce soit dans la même page, retire toi ces conneries de la tête. Les seules adresses qui comptent sont les adresses virtuelles dans l'espace d'adressage d'un seul processus. Lis la documentation que je t'ai siganlée et reviens nous voir *quand tu auras compris* et pas sur la base de documents débiles parus sur des journaux français qui ne sont même pas bons à servir de papier chiotte.
possibilité de mélanger des variables appartenant a 2 programmes différents qui n'ont pas les memes droits
Il n'y a pas 2 programmes différents, jamais. Il n'y a pas deux systèmes de droits différents, jamais, et de toute façon tu ferais d'abord mieux de te renseigner pour savoir quels sont les systèmes de protection gérés par le hardware x86 sur une page.
d'ou justement ma question
En tout état de cause tu n'as aucune question à te poser puisque les programmes de débordement de pile existent et fonctionnent. Ca prouve bien que toutes les objections que tu fais sont fausses, si tu avais un peu de plomb dans la cervelle.
mais je t'en pris n'hesites a parfaire mon ignorance
--
Michel TALON
talon
remy wrote:
donc si je te comprend
tu propose de remplacer un programme sur le disque par un autre programme root bien sur
Non, pas sur le disque, uniquement en mémoire. Tu introduis exec /bin/sh dans un tableau de la pile destiné à recevoir des données du problème, et tu te démerdes pour que le pointeur de retour de la fonction se servant de ce buffer soit écrasé et remplacé par un pointeur vers ce bout de merde. C'est aussi simple que ça, à des petits détails près - il faut progarmmer exec /bin/sh en assembleur pour que ça fasse une "string" dépourvue de 0. (Parceque 0 signifie une fin de string). Et c'est tout. Quand tu auras compris ça, tu auras compris pourquoi tout est vulnérable ou presque. La magie de ce truc, c'est que tu peux en trouver essentiellement partout, tant que les gens ne comptent pas *très* soigneusement les caractères qu'ils mettent dans un buffer, pour être sûrs que l'adresse de retour ne peut pas être écrasée. Par exemple tu peux introduir cette merde dans une image pour que xv se transforme en /bin/sh quand tu regardes l'image, etc.
--
Michel TALON
remy <remy@fctpas.fr> wrote:
donc si je te comprend
tu propose de remplacer un programme sur le disque par un autre
programme root bien sur
Non, pas sur le disque, uniquement en mémoire. Tu introduis
exec /bin/sh
dans un tableau de la pile destiné à recevoir des données du problème, et tu te
démerdes pour que le pointeur de retour de la fonction se servant de ce buffer
soit écrasé et remplacé par un pointeur vers ce bout de merde. C'est aussi
simple que ça, à des petits détails près - il faut progarmmer exec /bin/sh en
assembleur pour que ça fasse une "string" dépourvue de 0. (Parceque 0 signifie
une fin de string). Et c'est tout. Quand tu auras compris ça, tu auras compris
pourquoi tout est vulnérable ou presque. La magie de ce truc, c'est que tu
peux en trouver essentiellement partout, tant que les gens ne comptent pas
*très* soigneusement les caractères qu'ils mettent dans un buffer, pour être
sûrs que l'adresse de retour ne peut pas être écrasée. Par exemple tu peux
introduir cette merde dans une image pour que xv se transforme en /bin/sh
quand tu regardes l'image, etc.
tu propose de remplacer un programme sur le disque par un autre programme root bien sur
Non, pas sur le disque, uniquement en mémoire. Tu introduis exec /bin/sh dans un tableau de la pile destiné à recevoir des données du problème, et tu te démerdes pour que le pointeur de retour de la fonction se servant de ce buffer soit écrasé et remplacé par un pointeur vers ce bout de merde. C'est aussi simple que ça, à des petits détails près - il faut progarmmer exec /bin/sh en assembleur pour que ça fasse une "string" dépourvue de 0. (Parceque 0 signifie une fin de string). Et c'est tout. Quand tu auras compris ça, tu auras compris pourquoi tout est vulnérable ou presque. La magie de ce truc, c'est que tu peux en trouver essentiellement partout, tant que les gens ne comptent pas *très* soigneusement les caractères qu'ils mettent dans un buffer, pour être sûrs que l'adresse de retour ne peut pas être écrasée. Par exemple tu peux introduir cette merde dans une image pour que xv se transforme en /bin/sh quand tu regardes l'image, etc.
--
Michel TALON
remy
remy wrote:
de faire un débordement mais pour que ce débordement soit possible il faut que cela soit dans la meme page et qu'en plus il existe la
Non il n'y a aucun besoin que ce soit dans la même page, retire toi ces conneries de la tête. Les seules adresses qui comptent sont les adresses virtuelles dans l'espace d'adressage d'un seul processus. Lis la documentation que je t'ai siganlée et reviens nous voir *quand tu auras compris*
je les ai lus ce ne sont que des cas d'ecole qui mettent en oeuvre un seul processus ce qui discredite le hack
et pas sur la base de documents débiles parus sur des journaux français qui ne sont même pas bons à servir de papier chiotte.
possibilité de mélanger des variables appartenant a 2 programmes différents qui n'ont pas les memes droits
Il n'y a pas 2 programmes différents, jamais. Il n'y a pas deux systèmes de droits différents, jamais, et de toute façon tu ferais d'abord mieux de te renseigner pour savoir quels sont les systèmes de protection gérés par le hardware x86 sur une page.
bon d'accord l'on a donc un seul programme qui de maniere spontanee cree des programmes root
je crois que sur ce coup t'es pas clair et un peu largue
d'ou justement ma question
En tout état de cause tu n'as aucune question à te poser puisque les programmes de débordement de pile existent et fonctionnent. Ca prouve bien que toutes les objections que tu fais sont fausses, si tu avais un peu de plomb dans la cervelle.
mais je t'en pris n'hesites a parfaire mon ignorance
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception la preuve http://remyaumeunier.chez-alice.fr/ remy
remy <remy@fctpas.fr> wrote:
de faire un débordement mais pour que ce débordement soit possible
il faut que cela soit dans la meme page et qu'en plus il existe la
Non il n'y a aucun besoin que ce soit dans la même page, retire toi ces
conneries de la tête. Les seules adresses qui comptent sont les adresses
virtuelles dans l'espace d'adressage d'un seul processus. Lis la documentation
que je t'ai siganlée et reviens nous voir *quand tu auras compris*
je les ai lus ce ne sont que des cas d'ecole
qui mettent en oeuvre un seul processus ce qui discredite le hack
et pas sur
la base de documents débiles parus sur des journaux français qui ne sont même
pas bons à servir de papier chiotte.
possibilité de mélanger des variables appartenant a 2 programmes
différents qui n'ont pas les memes droits
Il n'y a pas 2 programmes différents, jamais. Il n'y a pas deux systèmes de
droits différents, jamais, et de toute façon tu ferais d'abord mieux de te
renseigner pour savoir quels sont les systèmes de protection gérés par le
hardware x86 sur une page.
bon d'accord l'on a donc un seul programme qui de maniere spontanee cree
des programmes root
je crois que sur ce coup t'es pas clair et un peu largue
d'ou justement ma question
En tout état de cause tu n'as aucune question à te poser puisque les
programmes de débordement de pile existent et fonctionnent. Ca prouve bien que
toutes les objections que tu fais sont fausses, si tu avais un peu de plomb
dans la cervelle.
mais je t'en pris n'hesites a parfaire mon ignorance
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
la preuve http://remyaumeunier.chez-alice.fr/
remy
de faire un débordement mais pour que ce débordement soit possible il faut que cela soit dans la meme page et qu'en plus il existe la
Non il n'y a aucun besoin que ce soit dans la même page, retire toi ces conneries de la tête. Les seules adresses qui comptent sont les adresses virtuelles dans l'espace d'adressage d'un seul processus. Lis la documentation que je t'ai siganlée et reviens nous voir *quand tu auras compris*
je les ai lus ce ne sont que des cas d'ecole qui mettent en oeuvre un seul processus ce qui discredite le hack
et pas sur la base de documents débiles parus sur des journaux français qui ne sont même pas bons à servir de papier chiotte.
possibilité de mélanger des variables appartenant a 2 programmes différents qui n'ont pas les memes droits
Il n'y a pas 2 programmes différents, jamais. Il n'y a pas deux systèmes de droits différents, jamais, et de toute façon tu ferais d'abord mieux de te renseigner pour savoir quels sont les systèmes de protection gérés par le hardware x86 sur une page.
bon d'accord l'on a donc un seul programme qui de maniere spontanee cree des programmes root
je crois que sur ce coup t'es pas clair et un peu largue
d'ou justement ma question
En tout état de cause tu n'as aucune question à te poser puisque les programmes de débordement de pile existent et fonctionnent. Ca prouve bien que toutes les objections que tu fais sont fausses, si tu avais un peu de plomb dans la cervelle.
mais je t'en pris n'hesites a parfaire mon ignorance
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception la preuve http://remyaumeunier.chez-alice.fr/ remy
remy
remy wrote:
donc si je te comprend tu propose de remplacer un programme sur le disque par un autre programme root bien sur
Non, pas sur le disque, uniquement en mémoire. Tu introduis exec /bin/sh dans un tableau de la pile destiné à recevoir des données du problème, et tu te démerdes pour que le pointeur de retour de la fonction se servant de ce buffer soit écrasé et remplacé par un pointeur vers ce bout de merde.
donc 2 processus et l'on repart sur la problématique du debut
C'est aussi
simple que ça, à des petits détails près - il faut progarmmer exec /bin/sh en assembleur pour que ça fasse une "string" dépourvue de 0. (Parceque 0 signifie une fin de string). Et c'est tout. Quand tu auras compris ça, tu auras compris pourquoi tout est vulnérable ou presque. La magie de ce truc, c'est que tu peux en trouver essentiellement partout, tant que les gens ne comptent pas *très* soigneusement les caractères qu'ils mettent dans un buffer, pour être sûrs que l'adresse de retour ne peut pas être écrasée. Par exemple tu peux introduir cette merde dans une image pour que xv se transforme en /bin/sh quand tu regardes l'image, etc.
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception la preuve http://remyaumeunier.chez-alice.fr/ remy
remy <remy@fctpas.fr> wrote:
donc si je te comprend
tu propose de remplacer un programme sur le disque par un autre
programme root bien sur
Non, pas sur le disque, uniquement en mémoire. Tu introduis
exec /bin/sh
dans un tableau de la pile destiné à recevoir des données du problème, et tu te
démerdes pour que le pointeur de retour de la fonction se servant de ce buffer
soit écrasé et remplacé par un pointeur vers ce bout de merde.
donc 2 processus et l'on repart sur la problématique du debut
C'est aussi
simple que ça, à des petits détails près - il faut progarmmer exec /bin/sh en
assembleur pour que ça fasse une "string" dépourvue de 0. (Parceque 0 signifie
une fin de string). Et c'est tout. Quand tu auras compris ça, tu auras compris
pourquoi tout est vulnérable ou presque. La magie de ce truc, c'est que tu
peux en trouver essentiellement partout, tant que les gens ne comptent pas
*très* soigneusement les caractères qu'ils mettent dans un buffer, pour être
sûrs que l'adresse de retour ne peut pas être écrasée. Par exemple tu peux
introduir cette merde dans une image pour que xv se transforme en /bin/sh
quand tu regardes l'image, etc.
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
la preuve http://remyaumeunier.chez-alice.fr/
remy
donc si je te comprend tu propose de remplacer un programme sur le disque par un autre programme root bien sur
Non, pas sur le disque, uniquement en mémoire. Tu introduis exec /bin/sh dans un tableau de la pile destiné à recevoir des données du problème, et tu te démerdes pour que le pointeur de retour de la fonction se servant de ce buffer soit écrasé et remplacé par un pointeur vers ce bout de merde.
donc 2 processus et l'on repart sur la problématique du debut
C'est aussi
simple que ça, à des petits détails près - il faut progarmmer exec /bin/sh en assembleur pour que ça fasse une "string" dépourvue de 0. (Parceque 0 signifie une fin de string). Et c'est tout. Quand tu auras compris ça, tu auras compris pourquoi tout est vulnérable ou presque. La magie de ce truc, c'est que tu peux en trouver essentiellement partout, tant que les gens ne comptent pas *très* soigneusement les caractères qu'ils mettent dans un buffer, pour être sûrs que l'adresse de retour ne peut pas être écrasée. Par exemple tu peux introduir cette merde dans une image pour que xv se transforme en /bin/sh quand tu regardes l'image, etc.
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception la preuve http://remyaumeunier.chez-alice.fr/ remy
Côme Desplats
remy wrote:
donc 2 processus et l'on repart sur la problématique du debut
Non, exec() remplace le processus courant.
remy wrote:
donc 2 processus et l'on repart sur la problématique du debut
