La faille WMF etait-elle une vrai backdoo r ?

Le
Xavier Roche
Steve Gibson a posté une nouvelle fort intéressante à propos de la
dernière "faille" de sécurité des fichiers WMF. Je place faille entre
guillemets, car beaucoup de questions se posent aujourd'hui sur la
présence de cette dernière.

Pour résumer, le format WMF est un format metafile (càd une liste de
commandes graphiques GDI appliquées à un contexte, qui sont sérialisées
dans un fichier pour être "rejouées" ; càd sur l'écran, l'imprimante, un
buffer graphique, etc.)

En gros, le fichier comportera une liste de commandes telles que "change
la couleur du pinceau en rouge", "trace un trait", "trace un carré ici",
etc. Lors qu'il sera rejouté sur un device, comme un écran, il permettra
de recomposer l'image ou de l'imprimer.

Lors d'une impression [sur un context, qui peut être un écran, encore
une fois], un contexte graphique peut contenir un callback en cas
d'erreur de traitement. Pour une imprimante, cela peut être un problème
de papier, d'encre, ou une simple annulation de la part de l'utilisateur.

Cela permet alors d'interrompre une impression, proposer à l'utilisateur
de reprendre, etc.

Ce callback est interne au programme, comme le sont tous les callbacks.
La procédure d'interruption de MsPaint ne sera pas la même que celle de
Photoshop, etc. Si vous utilisez une fonction système acceptant un
callback, vous placez VOTRE callback, pas celui d'un voisin.

Ainsi un tel callback n'a virtuellement aucun interêt DANS un fichier
meta (2). A l'exterieur, oui, dans le programme réalisant l'impression.
Mais quel interêt a l'intérieur du fichier meta lui même ? De plus, pour
qu'il puisse fonctionner, il faut prévoir la sérialisation de ce code ;
ce qui demande quelques adaptations [code ne nécessitant pas de
rellocation, càd du code relatif]

Il y a encore pire (3): le callback serait executé directement
uniquement si la taille du record est déclarée avec une taille invalide
de .. 1 octet. Troublant ? Un bug assez étonnant, et qui pose de
sérieuses questions sur le but recherché lors de l'ajout de cette
fonctionnalité.

La faille WMF, une fausse vrai faille cachant une vrai fausse backdoor ?


(1)
<http://www.grc.com/x/news.exe?cmd=article&group=grc.news.feedback&item`006>
<http://it.slashdot.org/it/06/01/13/1519204.shtml>

(2)
Windows MetaFiles are a completely different sort of animal.
When you create a MetaFile you are actually creating a MetaFile
Device Context that starts out blank. Then, as the GDI
functions in the MetaFile are executed, those GDI drawing
functions are "drawn" or applied onto the Metafile's Device
Context.

But MetaFiles are not "printed", to do that you need a "printer
Device Context", which is different from screen contexts and
metafile contexts. So it makes no sense to set an abort proc in
a metafile. But even so, there would presumably be no reason
for not allowing an abort proc to be set."

(3)
And, what's more remember my posting yesterday where I said
that I had some initial trouble getting my own tester to trigger
the exploit? The reason for that was the clincher for me, up to
this point: The only way to get this special behavior is to
deliberately mis-set the LENGTH of that ESCAPE/SetAbortProc
metafile record to ONE.

But since EVERY METAFILE RECORD starts out with a mandatory
four-byte record length, followed by a two-byte function code,
the smallest possible record is six-bytes, or a size of THREE
words. Therefore the use of a word-length of ONE is impossible.

It was put in there as a safety interlock to prevent the mis-
firing of this backdoor in the event that some whacky metafile
would actually HAVE a needless (because it's not a printer
device context) Escape/SetAbortProc metafile record.
  • Partager ce contenu :
Vos réponses Page 1 / 2
Trier par : date / pertinence
Xavier Roche
Le #829943
Xavier Roche wrote:

Une première réponse a été postée par Stephen Toulouse à ce sujet (1).
La réponse laisse néanmoins en suspend la question principale: pourquoi
SetAbortProc() a-t-elle été sérialisée avec son code dans le fichier
WMF, et pas uniquement sous forme d'un pointeur userland, comme cela
aurait été possible à l'époque ?

Ainsi un tel callback n'a virtuellement aucun interêt DANS un fichier
meta (2). A l'exterieur, oui, dans le programme réalisant l'impression.


Et d'ailleurs c'est ce que dit en gros (2) Steve Gibson dans sa réponse
(3) ; très dubitatif sur les raisons d'intérgrer du code dans le format
lui même.

uniquement si la taille du record est déclarée avec une taille invalide
de .. 1 octet.


