[HS] faille de sécurité

Sylvain Sauvage

29/08/2006 à 23:20

Mardi 29 août 2006, 21:47:52 CEST, Gaëtan PERRIER a écrit :

Bonjour,

'soir,

Est-ce qu'une erreur de segmentation peut-être considérée comme faille
de sécurité?

Je dirais que si elle est causée par une utilisation particulière du
logiciel (p.ex. une entrée non prévue (genre 'abc' pour un nombre)) et si
le fait que le logiciel plante permette de faire de méchante choses
(p.ex. le prog plante et on se retrouve avec les droits root), alors oui.

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Jean-Michel OLTRA

30/08/2006 à 07:30

Bonjour,

Le mardi 29 août 2006, Sylvain Sauvage a écrit...

Je dirais que si elle est causée par une utilisation particulière du
logiciel (p.ex. une entrée non prévue (genre 'abc' pour un nombre)) et si
le fait que le logiciel plante permette de faire de méchante choses
(p.ex. le prog plante et on se retrouve avec les droits root), alors oui.

Même si on ne se retrouve pas avec les droits root, il peut y avoir un
risque si le logiciel tourne sous le compte root ou un autre compte.

Une erreur de segmentation peut-être due à une écriture dans une zone
mémoire non prévue. Dans ce cas il "suffirait" de trouver la bonne
valeur à écrire dedans pour obtenir un accès sous le compte de
l'utilisateur sous lequel tourne le programme.

--
jm

A.E.L. Sarl (R.C.S CASTRES 490843240)
http://www.affaires-en-ligne.com

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

rixed

30/08/2006 à 08:40

-[ Wed, Aug 30, 2006 at 07:23:38AM +0200, Jean-Michel OLTRA ]----

Une erreur de segmentation peut-être due à une écriture dans une zone
mémoire non prévue. Dans ce cas il "suffirait" de trouver la bonne
valeur à écrire dedans pour obtenir un accès sous le compte de
l'utilisateur sous lequel tourne le programme.

Il faudrait encore trouver une valeur à écrire qui ne soit pas décelée
par le mécanisme hardware de pagination, sans quoi on n'obtiendra rien
d'autre qu'un nouveau "segmentation fault".

Il est vrai que les états paranoiaques ne sont pas les plus propices à
la réfléxion.

J'aimerais toutefois répondre à l'OP.

Une erreur de protection cela peut traduire deux choses : que le programme
est tombé victime du kernel suite à une erreur dans le noyaux, ou bien plus
probablement qu'il y a une erreur dans le programme. Naturellement, toute
erreur de programmation est susceptible d'être exploitée pour "comprommettre"
une machine, surtout si l'on veut bien donner un sens assez large à ce terme
(simplement en considérant par exemple que faire planter un programme
constitue un déni de service caractérisé). Donc, oui, un segfault peut nuire à
la sécurité d'une machine ; surtout s'il dump son core (beuark), en laissant
un fichier code qui peut fournir des informations précieuses à défaut d'un
accès root.

Mais votre question initiale de gène un peut : un segfault, c'est avant tout
un gros bug lamentable qu'il faut corriger de fait. Pourquoi chercher une
raison de le faire dans la sphère sécuritaire ? Serait-ce que l'on cherche
à dissimuler l'incompétence des "petits génies de l'informatique" d'hier derrière
le rideau de fumée des "experts de la sécurité" d'aujourd'hui ?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

-[ Wed, Aug 30, 2006 at 07:23:38AM +0200, Jean-Michel OLTRA ]----

Une erreur de segmentation peut-être due à une écriture dans une zone
mémoire non prévue. Dans ce cas il "suffirait" de trouver la bonne
valeur à écrire dedans pour obtenir un accès sous le compte de
l'utilisateur sous lequel tourne le programme.

Il faudrait encore trouver une valeur à écrire qui ne soit pas décelée
par le mécanisme hardware de pagination, sans quoi on n'obtiendra rien
d'autre qu'un nouveau "segmentation fault".

