La faille WMF etait-elle une vrai backdoo r ?

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=60006>
<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.