Re: [HS] faille de sécurité
-[ 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.
Reply to: