Je viens de faire des mises à jours de certains programmes à cause de ce
genre de faiblesse : overflow vulnerability.
Comment que ça se fait que l'on se retrouve avec ce genre de mises à jour à
faire?
Est-ce que se sont des personnes qui ont eu des problèmes ou alors est-ce
que se sont des développeurs qui cherchent les failles pour mieux sécuriser
le système?
Qu'est-ce que ça peut provoquer comme dégâts exactement?
Est-ce que se sont des personnes qui ont eu des problèmes ou alors est-ce que se sont des développeurs qui cherchent les failles pour mieux sécuriser le système?
Ça peut être n'importe qui qui détecte la vulnérabilité. Je t'encourage vivement à aller en discuter sur fr.comp.securite.
Qu'est-ce que ça peut provoquer comme dégâts exactement?
Dans le pire des cas, ça peut permettre à un pirate d'avoir un accès root sur ta machine.
On Fri, 16 Nov 2007 18:16:14 +0100, G-raison <jairaison@wanadoo.fr>:
Est-ce que se sont des personnes qui ont eu des problèmes ou alors est-ce
que se sont des développeurs qui cherchent les failles pour mieux sécuriser
le système?
Ça peut être n'importe qui qui détecte la vulnérabilité.
Je t'encourage vivement à aller en discuter sur fr.comp.securite.
Qu'est-ce que ça peut provoquer comme dégâts exactement?
Dans le pire des cas, ça peut permettre à un pirate d'avoir un accès
root sur ta machine.
Est-ce que se sont des personnes qui ont eu des problèmes ou alors est-ce que se sont des développeurs qui cherchent les failles pour mieux sécuriser le système?
Ça peut être n'importe qui qui détecte la vulnérabilité. Je t'encourage vivement à aller en discuter sur fr.comp.securite.
Qu'est-ce que ça peut provoquer comme dégâts exactement?
Dans le pire des cas, ça peut permettre à un pirate d'avoir un accès root sur ta machine.
Nicolas S.
G-raison a écrit:
Comment que ça se fait que l'on se retrouve avec ce genre de mises à jour à faire?
C'est une mise à jour de sécurité. Libre à toi de te mettre à jou r.
Est-ce que se sont des personnes qui ont eu des problèmes
Si tel était le cas, cela devrait apparaître quelque part en majuscule, en rouge, souligné et surligné.
ou alors est-ce que se sont des développeurs qui cherchent les failles pour mieux sécuriser le système?
Pour faire simple, c'est plutôt ça. Dans les faits, il y a différentes notions qui entrent en jeu: quel type de logiciel est concerné, avec quels droits est exécuté le programme, la faille permet-elle un gagner de nouveaux droits, la faille est-elle exploitable, est-elle exploitée, le logiciel est-il accessible de l'extérieur, etc...
Qu'est-ce que ça peut provoquer comme dégâts exactement?
Chaque cas est unique.
-- Nicolas S.
G-raison <jairaison@wanadoo.fr> a écrit:
Comment que ça se fait que l'on se retrouve avec ce genre de mises à
jour à faire?
C'est une mise à jour de sécurité. Libre à toi de te mettre à jou r.
Est-ce que se sont des personnes qui ont eu des problèmes
Si tel était le cas, cela devrait apparaître quelque part en majuscule,
en rouge, souligné et surligné.
ou alors
est-ce que se sont des développeurs qui cherchent les failles pour
mieux sécuriser le système?
Pour faire simple, c'est plutôt ça. Dans les faits, il y a différentes
notions qui entrent en jeu: quel type de logiciel est concerné, avec
quels droits est exécuté le programme, la faille permet-elle un gagner
de nouveaux droits, la faille est-elle exploitable, est-elle exploitée,
le logiciel est-il accessible de l'extérieur, etc...
Qu'est-ce que ça peut provoquer comme dégâts exactement?
Comment que ça se fait que l'on se retrouve avec ce genre de mises à jour à faire?
C'est une mise à jour de sécurité. Libre à toi de te mettre à jou r.
Est-ce que se sont des personnes qui ont eu des problèmes
Si tel était le cas, cela devrait apparaître quelque part en majuscule, en rouge, souligné et surligné.
ou alors est-ce que se sont des développeurs qui cherchent les failles pour mieux sécuriser le système?
Pour faire simple, c'est plutôt ça. Dans les faits, il y a différentes notions qui entrent en jeu: quel type de logiciel est concerné, avec quels droits est exécuté le programme, la faille permet-elle un gagner de nouveaux droits, la faille est-elle exploitable, est-elle exploitée, le logiciel est-il accessible de l'extérieur, etc...
Qu'est-ce que ça peut provoquer comme dégâts exactement?
Chaque cas est unique.
-- Nicolas S.
Luc.Habert.00__arjf
G-raison :
Je viens de faire des mises à jours de certains programmes à cause de ce genre de faiblesse : overflow vulnerability.
Il y a deux sortes de trous portant ce nom : les integer overflow et les buffer overflow.
Un integer overflow, c'est quand le programmeur a oublié que les entiers qu'il manipule ne sont pas de vrais entiers. Exemple (je crois qu'il y a eu ça dans ssh à une époque) : tu as un programme A tournant au nom de root qui doit allouer un port pour le compte d'un autre programme B, A doit vérifier que le port que B lui demande d'allouer est supérieur à 1024 (seul root a le droit d'allouer des ports < 1024), B demande à A de lui allouer le port 2^16 + 1, A voit que 2^16+1 >= 1024 et alloue donc le port 1, puisque les numéros de port sont codés sur 16 bits...
Un buffer overflow, c'est quand un programme écrit au-delà de la fin d'un tableau. Typiquement, le programme A écoute ce que lui envoie un programme B sur un pipe ou une connexion réseau, B étant censé envoyer à A une suite de lignes de longueur inférieures à N, A alloue donc un tableau de N octets pour y lire les lignes les unes après les autres, mais là, B envoye une ligne plus longue que N caractères, et A continue à l'écrire dans son tableau au-delà de son extrémité. B a donc pu écrire des choses dans la mémoire de A à un endroit où il n'était pas censé pouvoir écrire. Ça peut n'avoir aucun effet, conduire A à planter, ou carrément permettre à B de prendre le controle de A (typiquement, ce que B a écrit dans le tableau de A est un programme, puis ce qu'il a écrit au-delà du bout du tableau est venu écraser une adresse dans le code de A que A est censé exécuter plus tard, donc il suffit pour B d'y mettre l'adresse du début du tableau...).
Qu'est-ce que ça peut provoquer comme dégâts exactement?
Quelqu'un de mal intentionné peut prendre le controle d'un programme tournant sur ta machine.
G-raison :
Je viens de faire des mises à jours de certains programmes à cause de ce
genre de faiblesse : overflow vulnerability.
Il y a deux sortes de trous portant ce nom : les integer overflow et les
buffer overflow.
Un integer overflow, c'est quand le programmeur a oublié que les entiers
qu'il manipule ne sont pas de vrais entiers. Exemple (je crois qu'il y a eu
ça dans ssh à une époque) : tu as un programme A tournant au nom de root qui
doit allouer un port pour le compte d'un autre programme B, A doit vérifier
que le port que B lui demande d'allouer est supérieur à 1024 (seul root a le
droit d'allouer des ports < 1024), B demande à A
de lui allouer le port 2^16 + 1, A voit que 2^16+1 >= 1024 et alloue donc le
port 1, puisque les numéros de port sont codés sur 16 bits...
Un buffer overflow, c'est quand un programme écrit au-delà de la fin d'un
tableau. Typiquement, le programme A écoute ce que lui envoie un programme B
sur un pipe ou une connexion réseau, B étant censé envoyer à A une suite de
lignes de longueur inférieures à N, A alloue donc un tableau de N octets
pour y lire les lignes les unes après les autres, mais là, B envoye une
ligne plus longue que N caractères, et A continue à l'écrire dans son
tableau au-delà de son extrémité. B a donc pu écrire des choses dans la
mémoire de A à un endroit où il n'était pas censé pouvoir écrire. Ça peut
n'avoir aucun effet, conduire A à planter, ou carrément permettre à B de
prendre le controle de A (typiquement, ce que B a écrit dans le tableau de A
est un programme, puis ce qu'il a écrit au-delà du bout du tableau est venu
écraser une adresse dans le code de A que A est censé exécuter plus tard,
donc il suffit pour B d'y mettre l'adresse du début du tableau...).
Qu'est-ce que ça peut provoquer comme dégâts exactement?
Quelqu'un de mal intentionné peut prendre le controle d'un programme
tournant sur ta machine.
Je viens de faire des mises à jours de certains programmes à cause de ce genre de faiblesse : overflow vulnerability.
Il y a deux sortes de trous portant ce nom : les integer overflow et les buffer overflow.
Un integer overflow, c'est quand le programmeur a oublié que les entiers qu'il manipule ne sont pas de vrais entiers. Exemple (je crois qu'il y a eu ça dans ssh à une époque) : tu as un programme A tournant au nom de root qui doit allouer un port pour le compte d'un autre programme B, A doit vérifier que le port que B lui demande d'allouer est supérieur à 1024 (seul root a le droit d'allouer des ports < 1024), B demande à A de lui allouer le port 2^16 + 1, A voit que 2^16+1 >= 1024 et alloue donc le port 1, puisque les numéros de port sont codés sur 16 bits...
Un buffer overflow, c'est quand un programme écrit au-delà de la fin d'un tableau. Typiquement, le programme A écoute ce que lui envoie un programme B sur un pipe ou une connexion réseau, B étant censé envoyer à A une suite de lignes de longueur inférieures à N, A alloue donc un tableau de N octets pour y lire les lignes les unes après les autres, mais là, B envoye une ligne plus longue que N caractères, et A continue à l'écrire dans son tableau au-delà de son extrémité. B a donc pu écrire des choses dans la mémoire de A à un endroit où il n'était pas censé pouvoir écrire. Ça peut n'avoir aucun effet, conduire A à planter, ou carrément permettre à B de prendre le controle de A (typiquement, ce que B a écrit dans le tableau de A est un programme, puis ce qu'il a écrit au-delà du bout du tableau est venu écraser une adresse dans le code de A que A est censé exécuter plus tard, donc il suffit pour B d'y mettre l'adresse du début du tableau...).
Qu'est-ce que ça peut provoquer comme dégâts exactement?
Quelqu'un de mal intentionné peut prendre le controle d'un programme tournant sur ta machine.
noone
On Fri, 16 Nov 2007 18:33:10 +0100, Nicolas S. wrote:
G-raison a écrit:
Comment que ça se fait que l'on se retrouve avec ce genre de mises à jour à faire?
C'est une mise à jour de sécurité. Libre à toi de te mettre à jour.
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non exécutable ?
On Fri, 16 Nov 2007 18:33:10 +0100, Nicolas S. wrote:
G-raison <jairaison@wanadoo.fr> a écrit:
Comment que ça se fait que l'on se retrouve avec ce genre de mises à
jour à faire?
C'est une mise à jour de sécurité. Libre à toi de te mettre à jour.
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non
exécutable ?
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non exécutable ?
Un logiciel qui n'est pas censé être exécuté n'a tout simplement pas à être installé.
Si je ne réponds pas à ta question, c'est que je n'ai pas compris et qu'il faudrait que tu reformules.
-- Nicolas S.
Luc.Habert.00__arjf
:
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non exécutable ?
Tu veux dire ne mettre la permission d'exécution que sur les pages mmapées depuis l'exécutable et ses dlls? Il parait que ça ne suffit pas à se prémunir des buffer overflows, car l'attaquant peut encore faire en sorte de te faire appeler un appel système avec les arguments qu'il veut (en les envoyant sur la pile via le buffer et en mettant l'adresse de la fonction de la libc qui fait l'appel système en question).
noone@nowhere.invalid :
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non
exécutable ?
Tu veux dire ne mettre la permission d'exécution que sur les pages mmapées
depuis l'exécutable et ses dlls? Il parait que ça ne suffit pas à se
prémunir des buffer overflows, car l'attaquant peut encore faire en sorte de
te faire appeler un appel système avec les arguments qu'il veut (en les
envoyant sur la pile via le buffer et en mettant l'adresse de la fonction de
la libc qui fait l'appel système en question).
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non exécutable ?
Tu veux dire ne mettre la permission d'exécution que sur les pages mmapées depuis l'exécutable et ses dlls? Il parait que ça ne suffit pas à se prémunir des buffer overflows, car l'attaquant peut encore faire en sorte de te faire appeler un appel système avec les arguments qu'il veut (en les envoyant sur la pile via le buffer et en mettant l'adresse de la fonction de la libc qui fait l'appel système en question).
noone
On Sat, 17 Nov 2007 01:14:08 +0000, Luc Habert wrote:
:
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non exécutable ?
Tu veux dire ne mettre la permission d'exécution que sur les pages mmapées depuis l'exécutable et ses dlls? Il parait que ça ne suffit pas à se prémunir des buffer overflows, car l'attaquant peut encore faire en sorte de te faire appeler un appel système avec les arguments qu'il veut (en les envoyant sur la pile via le buffer et en mettant l'adresse de la fonction de la libc qui fait l'appel système en question).
non depuis le système meme : http://www.nsa.gov/selinux/info/faq.cfm#I2
On Sat, 17 Nov 2007 01:14:08 +0000, Luc Habert wrote:
noone@nowhere.invalid :
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non
exécutable ?
Tu veux dire ne mettre la permission d'exécution que sur les pages
mmapées depuis l'exécutable et ses dlls? Il parait que ça ne suffit pas
à se prémunir des buffer overflows, car l'attaquant peut encore faire en
sorte de te faire appeler un appel système avec les arguments qu'il veut
(en les envoyant sur la pile via le buffer et en mettant l'adresse de la
fonction de la libc qui fait l'appel système en question).
non depuis le système meme :
http://www.nsa.gov/selinux/info/faq.cfm#I2
On Sat, 17 Nov 2007 01:14:08 +0000, Luc Habert wrote:
:
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non exécutable ?
Tu veux dire ne mettre la permission d'exécution que sur les pages mmapées depuis l'exécutable et ses dlls? Il parait que ça ne suffit pas à se prémunir des buffer overflows, car l'attaquant peut encore faire en sorte de te faire appeler un appel système avec les arguments qu'il veut (en les envoyant sur la pile via le buffer et en mettant l'adresse de la fonction de la libc qui fait l'appel système en question).
non depuis le système meme : http://www.nsa.gov/selinux/info/faq.cfm#I2
noone
On Sat, 17 Nov 2007 01:44:51 +0100, Nicolas S. wrote:
a écrit:
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non exécutable ?
Un logiciel qui n'est pas censé être exécuté n'a tout simplement pas à être installé.
Si je ne réponds pas à ta question, c'est que je n'ai pas compris et qu'il faudrait que tu reformules.
pense avoir été clair mais pour plus de détail sur ce que je viens de dire lire http://people.redhat.com/drepper/nonselsec.pdf
en particulier chapitre 2, 3 et 4
On Sat, 17 Nov 2007 01:44:51 +0100, Nicolas S. wrote:
noone@nowhere.invalid a écrit:
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non
exécutable ?
Un logiciel qui n'est pas censé être exécuté n'a tout simplement pas à
être installé.
Si je ne réponds pas à ta question, c'est que je n'ai pas compris et
qu'il faudrait que tu reformules.
pense avoir été clair mais pour plus de détail sur ce que je viens de dire
lire
http://people.redhat.com/drepper/nonselsec.pdf
On Sat, 17 Nov 2007 01:44:51 +0100, Nicolas S. wrote:
a écrit:
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non exécutable ?
Un logiciel qui n'est pas censé être exécuté n'a tout simplement pas à être installé.
Si je ne réponds pas à ta question, c'est que je n'ai pas compris et qu'il faudrait que tu reformules.
pense avoir été clair mais pour plus de détail sur ce que je viens de dire lire http://people.redhat.com/drepper/nonselsec.pdf
en particulier chapitre 2, 3 et 4
Fabien LE LEZ
On 17 Nov 2007 00:37:26 GMT, :
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non exécutable ?
Sur une machine, j'ai un serveur mail, qui accepte automatiquement tout e-mail venant de 192.168.0.103. Imagine qu'un pirate remplace, en RAM, cette adresse par sa propre adresse -- mettons 82.227.159.62. Et boum, mon serveur mail est ouvert, le pirate peut s'en servir pour envoyer tout le spam qu'il veut.
On 17 Nov 2007 00:37:26 GMT, noone@nowhere.invalid:
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non
exécutable ?
Sur une machine, j'ai un serveur mail, qui accepte automatiquement
tout e-mail venant de 192.168.0.103.
Imagine qu'un pirate remplace, en RAM, cette adresse par sa propre
adresse -- mettons 82.227.159.62. Et boum, mon serveur mail est
ouvert, le pirate peut s'en servir pour envoyer tout le spam qu'il
veut.
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non exécutable ?
Sur une machine, j'ai un serveur mail, qui accepte automatiquement tout e-mail venant de 192.168.0.103. Imagine qu'un pirate remplace, en RAM, cette adresse par sa propre adresse -- mettons 82.227.159.62. Et boum, mon serveur mail est ouvert, le pirate peut s'en servir pour envoyer tout le spam qu'il veut.
noone
On Sat, 17 Nov 2007 13:41:01 +0100, Fabien LE LEZ wrote:
On 17 Nov 2007 00:37:26 GMT, :
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non exécutable ?
Sur une machine, j'ai un serveur mail, qui accepte automatiquement tout e-mail venant de 192.168.0.103. Imagine qu'un pirate remplace, en RAM, cette adresse par sa propre adresse -- mettons 82.227.159.62. Et boum, mon serveur mail est ouvert, le pirate peut s'en servir pour envoyer tout le spam qu'il veut.
Je veux bien imaginer maintenant comment est ce possible si il ne passe par le réseau il doit réussir à faire ça uniquement par un buffer overflow, non ?
On Sat, 17 Nov 2007 13:41:01 +0100, Fabien LE LEZ wrote:
On 17 Nov 2007 00:37:26 GMT, noone@nowhere.invalid:
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non
exécutable ?
Sur une machine, j'ai un serveur mail, qui accepte automatiquement tout
e-mail venant de 192.168.0.103.
Imagine qu'un pirate remplace, en RAM, cette adresse par sa propre
adresse -- mettons 82.227.159.62. Et boum, mon serveur mail est ouvert,
le pirate peut s'en servir pour envoyer tout le spam qu'il veut.
Je veux bien imaginer maintenant comment est ce possible si il ne passe
par le réseau il doit réussir à faire ça uniquement par un buffer
overflow, non ?
On Sat, 17 Nov 2007 13:41:01 +0100, Fabien LE LEZ wrote:
On 17 Nov 2007 00:37:26 GMT, :
pourquoi ne pas rendre ce qui n est pas adressé en mémoire non exécutable ?
Sur une machine, j'ai un serveur mail, qui accepte automatiquement tout e-mail venant de 192.168.0.103. Imagine qu'un pirate remplace, en RAM, cette adresse par sa propre adresse -- mettons 82.227.159.62. Et boum, mon serveur mail est ouvert, le pirate peut s'en servir pour envoyer tout le spam qu'il veut.
Je veux bien imaginer maintenant comment est ce possible si il ne passe par le réseau il doit réussir à faire ça uniquement par un buffer overflow, non ?