Il est vrai que les états paranoiaques ne sont pas les plus propices à
la réfléxion.

J'aimerais toutefois répondre à l'OP.

Une erreur de protection cela peut traduire deux choses : que le programme
est tombé victime du kernel suite à une erreur dans le noyaux, ou bien plus
probablement qu'il y a une erreur dans le programme. Naturellement, toute
erreur de programmation est susceptible d'être exploitée pour "comprommettre"
une machine, surtout si l'on veut bien donner un sens assez large à ce terme
(simplement en considérant par exemple que faire planter un programme
constitue un déni de service caractérisé). Donc, oui, un segfault peut nuire à
la sécurité d'une machine ; surtout s'il dump son core (beuark), en laissant
un fichier code qui peut fournir des informations précieuses à défaut d'un
accès root.

Mais votre question initiale de gène un peut : un segfault, c'est avant tout
un gros bug lamentable qu'il faut corriger de fait. Pourquoi chercher une
raison de le faire dans la sphère sécuritaire ? Serait-ce que l'on cherche
à dissimuler l'incompétence des "petits génies de l'informatique" d'hier derrière
le rideau de fumée des "experts de la sécurité" d'aujourd'hui ?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Vous avez filtré cet utilisateur ! Consultez son message

Gaëtan PERRIER

30/08/2006 à 20:30

Le Wed, 30 Aug 2006 08:31:06 +0200
rixed a écrit:

Mais votre question initiale de gène un peut : un segfault, c'est
avant tout un gros bug lamentable qu'il faut corriger de fait.
Pourquoi chercher une raison de le faire dans la sphère
sécuritaire ? Serait-ce que l'on cherche à dissimuler
l'incompétence des "petits génies de l'informatique" d'hier
derrière le rideau de fumée des "experts de la sécurité"
d'aujourd'hui ?

Tout simplement parce que c'est dans un logiciel propriétaire, que je n'ai pas de manip facile pour reproduire le bug et que donc l'éditeur préfère se concentrait sur autre chose. J'ai tenté l'argument de la faille de sécurité mais on me répond qu'on ne voit pas en quoi un segfault sous un compte utilisateur pouvait-être un trou de sécurité.

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

rixed

30/08/2006 à 22:10

-[ Wed, Aug 30, 2006 at 08:22:12PM +0200, Gaëtan PERRIER ]----

> Mais votre question initiale de gène un peut : un segfault, c'est
> avant tout un gros bug lamentable qu'il faut corriger de fait.

Tout simplement parce que c'est dans un logiciel propriétaire, que je n'ai pas de manip facile pour reproduire le bug et que donc l'éditeur préfère se concentrait sur autre chose. J'ai tenté l'argument de la faille de sécurité mais on me répond qu'on ne voit pas en quoi un segfault sous un compte utilisateur pouvait-être un trou de sécurité.

Ok je vois.

Que le programme se plante, perde éventuellement des données, fasse n'importe
quoi, ça ne préoccupe évidement personne ? Rassurez moi, ce n'est ni une
application militaire ni une application médicale, ni du transport
ferroviaire... ? :-)

Voyons donc ce que vous pourriez leur raconter...
Mais sans en savoir plus sur ce segfault, ça va rester au niveau des
généralités.

Imaginons que le segfault soit produit à cause d'une écriture invalide. Cela
signifie que le programme, dans certaines conditions, va écrire des données
n'importe où. Si ces données proviennent d'input, et si on arrive, avec
d'autres inputs, à 'choisir' où ce programme va écrire, on pourrait lui faire
patcher, par exemple, une chaîne de caractères qui serait une commande
exécutée plus tard par le programme (à condition que cette commande ne soit
pas en lecture seule). On pourrait donc exécuter faire exécuter une autre
commande au programme. Si ce n'est pas possible, on pourrait aussi tenter
d'écrire une adresse d'exécution valide dans la pile ou dans tout autre
endroit contenant une adresse (par exemple les morceaux de codes contenant
les adresses pour sauter dans des librairies linkées dynamiquement, et
envoyer le pointeur d'instruction où l'on veut, de préférence dans un buffer
contenant des données provenant elles aussi d'un input (sous réserve que ce
buffer se situe dans une zone exécutable). Un buffer overflow n'est qu'une
variante de ce principe général.

Si au contraire le segfault provient d'une lecture invalide, on peut
peut-être s'arranger pour influencer avec des inputs l'adresse en question,
et alors envoyer le programme lire tout ce qui est accessible au programme.
Si par le plus grand des hasards ces valeurs sont ensuite retournées d'une
manière où d'une autre à l'utilisateur malicieux, il pourra ainsi peut être
lire des mots de passe stockés en clair dans les données du programme.

Si le segfault provient d'une adresse d'exécution invalide, alors, toujours
en t'influençant cette adresse avec des inputs bien choisis, on est ramené au
premier cas ci-dessus : amener le programme a éxécuter des données que
l'utilisateur a lui même au préalable introduites (avec les mêmes réserves).

Dans tous les cas, cela suppose que l'utilise connaît bien le programme (il a
une version binaire au moins), ou bien qu'il a droit à de nombreux essais (ce
qui est probablement le cas : je suppose que lorsque le programme plante, il
est relancé aussi sec).

Voilà tout ce que l'on peut dire, je pense, sans faire preuve de trop de
mauvaise fois.

Mais faire remonter le bug au propriétaire du soft serait bien aussi.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

-[ Wed, Aug 30, 2006 at 08:22:12PM +0200, Gaëtan PERRIER ]----

> Mais votre question initiale de gène un peut : un segfault, c'est
> avant tout un gros bug lamentable qu'il faut corriger de fait.

Tout simplement parce que c'est dans un logiciel propriétaire, que je n'ai pas de manip facile pour reproduire le bug et que donc l'éditeur préfère se concentrait sur autre chose. J'ai tenté l'argument de la faille de sécurité mais on me répond qu'on ne voit pas en quoi un segfault sous un compte utilisateur pouvait-être un trou de sécurité.

Ok je vois.

Que le programme se plante, perde éventuellement des données, fasse n'importe
quoi, ça ne préoccupe évidement personne ? Rassurez moi, ce n'est ni une
application militaire ni une application médicale, ni du transport
ferroviaire... ? :-)

Voyons donc ce que vous pourriez leur raconter...
Mais sans en savoir plus sur ce segfault, ça va rester au niveau des
généralités.

Imaginons que le segfault soit produit à cause d'une écriture invalide. Cela
signifie que le programme, dans certaines conditions, va écrire des données
n'importe où. Si ces données proviennent d'input, et si on arrive, avec
d'autres inputs, à 'choisir' où ce programme va écrire, on pourrait lui faire
patcher, par exemple, une chaîne de caractères qui serait une commande
exécutée plus tard par le programme (à condition que cette commande ne soit
pas en lecture seule). On pourrait donc exécuter faire exécuter une autre
commande au programme. Si ce n'est pas possible, on pourrait aussi tenter
d'écrire une adresse d'exécution valide dans la pile ou dans tout autre
endroit contenant une adresse (par exemple les morceaux de codes contenant
les adresses pour sauter dans des librairies linkées dynamiquement, et
envoyer le pointeur d'instruction où l'on veut, de préférence dans un buffer
contenant des données provenant elles aussi d'un input (sous réserve que ce
buffer se situe dans une zone exécutable). Un buffer overflow n'est qu'une
variante de ce principe général.

Si au contraire le segfault provient d'une lecture invalide, on peut
peut-être s'arranger pour influencer avec des inputs l'adresse en question,
et alors envoyer le programme lire tout ce qui est accessible au programme.
Si par le plus grand des hasards ces valeurs sont ensuite retournées d'une
manière où d'une autre à l'utilisateur malicieux, il pourra ainsi peut être
lire des mots de passe stockés en clair dans les données du programme.

