Le samedi 22 janvier 2011 à 08:41 +0100, Nicolas Morey-Chaisemartin a
écrit :
> On 21/01/2011 19:50, Xavier Bestel wrote:
> >>
> >> Et dans ce cas, je ne vois pas du tout en quoi c'est un problème de sécurité....
> >
> > Ben tu manques d'imagination.
> > Imagine que tu puisses récupérer la mémoire du navigateur web de
> > l'utilisateur précédent, avec ses mots de passes. Ou une session ssh. Il
> > y a probablement des tonnes d'autres exemples.
> >
> > Xav
> >
> >
> >
>
> En pratique ce genre de truc n'est pas exploitable. Étant donné que
> mmap ne donne aucune garantie sur l'ordre d'allocation des pages sur
> le hardware (ni la première, ni la dernière fois), il n'y a en
> pratique aucune chance pour que tu tombe sur une grosse zone
> sequentielle qui était utilisée avant.
Et alors ? Une page fait 4k, c'est largement suffisant pour y retrouver
un mot de passe ou quelque-chose d'intéressant.
> Et surtout, comment est-tu censé savoir ce que la mémoire contient? Si
> tu as pu alloué la page, c'est que firefox a quitté ! Et le mode user
> n'a de toute façon pas les infos sur les pages hardwares donc ne peut
> pas checker.
?!? Si tu retrouves de la mémoire non-initialisée, il y a des choses
exploitables dedans. Pour te convaincre que c'est un problème sérieux,
fait une recherche sur les CVE correspondantes, il y en a des tonnes. Un
petit exemple:
"Dan Rosenberg discovered that several network ioctls did not clear kernel
memory correctly. A local user could exploit this to read kernel stack
memory, leading to a loss of privacy. (CVE-2010-3296, CVE-2010-3297,
CVE-2010-3298)"
> Tu n'as jamais remarqué que quand tu fais un malloc (pas sur pour le
> malloc, mais sur pour le mmap), tes datas ne sont jamais à 0 mais a
> des valeurs à la con? Ce à la con que l'on ne comprend pas de son
> programme, c'est le reste des datas d'un programme précédent (ou du
> cache disque pourquoi pas).
Non, je n'ai jamais remarqué pour la simple raison que c'est faux.
L'allocation mémoire, que ce soit par sbrk() ou mmap(MAP_ANONYMOUS)
retournent de la mémoire qui vient du kernel, et qui est effacée avant
usage. Ce que tu as du voir est de la mémoire allouée par malloc(), qui
provient de ton propre process et qui peut avoir été utilisée par
lui-même avant. Aucun problème de sécurité donc.
> Il y a eu dans des temps reculé des discussions pour avoir des options
> qui forcaient toutes les data à 0 lors de la première alloc dans le
> process (Chercher sanitize_meme sur la mailing list kernel) mais ca
> n'a pas l'aitr d'avoir marché. Le problème de tout mettre à 0 c'est
> que l'impact en perf est quand même assez monstrueux. Et ca ne résoud
> pas le problème des applis swappées....
Non. La discussion sur sanitize_mem est à propos de changer le moment où
on efface la mémoire utilisateur: au lieu de l'effacer à l'allocation,
on l'efface à la libération, pour que les données utilisateurs restent
en mémoire le moins longtemps possible.
Effectivement le procédé actuel (effacement à l'allocation) pose
problème, car si tu fais un reset de la machine toutes les données sont
en mémoire, et tu pourrais les récupérer avec un kernel spécialisé.
> En gros oui il y a moyen d'avoir un accès à la mémoire. NVidia ne l'a
> pas mis là et vu qu'on ne trouve rien sur le net à part quelques posts
> du gars qui "a trouvé le bug", je ne pense pas qu'il y ai plus de
> soucis que ca à se faire !
En gros pas du tout, l'accès à la mémoire est pris très au sérieux par
les développeurs du kernel, et NVIDIA a vraiment fait une boulette.
Heureusement, elle est limitée au GPU (mais le GPU est de plus en plus
utilisé), et heureusement pour eux personne ne peut aller lire leur
code, mais la faille est bien réelle.
Xav
