WMF Exposes Bad Design

Crisis of the day; an unpatched vulnerability that allows malformed .WMF files to run as raw code, i.e. the classic "insane code" scenario that can explode anywhere, any time.

See elsewhere for evolving details of the defect, workarounds, vulnerability detection tools and so on. DEP is mooted as a protection, but I am not certain that all exploits will trip DEP; in any case, DEP's only fully effective on XP SP2 systems with DEP-capable processors, and where other software issues haven't required it to be disabled.

Code defects can arise anywhere, any time, regardless of what the code is supposed to be doing by design. The hallmark of the pure code defect is that the results bear no relation to design intentions, and can thus be considered insane.

So it follows that any part of the OS may need to be amputated (or bulkheaded off) at any time.

When the problem is an inessential associated file type, this should be as easy as redirecting that file type away from the defective engine that processes it - and this is where bad OS design comes to light.

File associations are not simply there to "make things work"; they are also the point at which the user exerts control. The problem is, the OS often blurs file association linkages based on information hidden from the user, such as header information embedded in the file's data. If anything, the trend is getting worse, with the OS sniffing file content and changing its management according to what it finds hidden there, even if this differs from the information on which the user judged the risk of "opening" the file.

This is unsafe design. Surely by 2005, it should be obvious to mistrust content that mis-represents its nature? Even when the risk significance is less obvious than a .PIF containing raw .EXE code, the fact that any file type can suddenly become hi-risk due to an exploitable code defect should imply that all file types should be "opened" only by the code appropriate for the file type claimed.

As it is, simply changing (or killing) the association for .WMF files may be ineffective, because if the OS is presented with a file of different file name extension and it recognises the content as WMF, it will pass it to the (defective) WMF handler.

The lesson here goes beyond fixing this particular defect, resolving to code better in future (again), and always swallowing patches as soon as the vendor releases them (a sore point in this case, as exploitation precedes patch). We should also ensure that file content is processed only as expected by the file name extension; any variance between this and the content should be considered hostile, and blocked as such.