Selon Stephen Toulouse touours, ce point est incorrect ; le callback
pouvant fonctionner dans tous les cas, quelque soit la taille déclarée (4)

Une affaire à suivre en tout cas..


(1)

(2)

(3)
Also, as I said on the podcast, we are are not being asked for
a POINTER to the SetAbortProc code -- which is what the REAL
SetAbortProc function is provided for. Rather, the metafile
ITSELF is executed immediately and without warning. And,
speaking of "without warning" ... if what Stephen says is
correct, shouldn't the code wait to be executed until the user
actually aborts some printing or something? But that's not what
happens.

(4)
Now, there's been some speculation that you can only trigger this by
using an incorrect size in your metafile record and that this trigger
was somehow intentional. That speculation is wrong on both counts. The
vulnerability can be triggered with correct or incorrect size values.
If you are seeing that you can only trigger it with an incorrect value,
it's probably because your SetAbortProc record is the last record in the
metafile. The way this functionality works is by registering the
callback to be called after the next metafile record is played. If the
SetAbortProc record is the last record in the metafile, it will be more
difficult to trigger the vulnerability.

Emmanuel Florac
Le #829727
Le Sun, 15 Jan 2006 08:08:04 +0000, Xavier Roche a écrit :


Ainsi un tel callback n'a virtuellement aucun interêt DANS un fichier
meta (2). A l'exterieur, oui, dans le programme réalisant l'impression.
Mais quel interêt a l'intérieur du fichier meta lui même ? De plus,
pour qu'il puisse fonctionner, il faut prévoir la sérialisation de ce
code ; ce qui demande quelques adaptations [code ne nécessitant pas de
rellocation, càd du code relatif]


Ce ne serait tout de même pas la preomière fois qu'un truc idiot ou
inutile se trouverait dans un format de fichier ou une application
(surtout venant de chez microsoft...). Rappelez vous : Internet Explorer
traitait (toujours?) les fichiers images en fonction de leur extension et
pas du HTTP Header, c'est lamentable, c'est stupide, c'est dangereux mais
pourtant personne n'a accusé Microsoft de l'avoir fait exprès pour
permettre à la NSA de pirater vos PC.

--
Il y a toujours un bug de plus.
Loi de Lubarsky.

Xavier Roche
Le #829492
Emmanuel Florac wrote:
Ce ne serait tout de même pas la preomière fois qu'un truc idiot ou
inutile se trouverait dans un format de fichier ou une application
(surtout venant de chez microsoft...).


Oui mais là justement le "truc" en question n'était pas totalement
évident à implémenter ; ce n'est pas juste une commande qui traine et
qu'on a laissé, c'est un machin qui execute du code exterieur sans
demander son reste..

Rappelez vous : Internet Explorer
traitait (toujours?) les fichiers images en fonction de leur extension et
pas du HTTP Header


C'est inexact. Il y a aussi et surtout une détection du type selon le
contenu lui même ; càd que si vous envoyez un text/html avec des données
GIF, IE va "reconnaitre" que c'est au final une image et l'afficher.
Plus, évidemment, des wrappers selon l'extension. Mais le MIME est
parfois pris en compte. Enfin parfois.

Le résultat est une joyeuse soupe, en effet. Tiens, un bug toujours
aussi marrant: demandez a IE d'afficher un txt.gz. La première fois il
l'affichera tel quel. La seconde, il proposera de le télécharger.
Ensuite, selon le modulo du nombre d'essais à 2, l'une ou l'autre de ces
solutions.

Je pense qu'on doit pouvoir trouver d'autres exemples aussi poilant :p

Fabien LE LEZ
Le #829493
On 15 Jan 2006 21:34:53 GMT, Emmanuel Florac
Rappelez vous : Internet Explorer
traitait (toujours?) les fichiers images en fonction de leur extension et
pas du HTTP Header, c'est lamentable, c'est stupide, c'est dangereux mais
pourtant personne n'a accusé Microsoft de l'avoir fait exprès pour
permettre à la NSA de pirater vos PC.


Le truc, c'est que pour faire autant de conneries, soit ils sont
fondamentalement idiots, soit ils ont une réelle volonté de nuire.

Et étant donné leur succès commercial, j'ai tendance (peut-être à
tort) à ne pas les prendre pour des idiots.

Dominique ROUSSEAU
Le #829490
Le lun, 16 jan 2006 at 09:38 GMT, Xavier Roche [... mime et IE ...]
Le résultat est une joyeuse soupe, en effet. Tiens, un bug toujours
aussi marrant: demandez a IE d'afficher un txt.gz. La première fois il
l'affichera tel quel. La seconde, il proposera de le télécharger.
Ensuite, selon le modulo du nombre d'essais à 2, l'une ou l'autre de
ces solutions.