Si le segfault provient d'une adresse d'exécution invalide, alors, toujours
en t'influençant cette adresse avec des inputs bien choisis, on est ramené au
premier cas ci-dessus : amener le programme a éxécuter des données que
l'utilisateur a lui même au préalable introduites (avec les mêmes réserves).

Dans tous les cas, cela suppose que l'utilise connaît bien le programme (il a
une version binaire au moins), ou bien qu'il a droit à de nombreux essais (ce
qui est probablement le cas : je suppose que lorsque le programme plante, il
est relancé aussi sec).

Voilà tout ce que l'on peut dire, je pense, sans faire preuve de trop de
mauvaise fois.

Mais faire remonter le bug au propriétaire du soft serait bien aussi.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Vous avez filtré cet utilisateur ! Consultez son message

-[ Wed, Aug 30, 2006 at 08:22:12PM +0200, Gaëtan PERRIER ]----

> Mais votre question initiale de gène un peut : un segfault, c'est
> avant tout un gros bug lamentable qu'il faut corriger de fait.

Tout simplement parce que c'est dans un logiciel propriétaire, que je n'ai pas de manip facile pour reproduire le bug et que donc l'éditeur préfère se concentrait sur autre chose. J'ai tenté l'argument de la faille de sécurité mais on me répond qu'on ne voit pas en quoi un segfault sous un compte utilisateur pouvait-être un trou de sécurité.

Ok je vois.

Que le programme se plante, perde éventuellement des données, fasse n'importe
quoi, ça ne préoccupe évidement personne ? Rassurez moi, ce n'est ni une
application militaire ni une application médicale, ni du transport
ferroviaire... ? :-)

Voyons donc ce que vous pourriez leur raconter...
Mais sans en savoir plus sur ce segfault, ça va rester au niveau des
généralités.

Imaginons que le segfault soit produit à cause d'une écriture invalide. Cela
signifie que le programme, dans certaines conditions, va écrire des données
n'importe où. Si ces données proviennent d'input, et si on arrive, avec
d'autres inputs, à 'choisir' où ce programme va écrire, on pourrait lui faire
patcher, par exemple, une chaîne de caractères qui serait une commande
exécutée plus tard par le programme (à condition que cette commande ne soit
pas en lecture seule). On pourrait donc exécuter faire exécuter une autre
commande au programme. Si ce n'est pas possible, on pourrait aussi tenter
d'écrire une adresse d'exécution valide dans la pile ou dans tout autre
endroit contenant une adresse (par exemple les morceaux de codes contenant
les adresses pour sauter dans des librairies linkées dynamiquement, et
envoyer le pointeur d'instruction où l'on veut, de préférence dans un buffer
contenant des données provenant elles aussi d'un input (sous réserve que ce
buffer se situe dans une zone exécutable). Un buffer overflow n'est qu'une
variante de ce principe général.

Si au contraire le segfault provient d'une lecture invalide, on peut
peut-être s'arranger pour influencer avec des inputs l'adresse en question,
et alors envoyer le programme lire tout ce qui est accessible au programme.
Si par le plus grand des hasards ces valeurs sont ensuite retournées d'une
manière où d'une autre à l'utilisateur malicieux, il pourra ainsi peut être
lire des mots de passe stockés en clair dans les données du programme.

Si le segfault provient d'une adresse d'exécution invalide, alors, toujours
en t'influençant cette adresse avec des inputs bien choisis, on est ramené au
premier cas ci-dessus : amener le programme a éxécuter des données que
l'utilisateur a lui même au préalable introduites (avec les mêmes réserves).

Dans tous les cas, cela suppose que l'utilise connaît bien le programme (il a
une version binaire au moins), ou bien qu'il a droit à de nombreux essais (ce
qui est probablement le cas : je suppose que lorsque le programme plante, il
est relancé aussi sec).

Voilà tout ce que l'on peut dire, je pense, sans faire preuve de trop de
mauvaise fois.

Mais faire remonter le bug au propriétaire du soft serait bien aussi.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Gaëtan PERRIER

