Seems very unlikely to me

Post #241,519 by JayMehaffey 1/16/06 3:18:21 PM Reply	Seems very unlikely to me If Gibson's understanding of the coding vunrability is right then I agree with him, it's very hard to think that it is a coding mistake. It strikes me as also very unlikely that somebody as MS intentionally left such a backdoor in Windows. My guess would be that some programmer at MS put the backdoor in on his own because it was handy for debugging something he was working on or some such and it never got taken out. Jay
Post #241,525 by bepatient 1/16/06 4:07:08 PM Reply	But thats just as bad especially in light of the code freeze and review. It should have been caught...but wasn't (which he covers). I would not be hard-pressed to believe that there are several of these, there on purpose and that this one simply "got found out". Sort of like easter eggs...only with a completely different purpose (NSA or otherwise). If you push something hard enough, it will fall over. _{Fudd's First Law of Opposition} [link\|mailto:bepatient@aol.com\|BePatient]
Post #241,532 by drewk 1/16/06 5:03:27 PM Reply	Do I unnderstand this right? I heard it had to do with printing images, and the ability to abort a print job. Is that appropriate to put in the image code, and not the printing code? I guess for really large files on older hardware it could take a while to finish converting it into a printable format and you'd want to be able to interrupt it. But wouldn't it make more sense <question class="from ignorance">to spawn a thread for the printing, and if you receive the interrupt from the printing system you just kill that one thread?<question> === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com]
Post #241,538 by boxley 1/16/06 5:17:35 PM Reply	did $MS understand multithreading when they wrote it? Any opinions expressed by me are mine alone, posted from my home computer, on my own time as a free american and do not reflect the opinions of any person or company that I have had professional relations with in the past 50 years. meep
Post #241,548 by JayMehaffey 1/16/06 6:38:38 PM Reply	It is part of that I guess for really large files on older hardware it could take a while to finish converting it into a printable format and you'd want to be able to interrupt it. But wouldn't it make more sense <question class="from ignorance">to spawn a thread for the printing, and if you receive the interrupt from the printing system you just kill that one thread?<question> The function in question is the one a program uses to tell Windows that you want that interrupt and where you want that notification send in your program. But this function not for the conversion phase, it is for the actual printing part. This is to handle the case where the program is done with the printing entirly, but the physical pages are not done coming out of the printer. This lets the program get notification if the print job is stopped after the program is done with it. As for why the function exists at all for WMF and display routines, it is because of Windows unified drawing subsystem. Windows, in theory, has one set of drawing functions that are used for all output contexts. WMF are really just a way of storing those drawing commands in a file, and thus WMFs have access to the same functions as display and printer routines. Jay
Post #241,570 by broomberg 1/16/06 9:08:08 PM Reply	No. He was using the explanation of printing VS viewing as a reason why MS MIGHT have screwed up and done it by accident. If a file is going to the print subsystem, there is the possibility that the job will need to be aborted after the hand-off. So there is the ability to drop a callback into the file that will allow the print subsystem to check if it has been aborted. The callback is a 4 byte address in the submitting program's memory space, which hold a routine, and will tell the print subsystem whether the job should be aborted. This is a different. In this case, there is an illegal instruction in the wmf file that is VERY unlikely to be there by accident. It essential saya that the length of the data to follow is 1 byte, but since it is dealing in words is must be at LEAST 4 bytes. Combined that with the abort instruction. And then, rather than jump to a callback (which would be appropriate if this was a mistake, ie: cut-and-paste of the underlying code that make no sense for viewing rather than printing), start executing code contained within the image file. This also means there is no return to current operation, since the stack is destroyed,
Post #241,549 by JayMehaffey 1/16/06 6:43:55 PM Reply	I would say not quite as bad Of course, I would also say it is the difference between criminal negligence and homicide. Either way it is a crime. Jay
Post #241,590 by static 1/16/06 10:56:52 PM 1/18/06 1:02:33 AM Reply	Microsoft have an explanation. And I believe it's credible. [link\|http://blogs.technet.com/msrc/archive/2006/01/13/417431.aspx\|http://blogs.technet...01/13/417431.aspx] To detail it a little bit, SetAbortProc functionality was a needed component in the graphics rendering environment for applications to register a callback to cancel printing, before even the WMF file format existed. ... Around 1990, WMF support was added to Windows 3.0 as a file-based set of drawing commands for GDI to consume. The SetAbortProc functionality, like all the other drawing commands supported by GDI, was ported over (all in assembly language at this point) by our developers to be recognized when called from a WMF. This was a different time in the security landscape and these metafile records were all completely trusted by the OS. To recap, when it was introduced, the SetAbortProc functionality served an important function. He goes on to say that IE's WMF execution would not recognise the function class that SetAbortProc is in, but there are simple ways to trick it into running such a WMF file via another program anyway. It looks like a case of a very old and still very useful low-level Windows function that is still around but the landscape around it has changed so much that it's causing problems. Wade. "Insert crowbar. Apply force." Edited by static Jan. 18, 2006, 01:02:33 AM EST Expand All History
Post #241,593 by admin 1/16/06 11:01:16 PM Reply	Artful Dodging That's not why Gibson thought it was a back door. The back door part comes in when you realize that the SetAbortProc functionality only works in a WMF when you explicitly (and incorrectly) set the content size to 1. BTW, fix your link, please. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #241,713 by static 1/18/06 1:08:26 AM Reply	Link fixed. Actually, I think MS and Gibson are talking past each other. This MS guy is asserting that Gibson is basically wrong to think of it as a backdoor. OTOH, Gibson seems to have found a genuine bug in the parsing of a WMF, if an incorrect length of 1 can trigger that behaviour. It'd be interesting to see his counter-response (he hasn't posted one yet). Wade. "Insert crowbar. Apply force."
Post #241,594 by admin 1/16/06 11:02:31 PM Reply	I like how that "blog" doesn't allow comments, too. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #241,602 by Andrew Grygus 1/17/06 2:41:55 AM Reply	If it's brought forward from legacy stuff . . . . . how come legacy Windows isn't vulnerable? The features enabling the vulnerability were introduced in Windows 2000 and XP. [link\|http://www.aaxnet.com\|AAx]
Post #241,637 by mmoffitt 1/17/06 11:03:40 AM Reply	Dang. Beat me to it. That was my first thought. bcnu, Mikem It would seem, therefore, that the three human impulses embodied in religion are fear, conceit, and hatred. The purpose of religion, one might say, is to give an air of respectibility to these passions. -- Bertrand Russell
Post #241,675 by altmann 1/17/06 8:29:52 PM Reply	No default program for WMF = No "critical" vulnerability -- Chris Altmann

Welcome to IWETHEY!