Streaming : faille critique pour Quicktime

Franck hardfflas> parceque mac os x est un système d'exploitation UNIX, et que a moins d'être root, tu ne prends le controle de rien :)
Hardfflas> cest ptéte ta m*** madame Irma... (NB:J'ai pas été vulgaire le premier, vous noterez la similitude dans les *** ^^)
Edité le 27/11/2007 à 19:23

Pour info elle concerne aussi bien les versions Windows que les version Mac cette faille :
www.certa.ssi.gouv.fr...

Et les mec comme toi ca me saoule aussi t'inquiètes. Et si tu relis bien ce que je dis "On ignore actuellement si la faille touche mac os x... Perso ca m'étonnerai". Je ne faisais que reprendre celui qui disait que la faille était sous win et mac os :) merci d'avoir jouer.

---

kpouer, je viens de lire ta page, c'est écrit nulle part que ca concerne mac os x.. ils disent qu'il est "préférable" de désactiver la prise en charge des liens :)

Tu notes qu'ils disent pas non plus que ca concerne Windows :neutre: Seulement le CERTA est une organisation sérieuse qui ne publie pas n'importe quoi, s'ils donnent un contournement sous Mac OS X c'est qu'il y a des raisons de se faire du soucis aussi sur cet OS aussi.

Je n'ai pas dit qu'il n'y avait pas ce problème sous mac os x, je parlais de la prise de contrôle a distance.

Comme promis, j'ai testé le petit script python. Je confirme donc que Quicktime 7.3 sous Leopard et Tiger plante lamentablement comme sous XP et Vista...

---

kpouer a écrit:
Pour info elle concerne aussi bien les versions Windows que les version Mac cette faille :
www.certa.ssi.gouv.fr...

:non: Ce n'est pas encore une faille, c'est un buffer overrun qui fait planter Quicktime... le vrai boulot commence seulement maintenant et je doute qu'il soit aisé de faire en sorte qu'au lieu de planter, Quicktime (ou n'importe quel autre programme) execute un code spécifique :neutre:

Faire planter une application avec des données corrompu est très très facile et se fait en quelque minutes (merci rand). Exploiter le plantage est une tout autre affaire. Sans exploitation, il s'agit d'un bug (ou disons une faille potentielle) et non d'une faille avéré (edit : je précise que cela vaut quel que soit l'OS avant qu'on me traite de fanboy :pfff:).

Edit 2 : il faut savoir qu'un buffer overrun n'implique pas forcement qu'on puisse utiliser le plantage pour exécuter un code contenu dans "l'overrun". La plupart du temps, le buffer overrun écrase des datas et non du code (les deux étant séparé sauf s'il s'agit d'espace sur la pile par exemple).
Edité le 28/11/2007 à 00:21

Desactive le DEP et recommence s'il te plait ..
Le DEP fait systematiquement planter n'importe quelle appli en buffer overrun ... c'est sa fonction justement...

Merci pour votre motivations en tout cas! même si je ne comprend pas trop tes explications PColis, je vois l'idée :)

catseye a écrit:
Desactive le DEP et recommence s'il te plait ..
Le DEP fait systematiquement planter n'importe quelle appli en buffer overrun ... c'est sa fonction justement...

DEP ou pas DEP, ca ne change strictement rien...

J'ai attaché le debugger (Visual Studio) au processus QuicktimePlayer pour voir ce qui se passait. L'overrun écrase la pile et après la first chance exception dans le thread principal du module QuickTimeStreaming.qtx, l'instruction pointer saute en 0x42424242 (qui se trouve être la chaine de 4096 'B' du script python).

On se trouve donc typiquement dans le cas ou le buffer utilisé pour l'entête RTSP se trouvait sur la pile sans test de dépassement. La pile est donc corrompu est l'execution se fait dans le décors. Donc oui, il est dans ce cas eventuellement possible de sauter sur une adresse autre que 0x42424242, disons par exemple l'adresse du début d'un code contenu dans l'overrrun.
Un saut relatif est ici impossible car il s'agit d'une adresse de retour sur la pile. Il faut donc que le mappage mémoire des modules soit identique d'une execution à l'autre afin de trouver la "bonne" adresse. Après plusieurs tests, ceci est bien le cas sous Windows (aucune idée pour OSX n'ayant pas de debuggeur sous la main).

Donc, en résumé, il s'agit bien d'une faille potentiellement exploitable si les adresses des modules restent identique. Mais ce n'est pas encore un exploit car le code executé n'est pas encore celui de l'overrun.
Edité le 28/11/2007 à 10:31

PColis > le mappage mémoire des modules, ça ne correspond pas justement à une des nouveautés de Leopard ?

Affectation aléatoire des adresses
Défendez-vous sans aucun effort contre les attaques. L'une des failles de sécurité les plus courantes intervient lorsque le code d'un pirate appelle une adresse mémoire connue pour faire exécuter du code malveillant par une fonction du système. Leopard déjoue ce plan en replaçant les bibliothèques système à l'une des adresses allouées de façon aléatoire, qui se comptent par milliers.

d9pouces a écrit:
PColis > le mappage mémoire des modules, ça ne correspond pas justement à une des nouveautés de Leopard ?

Si, mais je n'osais pas le dire ; on aurait pu croire que je fesais preuve de fanboyisme aigue :peur:

Edit : pour info, VLC plante également avec ce même script python mais le plantage n'intervient seulement qu'après plusieurs minutes :etonne2:
Edité le 28/11/2007 à 10:58

PColis a écrit:

catseye a écrit:
Desactive le DEP et recommence s'il te plait ..
Le DEP fait systematiquement planter n'importe quelle appli en buffer overrun ... c'est sa fonction justement...

DEP ou pas DEP, ca ne change strictement rien...

J'ai attaché le debugger (Visual Studio) au processus QuicktimePlayer pour voir ce qui se passait. L'overrun écrase la pile et après la first chance exception dans le thread principal du module QuickTimeStreaming.qtx, l'instruction pointer saute en 0x42424242 (qui se trouve être la chaine de 4096 'B' du script python).

On se trouve donc typiquement dans le cas ou le buffer utilisé pour l'entête RTSP se trouvait sur la pile sans test de dépassement. La pile est donc corrompu est l'execution se fait dans le décors. Donc oui, il est dans ce cas eventuellement possible de sauter sur une adresse autre que 0x42424242, disons par exemple l'adresse du début d'un code contenu dans l'overrrun.
Un saut relatif est ici impossible car il s'agit d'une adresse de retour sur la pile. Il faut donc que le mappage mémoire des modules soit identique d'une execution à l'autre afin de trouver la "bonne" adresse. Après plusieurs tests, ceci est bien le cas sous Windows (aucune idée pour OSX n'ayant pas de debuggeur sous la main).

Donc, en résumé, il s'agit bien d'une faille potentiellement exploitable si les adresses des modules restent identique. Mais ce n'est pas encore un exploit car le code executé n'est pas encore celui de l'overrun.

On sent bien les réminiscences de l'ancien hacker Amiga qui remontent à la surface :lol:

C'est vrai, je pense que je ne me serais peut-être pas donné la peine de regarder s'il n'y avait pas eu la news sur l'AmigaOS4 :ane: :paf: