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 ;-) )
Non, pas du tout, c'est totalement irrelevant. Quand tu appelles une fonction dans ton programme, tu ne te préoccupes pas de savoir à quelle adresse physique elle va se trouver dans la machine, c'est exactement pareil pour le code qui profite d'un débordement de pile. Tu dois modifier l'adresse de retour dans la pile vers l' adresse d'un code que tu as logé dans un buffer de la pile. Toutes ces adresses sont virtuelles, et tu n'as absolument rien à foutre de la translation effectuée par la mmu pour celà. D'ailleurs idem si ton "egg" est dans le heap, sauf que c'est plus difficile de calculer l'adresse où il va se trouver, bien entendu adresse virtuelle uniquement, l'adresse physique dans la machine n'intervient *jamais*.
--
Michel TALON
remy <remy@fctpas.fr> wrote:
l'elevation de privileges. Beaucoup de conditionnels, hein? Mais il faut
croire que certaines personnes reussissent a faire mieux qu'un
plantage...
Non, pas du tout, c'est totalement irrelevant. Quand tu appelles une fonction
dans ton programme, tu ne te préoccupes pas de savoir à quelle adresse
physique elle va se trouver dans la machine, c'est exactement pareil pour le
code qui profite d'un débordement de pile. Tu dois modifier l'adresse de
retour dans la pile vers l' adresse d'un code que tu as logé dans un buffer de
la pile. Toutes ces adresses sont virtuelles, et tu n'as absolument rien à
foutre de la translation effectuée par la mmu pour celà. D'ailleurs idem si
ton "egg" est dans le heap, sauf que c'est plus difficile de calculer
l'adresse où il va se trouver, bien entendu adresse virtuelle uniquement,
l'adresse physique dans la machine n'intervient *jamais*.
Non, pas du tout, c'est totalement irrelevant. Quand tu appelles une fonction dans ton programme, tu ne te préoccupes pas de savoir à quelle adresse physique elle va se trouver dans la machine, c'est exactement pareil pour le code qui profite d'un débordement de pile. Tu dois modifier l'adresse de retour dans la pile vers l' adresse d'un code que tu as logé dans un buffer de la pile. Toutes ces adresses sont virtuelles, et tu n'as absolument rien à foutre de la translation effectuée par la mmu pour celà. D'ailleurs idem si ton "egg" est dans le heap, sauf que c'est plus difficile de calculer l'adresse où il va se trouver, bien entendu adresse virtuelle uniquement, l'adresse physique dans la machine n'intervient *jamais*.
--
Michel TALON
remy
remy wrote:
l'elevation de privileges. Beaucoup de conditionnels, hein? Mais il faut croire que certaines personnes reussissent a faire mieux qu'un plantage... http://www.stielec.ac-aix-marseille.fr/cours/caleca/pc/mmu.html
tables de translation c'est chiant non ?
Non, pas du tout, c'est totalement irrelevant. Quand tu appelles une fonction dans ton programme, tu ne te préoccupes pas de savoir à quelle adresse physique elle va se trouver dans la machine, c'est exactement pareil pour le code qui profite d'un débordement de pile. Tu dois modifier l'adresse de retour dans la pile vers l' adresse d'un code que tu as logé dans un buffer de la pile. Toutes ces adresses sont virtuelles, et tu n'as absolument rien à foutre de la translation effectuée par la mmu pour celà. D'ailleurs idem si ton "egg" est dans le heap, sauf que c'est plus difficile de calculer l'adresse où il va se trouver, bien entendu adresse virtuelle uniquement, l'adresse physique dans la machine n'intervient *jamais*.
ok l'on ne parle pas vraiment de la meme attaque
toi tu dis un buffeur du code et je deroute l'execution d'un code pour executer le buffeur
perso je pensais plutot a un code avec faille je cree un debordement de buffeur qui contient du code malveillant
ce qui implique que l'execution se fait naturellement via l'execution du code avec faille mais pose le probleme de la localisation du code avec faille
donc avec ton approche il faut derouter une execution pour pouvoir executer ton buffeur
tu fais comment par debordement mais dans ce cas vraiment tres tres bien calculé oui mais comment?
-- 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:
l'elevation de privileges. Beaucoup de conditionnels, hein? Mais il faut
croire que certaines personnes reussissent a faire mieux qu'un
plantage...
http://www.stielec.ac-aix-marseille.fr/cours/caleca/pc/mmu.html
tables de translation c'est chiant non ?
Non, pas du tout, c'est totalement irrelevant. Quand tu appelles une fonction
dans ton programme, tu ne te préoccupes pas de savoir à quelle adresse
physique elle va se trouver dans la machine, c'est exactement pareil pour le
code qui profite d'un débordement de pile. Tu dois modifier l'adresse de
retour dans la pile vers l' adresse d'un code que tu as logé dans un buffer de
la pile. Toutes ces adresses sont virtuelles, et tu n'as absolument rien à
foutre de la translation effectuée par la mmu pour celà. D'ailleurs idem si
ton "egg" est dans le heap, sauf que c'est plus difficile de calculer
l'adresse où il va se trouver, bien entendu adresse virtuelle uniquement,
l'adresse physique dans la machine n'intervient *jamais*.
ok l'on ne parle pas vraiment de la meme attaque
toi tu dis un buffeur du code et je deroute l'execution d'un code
pour executer le buffeur
perso je pensais plutot a un code avec faille je cree un debordement de
buffeur qui contient du code malveillant
ce qui implique que l'execution se fait naturellement via l'execution
du code avec faille mais pose le probleme de la localisation du code
avec faille
donc avec ton approche il faut derouter une execution pour
pouvoir executer ton buffeur
tu fais comment par debordement mais dans ce cas vraiment tres tres bien
calculé oui mais comment?
--
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
l'elevation de privileges. Beaucoup de conditionnels, hein? Mais il faut croire que certaines personnes reussissent a faire mieux qu'un plantage... http://www.stielec.ac-aix-marseille.fr/cours/caleca/pc/mmu.html
tables de translation c'est chiant non ?
Non, pas du tout, c'est totalement irrelevant. Quand tu appelles une fonction dans ton programme, tu ne te préoccupes pas de savoir à quelle adresse physique elle va se trouver dans la machine, c'est exactement pareil pour le code qui profite d'un débordement de pile. Tu dois modifier l'adresse de retour dans la pile vers l' adresse d'un code que tu as logé dans un buffer de la pile. Toutes ces adresses sont virtuelles, et tu n'as absolument rien à foutre de la translation effectuée par la mmu pour celà. D'ailleurs idem si ton "egg" est dans le heap, sauf que c'est plus difficile de calculer l'adresse où il va se trouver, bien entendu adresse virtuelle uniquement, l'adresse physique dans la machine n'intervient *jamais*.
ok l'on ne parle pas vraiment de la meme attaque
toi tu dis un buffeur du code et je deroute l'execution d'un code pour executer le buffeur
perso je pensais plutot a un code avec faille je cree un debordement de buffeur qui contient du code malveillant
ce qui implique que l'execution se fait naturellement via l'execution du code avec faille mais pose le probleme de la localisation du code avec faille
donc avec ton approche il faut derouter une execution pour pouvoir executer ton buffeur
tu fais comment par debordement mais dans ce cas vraiment tres tres bien calculé oui mais comment?
-- 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
Michel Billaud
(Michel Talon) writes:
Michel Billaud wrote:
On connait d'_anciennes_ failles.
Oui, toi et moi on connaît d'anciennes failles, les hackers en connaissent de nouvelles, ne te fais pas de souci. Linux a été écrit, comme Windows, par des gens qui n'avaient pas grand souci de la sécurité et probablement pas de grandes connaissances à ce sujet
Linux, ou GNU/linux ?
En 94 c'était peut être vrai du noyau Linux, quand il n'était pas destiné à faire des choses sérieurses, mais après, ça a un peu changé.
Chez Microsoft ils ont toujours pu se planquer derrière le principe de sécurité par l'obscurité, alors que pour le noyau linux (et les applications) on sait qu'il y a plein de petits yeux pointus qui regardent le code. Ca incite à être prudent.
Donc on peut considérer comme un axiome qu'un hacker ayant un accés local a ipso-facto un accès root.
Tu dis ça parce que ça t'évite d'avoir à le démontrer :-)
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
talon@lpthe.jussieu.fr (Michel Talon) writes:
Michel Billaud <billaud@serveur5.labri.fr> wrote:
On connait d'_anciennes_ failles.
Oui, toi et moi on connaît d'anciennes failles, les hackers en connaissent de
nouvelles, ne te fais pas de souci. Linux a été écrit, comme Windows, par des
gens qui n'avaient pas grand souci de la sécurité et probablement pas de
grandes connaissances à ce sujet
Linux, ou GNU/linux ?
En 94 c'était peut être vrai du noyau Linux, quand il n'était pas
destiné à faire des choses sérieurses, mais après, ça a un peu changé.
Chez Microsoft ils ont toujours pu se planquer derrière le principe de
sécurité par l'obscurité, alors que pour le noyau linux (et les
applications) on sait qu'il y a plein de petits yeux pointus qui
regardent le code. Ca incite à être prudent.
Donc on peut considérer comme un axiome
qu'un hacker ayant un accés local a ipso-facto un accès root.
Tu dis ça parce que ça t'évite d'avoir à le démontrer :-)
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Oui, toi et moi on connaît d'anciennes failles, les hackers en connaissent de nouvelles, ne te fais pas de souci. Linux a été écrit, comme Windows, par des gens qui n'avaient pas grand souci de la sécurité et probablement pas de grandes connaissances à ce sujet
Linux, ou GNU/linux ?
En 94 c'était peut être vrai du noyau Linux, quand il n'était pas destiné à faire des choses sérieurses, mais après, ça a un peu changé.
Chez Microsoft ils ont toujours pu se planquer derrière le principe de sécurité par l'obscurité, alors que pour le noyau linux (et les applications) on sait qu'il y a plein de petits yeux pointus qui regardent le code. Ca incite à être prudent.
Donc on peut considérer comme un axiome qu'un hacker ayant un accés local a ipso-facto un accès root.
Tu dis ça parce que ça t'évite d'avoir à le démontrer :-)
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
nicolas vigier
On 2006-09-26, PRORIOL Fabien wrote:
J'aimerais vos point de vu OBJECTIF (en gros, les debian ça pu, Gentoo c'est mieu sans argument, --->DEHORS ;-) )
Ca sert à rien de demander des avis objectif. Personne n'est completement objectif, et encore moins ceux qui prétendent l'etre. C'est un peu comme les trolleurs qui rajoutent "je ne troll pas" à la fin de leur message trollistique ou les spammers qui rajoutent "ceci n'est pas un spam".
Bon sinon, objectivement, debian ca pux, gentoo ca sux, mandriva c'est pourri, Ubuntu c'est naze, slackware c'est deprecated, et Suse c'est de la merde.
-- http://n0x.org/ -
On 2006-09-26, PRORIOL Fabien <news-groupe@saint-pal.com> wrote:
J'aimerais vos point de vu OBJECTIF (en gros, les debian ça pu, Gentoo
c'est mieu sans argument, --->DEHORS ;-) )
Ca sert à rien de demander des avis objectif. Personne n'est completement
objectif, et encore moins ceux qui prétendent l'etre. C'est un peu comme
les trolleurs qui rajoutent "je ne troll pas" à la fin de leur message
trollistique ou les spammers qui rajoutent "ceci n'est pas un spam".
Bon sinon, objectivement, debian ca pux, gentoo ca sux, mandriva c'est
pourri, Ubuntu c'est naze, slackware c'est deprecated, et Suse c'est de
la merde.
J'aimerais vos point de vu OBJECTIF (en gros, les debian ça pu, Gentoo c'est mieu sans argument, --->DEHORS ;-) )
Ca sert à rien de demander des avis objectif. Personne n'est completement objectif, et encore moins ceux qui prétendent l'etre. C'est un peu comme les trolleurs qui rajoutent "je ne troll pas" à la fin de leur message trollistique ou les spammers qui rajoutent "ceci n'est pas un spam".
Bon sinon, objectivement, debian ca pux, gentoo ca sux, mandriva c'est pourri, Ubuntu c'est naze, slackware c'est deprecated, et Suse c'est de la merde.
-- http://n0x.org/ -
nicolas vigier
On 2006-09-26, PRORIOL Fabien wrote:
Absolument pas, je cherche une distrib qui me plaira.....
Ensuite, je pense que je pourrais arriver à installer une Gentoo, je ne suis pas un bébutant en informatique, j'ai deja configurer un server Debian en mode texte, recompilé des noyaux, etc etc....
Mais ma question est : Est-ce que la Gentoo m'aportera quelque chose de plus? Je veux dire par la, je me sent capable de l'installer, j'ai aussi la motivation pour, MAIS, n'est-ce pas du temps de perdu pour avoir presque la même chose ?
Un conseil: si tu ne veux pas perdre de temps, install cette distrib ou une autre, et teste toi meme. Ca sera plus rapide que discutter des heures des avantages possibles de chacune des distribs. Et si vraiment tu veux perdre de temps à lire des avis sur ce genre de choses, quelques recherches sur google te permettront de passer des milliers d'heures à lire des comparatifs et autres trolls sans interets sur les differentes distribs existantes.
-- http://n0x.org/ -
On 2006-09-26, PRORIOL Fabien <news-groupe@saint-pal.com> wrote:
Absolument pas, je cherche une distrib qui me plaira.....
Ensuite, je pense que je pourrais arriver à installer une Gentoo, je ne
suis pas un bébutant en informatique, j'ai deja configurer un server
Debian en mode texte, recompilé des noyaux, etc etc....
Mais ma question est :
Est-ce que la Gentoo m'aportera quelque chose de plus?
Je veux dire par la, je me sent capable de l'installer, j'ai aussi la
motivation pour, MAIS, n'est-ce pas du temps de perdu pour avoir presque
la même chose ?
Un conseil: si tu ne veux pas perdre de temps, install cette distrib ou
une autre, et teste toi meme. Ca sera plus rapide que discutter des
heures des avantages possibles de chacune des distribs. Et si vraiment
tu veux perdre de temps à lire des avis sur ce genre de choses, quelques
recherches sur google te permettront de passer des milliers d'heures à
lire des comparatifs et autres trolls sans interets sur les differentes
distribs existantes.
Absolument pas, je cherche une distrib qui me plaira.....
Ensuite, je pense que je pourrais arriver à installer une Gentoo, je ne suis pas un bébutant en informatique, j'ai deja configurer un server Debian en mode texte, recompilé des noyaux, etc etc....
Mais ma question est : Est-ce que la Gentoo m'aportera quelque chose de plus? Je veux dire par la, je me sent capable de l'installer, j'ai aussi la motivation pour, MAIS, n'est-ce pas du temps de perdu pour avoir presque la même chose ?
Un conseil: si tu ne veux pas perdre de temps, install cette distrib ou une autre, et teste toi meme. Ca sera plus rapide que discutter des heures des avantages possibles de chacune des distribs. Et si vraiment tu veux perdre de temps à lire des avis sur ce genre de choses, quelques recherches sur google te permettront de passer des milliers d'heures à lire des comparatifs et autres trolls sans interets sur les differentes distribs existantes.
-- http://n0x.org/ -
Jerome Lambert
(...)
planter un programme oui mais de la a donner des droits root a un scripte
Il y a nettement plus simple: il suffit d'accéder à une page ayant des scripts genre scripts cgi dans un formulaire, de bidouiller la réponse pour que le formulaire affiche p.ex. la page ../../../../../etc/passwd (ou shadow), de prendre ce qui s'affiche, de faire tourner un crackeur de mots de passe chez soi sur ce contenu et puis de revenir tranquillement avec les bons mots de passe. C'est en gros ce qui était arrivé dans le cas que j'ai évoqué ailleurs. là je suis d'accord les scripts cgi sont une veritable passoire
mais cela s'apparente a de la force brute et donc a un mauvais choix de mot de passe
Force brute? Un script qui merdoie et donne accès à /etc/passwd, je ne trouve pas cela d'une grande sécurité, mais chacun ses choix...
(...)
planter un programme oui mais de la a donner des droits root
a un scripte
Il y a nettement plus simple: il suffit d'accéder à une page ayant des
scripts genre scripts cgi dans un formulaire, de bidouiller la réponse
pour que le formulaire affiche p.ex. la page ../../../../../etc/passwd
(ou shadow), de prendre ce qui s'affiche, de faire tourner un crackeur
de mots de passe chez soi sur ce contenu et puis de revenir
tranquillement avec les bons mots de passe.
C'est en gros ce qui était arrivé dans le cas que j'ai évoqué ailleurs.
là je suis d'accord les scripts cgi sont une veritable passoire
mais cela s'apparente a de la force brute et donc a un mauvais choix de
mot de passe
Force brute? Un script qui merdoie et donne accès à /etc/passwd, je ne
trouve pas cela d'une grande sécurité, mais chacun ses choix...
planter un programme oui mais de la a donner des droits root a un scripte
Il y a nettement plus simple: il suffit d'accéder à une page ayant des scripts genre scripts cgi dans un formulaire, de bidouiller la réponse pour que le formulaire affiche p.ex. la page ../../../../../etc/passwd (ou shadow), de prendre ce qui s'affiche, de faire tourner un crackeur de mots de passe chez soi sur ce contenu et puis de revenir tranquillement avec les bons mots de passe. C'est en gros ce qui était arrivé dans le cas que j'ai évoqué ailleurs. là je suis d'accord les scripts cgi sont une veritable passoire
mais cela s'apparente a de la force brute et donc a un mauvais choix de mot de passe
Force brute? Un script qui merdoie et donne accès à /etc/passwd, je ne trouve pas cela d'une grande sécurité, mais chacun ses choix...
talon
remy wrote:
ce qui implique que l'execution se fait naturellement via l'execution du code avec faille mais pose le probleme de la localisation du code avec faille
Non, ce problème ne se pose pas, c'est toujours le problème de la localisation du code avec faille dans l'espace d'adressage virtuel du processus qui se pose, jamais de sa localisation dans l'espace physique de la mémoire machine. Tu aurais peut être un problème comme ça si tu comptais utiliser des débordements de buffer directement dans le noyau, dans une zone du noyau qui ne serait pas décrite par les tables de page, si ça existe, comme par exemple la mémoire video, les bus pci et les trucs comme ça que je ne connais pas. En fonctionnement normal, même quand un processus fonctionne ne mod noyau, le noyau est mappé dans l'espace d'adressage du processus, tout ça est de la mémoire virtuelle gérée avec les tables de page et tous les débordements de pile utilisent ces adresses virtuelles.
Et en outre, comme je disais, il y a bin d'autres moyens de devenir root. par exemple avec cdrecord et cdrdao on pouvait dévoyer l'écriture du .cdrecordrc ou similaire pour lui faire écrire dans /etc/passwd à la place, d'où la possibilité triviale de devenir root. Et ça a duré jusqu'à une époque récente. Il suffisait de précharger une librairie avent de lancer cdrecord ou cdrdao. On peut faire des choses fantastiques en préchargeant une librairie, regarde ce que fait fakeroot dans Debian. Si un programme suidroot est vulnérable à ce genre de choses tu es cuit. Autant partir du postulat que ton système est une passoire pour tout utilisateur local, et le restera longtemps encore.
remy <remy@fctpas.fr> wrote:
ce qui implique que l'execution se fait naturellement via l'execution
du code avec faille mais pose le probleme de la localisation du code
avec faille
Non, ce problème ne se pose pas, c'est toujours le problème de la localisation
du code avec faille dans l'espace d'adressage virtuel du processus qui se
pose, jamais de sa localisation dans l'espace physique de la mémoire machine.
Tu aurais peut être un problème comme ça si tu comptais utiliser des
débordements de buffer directement dans le noyau, dans une zone du noyau
qui ne serait pas décrite par les tables de page, si ça existe, comme par
exemple la mémoire video, les bus pci et les trucs comme ça que je ne connais
pas. En fonctionnement normal, même quand un processus fonctionne ne mod
noyau, le noyau est mappé dans l'espace d'adressage du processus, tout ça est
de la mémoire virtuelle gérée avec les tables de page et tous les débordements
de pile utilisent ces adresses virtuelles.
Et en outre, comme je disais, il y a bin d'autres moyens de devenir root. par
exemple avec cdrecord et cdrdao on pouvait dévoyer l'écriture du .cdrecordrc
ou similaire pour lui faire écrire dans /etc/passwd à la place, d'où la
possibilité triviale de devenir root. Et ça a duré jusqu'à une époque récente.
Il suffisait de précharger une librairie avent de lancer cdrecord ou cdrdao.
On peut faire des choses fantastiques en préchargeant une librairie, regarde
ce que fait fakeroot dans Debian. Si un programme suidroot est vulnérable à ce
genre de choses tu es cuit. Autant partir du postulat que ton système est une
passoire pour tout utilisateur local, et le restera longtemps encore.
ce qui implique que l'execution se fait naturellement via l'execution du code avec faille mais pose le probleme de la localisation du code avec faille
Non, ce problème ne se pose pas, c'est toujours le problème de la localisation du code avec faille dans l'espace d'adressage virtuel du processus qui se pose, jamais de sa localisation dans l'espace physique de la mémoire machine. Tu aurais peut être un problème comme ça si tu comptais utiliser des débordements de buffer directement dans le noyau, dans une zone du noyau qui ne serait pas décrite par les tables de page, si ça existe, comme par exemple la mémoire video, les bus pci et les trucs comme ça que je ne connais pas. En fonctionnement normal, même quand un processus fonctionne ne mod noyau, le noyau est mappé dans l'espace d'adressage du processus, tout ça est de la mémoire virtuelle gérée avec les tables de page et tous les débordements de pile utilisent ces adresses virtuelles.
Et en outre, comme je disais, il y a bin d'autres moyens de devenir root. par exemple avec cdrecord et cdrdao on pouvait dévoyer l'écriture du .cdrecordrc ou similaire pour lui faire écrire dans /etc/passwd à la place, d'où la possibilité triviale de devenir root. Et ça a duré jusqu'à une époque récente. Il suffisait de précharger une librairie avent de lancer cdrecord ou cdrdao. On peut faire des choses fantastiques en préchargeant une librairie, regarde ce que fait fakeroot dans Debian. Si un programme suidroot est vulnérable à ce genre de choses tu es cuit. Autant partir du postulat que ton système est une passoire pour tout utilisateur local, et le restera longtemps encore.
talon
remy wrote:
donc avec ton approche il faut derouter une execution pour pouvoir executer ton buffeur
Pour ton édification l'explication classique du débordement de buffer est l'article "smashing the stack" que tu peux trouver ici: http://insecure.org/stf/smashstack.html et qui est extrêmement clair.
--
Michel TALON
remy <remy@fctpas.fr> wrote:
donc avec ton approche il faut derouter une execution pour
pouvoir executer ton buffeur
Pour ton édification l'explication classique du débordement de buffer est
l'article "smashing the stack" que tu peux trouver ici:
http://insecure.org/stf/smashstack.html
et qui est extrêmement clair.
donc avec ton approche il faut derouter une execution pour pouvoir executer ton buffeur
Pour ton édification l'explication classique du débordement de buffer est l'article "smashing the stack" que tu peux trouver ici: http://insecure.org/stf/smashstack.html et qui est extrêmement clair.
--
Michel TALON
talon
remy wrote:
donc avec ton approche il faut derouter une execution pour pouvoir executer ton buffeur
Pour ton édification l'explication classique du débordement de buffer est l'article "smashing the stack" que tu peux trouver ici: http://insecure.org/stf/smashstack.html et qui est extrêmement clair.
Et pour les exploits sur le noyau, voici une référence récente: http://phrack.ru/60/p60-0x06.txt
--
Michel TALON
remy <remy@fctpas.fr> wrote:
donc avec ton approche il faut derouter une execution pour
pouvoir executer ton buffeur
Pour ton édification l'explication classique du débordement de buffer est
l'article "smashing the stack" que tu peux trouver ici:
http://insecure.org/stf/smashstack.html
et qui est extrêmement clair.
Et pour les exploits sur le noyau, voici une référence récente:
http://phrack.ru/60/p60-0x06.txt
donc avec ton approche il faut derouter une execution pour pouvoir executer ton buffeur
Pour ton édification l'explication classique du débordement de buffer est l'article "smashing the stack" que tu peux trouver ici: http://insecure.org/stf/smashstack.html et qui est extrêmement clair.
Et pour les exploits sur le noyau, voici une référence récente: http://phrack.ru/60/p60-0x06.txt
--
Michel TALON
Laurent
Stéphane CARPENTIER wrote:
Michel Talon wrote:
PRORIOL Fabien wrote:
Voir ici : http://doc.ubuntu-fr.org/installation/compte_root OK merci de l'information ;-)
Mais par rapport a Gentoo par exemple ? quoi de mieu, quoi de moins bien ? Tu compares la distribution la plus facile à installer et à maintenir à la
plus difficile. Tu ne te trouves pas un peu bizarre dès fois?
C'est pas LFS ce qu'il y a de plus dur à installer ?
Non c'est Windows.
-- Laurent
Stéphane CARPENTIER wrote:
Michel Talon wrote:
PRORIOL Fabien <news-groupe@saint-pal.com> wrote:
Voir ici :
http://doc.ubuntu-fr.org/installation/compte_root
OK merci de l'information ;-)
Mais par rapport a Gentoo par exemple ? quoi de mieu, quoi de moins bien
?
Tu compares la distribution la plus facile à installer et à maintenir à la
plus difficile. Tu ne te trouves pas un peu bizarre dès fois?
C'est pas LFS ce qu'il y a de plus dur à installer ?