Je pense qu'on doit pouvoir trouver d'autres exemples aussi poilant :p


Dans le même genre, y'a un truc crispant, c'est d'essayer de lui faire
télécharger un fichier PDF. L'heuristique sur le contenu persiste à le
faire visualiser directement dans IE via le plugin kivabien, ignorant
royalement le content-type envoyé...
(en jouant avec "content-disposition", certaines versions, selon leur
configuration accepte de proposer directement d'enregistrer le fichier
sur le disque)



Dom

Pierre Vandevennne
Le #829491
Fabien LE LEZ news::

Le truc, c'est que pour faire autant de conneries, soit ils sont
fondamentalement idiots, soit ils ont une réelle volonté de nuire.


Les developeurs de Wine (et autres) aussi...

http://www.secuobs.com/news/11012006-ossir-wmf.html

Fabien LE LEZ
Le #829270
On 16 Jan 2006 14:47:22 GMT, Dominique ROUSSEAU

Dans le même genre, y'a un truc crispant, c'est d'essayer de lui faire
télécharger un fichier PDF.


Tant qu'on en est aux joyeusetés, j'ai trouvé aussi un truc marrant
sous IE : sur une machine de test, je voulais lui faire ouvrir les
fichiers d'extension ".machin" (avec un type MIME bidon mais unique),
par l'application truc.exe.

Sous Firefox, ça marche au poil, mais IE a un comportement
"intéressant" : il télécharge le fichier sur disque dur, le supprime,
puis exécute l'application avec le fichier en paramètre. Application
qui, bien sûr, râle parce que le fichier a disparu avant qu'elle ait
pu le lire.

Bien sûr, le test a été fait sur plusieurs machines, sans anti-virus,
toujours avec le même résultat.

Règle d'or de l'informatique : si tu veux rester sain d'esprit,
n'essaie pas de comprendre ce qui se passe dans la tête d'un
programmeur de chez Microsoft.

Emmanuel Florac
Le #829266
Le Mon, 16 Jan 2006 09:38:07 +0000, Xavier Roche a écrit :

Oui mais là justement le "truc" en question n'était pas totalement
évident à implémenter ; ce n'est pas juste une commande qui traine et
qu'on a laissé, c'est un machin qui execute du code exterieur sans
demander son reste..


OUi, mais je pense que comme pour l'explication de l'oeil par l'évolution
darwinienne, on doit pouvoir trouver une explication qui ne fait pas appel
à la théorie du complot :)


C'est inexact. Il y a aussi et surtout une détection du type selon le
contenu lui même ; càd que si vous envoyez un text/html avec des
données GIF, IE va "reconnaitre" que c'est au final une image et
l'afficher. Plus, évidemment, des wrappers selon l'extension. Mais le
MIME est parfois pris en compte. Enfin parfois.


Non, je ne crois pas, la détection n'a jamais été par le contenu
(comment ferait il?) mais bien par l'extension : si j'envoie un fichier
.js avec le mimetype image/jpeg, il va l'exécuter (enfin parfois)...

--
Le commissaire : Comment vous appelez-vous?
Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas
besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut
vous intéresser.
Prévert,"les enfants du Paradis".

Emmanuel Florac
Le #829040
Le Mon, 16 Jan 2006 14:47:22 +0000, Dominique ROUSSEAU a écrit :


Dans le même genre, y'a un truc crispant, c'est d'essayer de lui faire
télécharger un fichier PDF.


Remarque, il y a une solution aisée : ne pas utiliser ce logiciel pourri.
En plus PDF n'est pas forcément très sûr non plus, surtout si on le
télécahrge avec IE :)

--
Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir
aristocratique de déplaire.
C. Baudelaire.

Dominique ROUSSEAU
Le #829037
Le mar, 17 jan 2006 at 09:52 GMT, Emmanuel Florac
Le Mon, 16 Jan 2006 14:47:22 +0000, Dominique ROUSSEAU a écrit :
Dans le même genre, y'a un truc crispant, c'est d'essayer de lui faire
télécharger un fichier PDF.


Remarque, il y a une solution aisée : ne pas utiliser ce logiciel pourri.
En plus PDF n'est pas forcément très sûr non plus, surtout si on le
télécahrge avec IE :)


Oh bah je suis bien d'accord.
Mais quand t'as le client qui 1) a vu que ça marchait avec
Mozilla/Netscape/... 2) voit que ça marche pas avec IE et 3) veut que ça
marche avec IE parceque la politique de la boite c'est d'utiliser IE
(vous comprenez, y'a rien de plus à installer, alors c'est plus pratique
quand y'a de nouvlles machines...) et que 4) c'est lui qui paye ;-)


Poster une réponse
Anonyme