30/08/2006 à 23:50

Le Wed, 30 Aug 2006 22:07:57 +0200
rixed a écrit:

-[ Wed, Aug 30, 2006 at 08:22:12PM +0200, Gaëtan PERRIER ]----
> > Mais votre question initiale de gène un peut : un segfault,
> > c'est avant tout un gros bug lamentable qu'il faut corriger de
> > fait.
>
> Tout simplement parce que c'est dans un logiciel propriétaire,
> que je n'ai pas de manip facile pour reproduire le bug et que
> donc l'éditeur préfère se concentrait sur autre chose. J'ai tenté
> l'argument de la faille de sécurité mais on me répond qu'on ne
> voit pas en quoi un segfault sous un compte utilisateur
> pouvait-être un trou de sécurité.

Ok je vois.

Que le programme se plante, perde éventuellement des données, fasse
n'importe quoi, ça ne préoccupe évidement personne ? Rassurez moi,
ce n'est ni une application militaire ni une application médicale,
ni du transport ferroviaire... ? :-)

Non, c'est un système de contrôle de trajectoire pour les voitures... mais non je déconne. C'est juste un logiciel de traitement des fichiers photo RAW. BibblePro pour ne pas le nommer.

Mais faire remonter le bug au propriétaire du soft serait bien
aussi.

Le problème c'est que le logiciel plante des fois tout seul sans rien faire. Par exemple, je pars ouvrir la porte, je reviens et pouf le logiciel a planté alors qu'il n'avait pas d'action en cours... D'autre fois tu crois que c'est lié à ce que tu fais mais si tu refais la même manip ensuite et bien il ne plante pas...
Le seul truc que je vois c'est que souvent il y a un segfault. Je serais assez tenté de dire qu'ils ont des soucis de gestion mémoire vu les quantités assez importantes qu'un logiciel de ce genre peut consommer. Bref faire un rapport de bug dans ces conditions c'est mission impossible.

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Le Wed, 30 Aug 2006 22:07:57 +0200
rixed <rixed@happyleptic.org> a écrit:

-[ Wed, Aug 30, 2006 at 08:22:12PM +0200, Gaëtan PERRIER ]----
> > Mais votre question initiale de gène un peut : un segfault,
> > c'est avant tout un gros bug lamentable qu'il faut corriger de
> > fait.
>
> Tout simplement parce que c'est dans un logiciel propriétaire,
> que je n'ai pas de manip facile pour reproduire le bug et que
> donc l'éditeur préfère se concentrait sur autre chose. J'ai tenté
> l'argument de la faille de sécurité mais on me répond qu'on ne
> voit pas en quoi un segfault sous un compte utilisateur
> pouvait-être un trou de sécurité.

Ok je vois.

Que le programme se plante, perde éventuellement des données, fasse
n'importe quoi, ça ne préoccupe évidement personne ? Rassurez moi,
ce n'est ni une application militaire ni une application médicale,
ni du transport ferroviaire... ? :-)

Non, c'est un système de contrôle de trajectoire pour les voitures... mais non je déconne. C'est juste un logiciel de traitement des fichiers photo RAW. BibblePro pour ne pas le nommer.

Mais faire remonter le bug au propriétaire du soft serait bien
aussi.

Le problème c'est que le logiciel plante des fois tout seul sans rien faire. Par exemple, je pars ouvrir la porte, je reviens et pouf le logiciel a planté alors qu'il n'avait pas d'action en cours... D'autre fois tu crois que c'est lié à ce que tu fais mais si tu refais la même manip ensuite et bien il ne plante pas...
Le seul truc que je vois c'est que souvent il y a un segfault. Je serais assez tenté de dire qu'ils ont des soucis de gestion mémoire vu les quantités assez importantes qu'un logiciel de ce genre peut consommer. Bref faire un rapport de bug dans ces conditions c'est mission impossible.

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Vous avez filtré cet utilisateur ! Consultez son message

[HS] faille de sécurité

6 réponses

Veuillez sélectionner un problème