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 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.
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).
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....
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 !
Nicolas
