cprintf
15-01-2006, 11:06
Secondo voi è plausibile questa cosa? Qualcuno riesce a verificarla oppure l'ha già verificata?
http://www.grc.com/sn/SN-022.htm
<<
The Windows MetaFile Backdoor?
Description: Leo and I carefully examine the operation of the recently patched Windows MetaFile vulnerability. I describe exactly how it works in an effort to explain why it doesn't have the feeling of another Microsoft "coding error." It has the feeling of something that Microsoft deliberately designed into Windows. Given the nature of what it is, this would make it a remote code execution "backdoor." We will likely never know if this was the case, but the forensic evidence appears to be quite compelling.
The Windows MetaFile Backdoor?
Steve: Well, okay. First of all, it makes no sense at all in a metafile device context. In the context of processing a metafile, setting a printer abort is crazy because it's not a printer context. You don't print metafile contexts in this way. It's just not the way it's done in Windows. So it doesn't make sense. But it's like, okay, well, so maybe, you know, it's there anyway; they didn't think to remove it or take it out. Except that, when I was pursuing this and finally got it to work, what Windows did when it encountered this Escape function, followed by the SETABORTPROC metafile record, was it jumped immediately to the next byte of code and began to execute it. That is, it was no longer interpreting my metafile records record by record, which is the way metafiles are supposed to be processed. You don't actually execute the metafile. As we said before last week, and I think the week before, it's sort of a script. It's a script of Windows graphics calls that allow you to specify, you know, draw a rectangle from here to here, draw a line from there to there. And it's in a nice sort of device-independent fashion. So you don't run the code in the metafile. But what Windows did when it encountered this particular nonsensical sequence was to start executing the next byte of code in the metafile.
Leo: Hmm.
Steve: And it's like, okay, wait a minute.
Leo: Why?
Steve: You know, that's crazy. But what's even more crazy is what it took for me to make it do this. As I said before, each record in a metafile begins with a four-byte length, followed by a two-byte function number. So in other words, each metafile record has six bytes minimum that it can possibly be in size. Oh, and since the size is in words, the smallest possible size for a metafile record would be three words long, or six bytes. Look, the reason I had problems making this exploit happen initially is I was setting the length correctly. It turns out that the only way to get Windows to misbehave in this bizarre fashion is to set the length to one, which is an impossible value. I tried setting it to zero. It didn't trigger the exploit. I tried setting it to two, no effect. Three, no effect. Nothing, not even the correct length. Only one.
[...]
Leo: So you're saying intentionally or - Microsoft intentionally put a backdoor in Windows? Is that what you're saying?
Steve: Yes.
Leo: Well, that's a pretty strong accusation. Could this not have been a...
Steve: Well, it's the only conclusion...
Leo: It couldn't have been a mistake?
Steve: I don't see how it could have been a mistake. Again, I'm going to continue to look at it. But from what I've seen now, this had to be deliberate. It was not what we were led to believe. Well, and it's funny, too, because then I thought, okay, wait a minute, Microsoft has lied to us. I reread the original vulnerability spec in, you know, their vulnerability page. And they never say this isn't the case. I mean, they describe it as a vulnerability, which it certainly is. Nowhere, you know, is even what I'm saying contradicted by their page.
Leo: So you're saying Microsoft, or people at Microsoft maybe unbeknownst to Microsoft, intentionally put code in Microsoft Windows that will allow anybody who knew about it access any Windows machine, to get into any Windows machine and run any arbitrary code on it.
Steve: Well, it's not like a trojan, where they would be able to contact a remote machine. But, for example, if Microsoft was worried that for some reason in the future they might have cause to get visitors to their website to execute code, even if ActiveX is turned off, even if security is up full, even if firewalls are on, basically if Microsoft wanted a short circuit, a means to get code run in a Windows machine by visiting their website, they have had that ability, and this code gave it to them.
Leo: And there'd be nothing anybody could do about it or - and in most cases detect it. So it sounds like - and I really want to be careful here because this is a very serious accusation. It sounds like this was done on purpose by Microsoft or somebody at Microsoft. It sounds like it was accidentally discovered. Microsoft reacted and has pulled it out now.
Steve: Right.
[...]
Leo: Could this have been at the request of a government agency, let's say? I guess not because, as you point out, it's not a trojan horse. You have to go to a site. You have to go to the site of somebody who knows about this exploit to be taken advantage of. And in fact, the scenario you describe is really the only scenario I can think of, Microsoft doing it so that, if worst case happened, they would be able to update a machine. They'd be able to say, go to the Microsoft site and we'll fix you or something. I mean, the NSA wouldn't put this in because they couldn't guarantee access to any computer.
Steve: I've looked back over all the documentation. I can't find anything about this documented anywhere. Okay, then I said - I played my own devil's advocate. Okay, so code is running in the metafile. Wouldn't that be useful? Wouldn't it be useful if a metafile could contain executable code, sort of as an undocumented feature? Microsoft never got around to writing about it; but they said, oh, this would be cool, and we'll use the SETABORTPROC. Notice that SETABORTPROC, it was just, I mean, this has nothing to do with printer aborting. It was just sort of a - it was a value that they had handy from other processing, and they sort of reused it. But this has got nothing to do with aborting printing. So it almost helped with the obfuscation and sort of, you know, the plausible deniability, except that this wasn't a coding mistake. And, you know, you even had to put the magic key into the length of the record in order to get this to work. And that was protection from somebody's metafile having a SETABORTPROC metafile record in it and tripping over this backdoor by mistake.
Leo: This is exactly what you would do, if you were going to write a backdoor, this is exactly how you would do it.
Steve: Yeah. Yeah. So I asked myself, isn't there, like, a constructive purpose for putting code in a metafile? And the problem is, code running in the metafile doesn't have access to the context of the metafile. It doesn't know what to do with it. It's, you know, it's powerless to use the objects that Windows is using. And there seems to be no way to get back to Microsoft's code from this. Again, I've got some more work to do, and then the timing of this Security Now! podcast coincided with, you know, I've known this for a day now. And I've been going back over it and trying to come up with a reason, I mean, a benign reason for this. And I just don't see it.
Leo: I suppose we should contact Microsoft and ask them what they think about this. But I doubt that we'd get a straight answer.
Steve: I've tried doing that before on other issues like this, Leo. And, you know, it's not useful. So...
Leo: In this case, you know, Microsoft often says, well, don't reveal this stuff because give us a chance to fix it because it could be a security issue. But the security issue has already been revealed. We're not revealing anything that isn't already known. We're just asking why is it in there.
Steve: Yeah.
Leo: And the answer is not very encouraging. It does make you think maybe open source is a better way to go for an operating system. At least if it were in there, somebody would have had a chance to see it.
Steve: Well, and setting this length of the metafile record to one, that breaks the metafile processing. It's not possible to, like, execute some code, then go back and finish things up gracefully. I mean, you've got a thread running on your own code, in your own image. And everything is, like, over at that point. I mean, it just makes no sense.>>
http://www.grc.com/sn/SN-022.htm
<<
The Windows MetaFile Backdoor?
Description: Leo and I carefully examine the operation of the recently patched Windows MetaFile vulnerability. I describe exactly how it works in an effort to explain why it doesn't have the feeling of another Microsoft "coding error." It has the feeling of something that Microsoft deliberately designed into Windows. Given the nature of what it is, this would make it a remote code execution "backdoor." We will likely never know if this was the case, but the forensic evidence appears to be quite compelling.
The Windows MetaFile Backdoor?
Steve: Well, okay. First of all, it makes no sense at all in a metafile device context. In the context of processing a metafile, setting a printer abort is crazy because it's not a printer context. You don't print metafile contexts in this way. It's just not the way it's done in Windows. So it doesn't make sense. But it's like, okay, well, so maybe, you know, it's there anyway; they didn't think to remove it or take it out. Except that, when I was pursuing this and finally got it to work, what Windows did when it encountered this Escape function, followed by the SETABORTPROC metafile record, was it jumped immediately to the next byte of code and began to execute it. That is, it was no longer interpreting my metafile records record by record, which is the way metafiles are supposed to be processed. You don't actually execute the metafile. As we said before last week, and I think the week before, it's sort of a script. It's a script of Windows graphics calls that allow you to specify, you know, draw a rectangle from here to here, draw a line from there to there. And it's in a nice sort of device-independent fashion. So you don't run the code in the metafile. But what Windows did when it encountered this particular nonsensical sequence was to start executing the next byte of code in the metafile.
Leo: Hmm.
Steve: And it's like, okay, wait a minute.
Leo: Why?
Steve: You know, that's crazy. But what's even more crazy is what it took for me to make it do this. As I said before, each record in a metafile begins with a four-byte length, followed by a two-byte function number. So in other words, each metafile record has six bytes minimum that it can possibly be in size. Oh, and since the size is in words, the smallest possible size for a metafile record would be three words long, or six bytes. Look, the reason I had problems making this exploit happen initially is I was setting the length correctly. It turns out that the only way to get Windows to misbehave in this bizarre fashion is to set the length to one, which is an impossible value. I tried setting it to zero. It didn't trigger the exploit. I tried setting it to two, no effect. Three, no effect. Nothing, not even the correct length. Only one.
[...]
Leo: So you're saying intentionally or - Microsoft intentionally put a backdoor in Windows? Is that what you're saying?
Steve: Yes.
Leo: Well, that's a pretty strong accusation. Could this not have been a...
Steve: Well, it's the only conclusion...
Leo: It couldn't have been a mistake?
Steve: I don't see how it could have been a mistake. Again, I'm going to continue to look at it. But from what I've seen now, this had to be deliberate. It was not what we were led to believe. Well, and it's funny, too, because then I thought, okay, wait a minute, Microsoft has lied to us. I reread the original vulnerability spec in, you know, their vulnerability page. And they never say this isn't the case. I mean, they describe it as a vulnerability, which it certainly is. Nowhere, you know, is even what I'm saying contradicted by their page.
Leo: So you're saying Microsoft, or people at Microsoft maybe unbeknownst to Microsoft, intentionally put code in Microsoft Windows that will allow anybody who knew about it access any Windows machine, to get into any Windows machine and run any arbitrary code on it.
Steve: Well, it's not like a trojan, where they would be able to contact a remote machine. But, for example, if Microsoft was worried that for some reason in the future they might have cause to get visitors to their website to execute code, even if ActiveX is turned off, even if security is up full, even if firewalls are on, basically if Microsoft wanted a short circuit, a means to get code run in a Windows machine by visiting their website, they have had that ability, and this code gave it to them.
Leo: And there'd be nothing anybody could do about it or - and in most cases detect it. So it sounds like - and I really want to be careful here because this is a very serious accusation. It sounds like this was done on purpose by Microsoft or somebody at Microsoft. It sounds like it was accidentally discovered. Microsoft reacted and has pulled it out now.
Steve: Right.
[...]
Leo: Could this have been at the request of a government agency, let's say? I guess not because, as you point out, it's not a trojan horse. You have to go to a site. You have to go to the site of somebody who knows about this exploit to be taken advantage of. And in fact, the scenario you describe is really the only scenario I can think of, Microsoft doing it so that, if worst case happened, they would be able to update a machine. They'd be able to say, go to the Microsoft site and we'll fix you or something. I mean, the NSA wouldn't put this in because they couldn't guarantee access to any computer.
Steve: I've looked back over all the documentation. I can't find anything about this documented anywhere. Okay, then I said - I played my own devil's advocate. Okay, so code is running in the metafile. Wouldn't that be useful? Wouldn't it be useful if a metafile could contain executable code, sort of as an undocumented feature? Microsoft never got around to writing about it; but they said, oh, this would be cool, and we'll use the SETABORTPROC. Notice that SETABORTPROC, it was just, I mean, this has nothing to do with printer aborting. It was just sort of a - it was a value that they had handy from other processing, and they sort of reused it. But this has got nothing to do with aborting printing. So it almost helped with the obfuscation and sort of, you know, the plausible deniability, except that this wasn't a coding mistake. And, you know, you even had to put the magic key into the length of the record in order to get this to work. And that was protection from somebody's metafile having a SETABORTPROC metafile record in it and tripping over this backdoor by mistake.
Leo: This is exactly what you would do, if you were going to write a backdoor, this is exactly how you would do it.
Steve: Yeah. Yeah. So I asked myself, isn't there, like, a constructive purpose for putting code in a metafile? And the problem is, code running in the metafile doesn't have access to the context of the metafile. It doesn't know what to do with it. It's, you know, it's powerless to use the objects that Windows is using. And there seems to be no way to get back to Microsoft's code from this. Again, I've got some more work to do, and then the timing of this Security Now! podcast coincided with, you know, I've known this for a day now. And I've been going back over it and trying to come up with a reason, I mean, a benign reason for this. And I just don't see it.
Leo: I suppose we should contact Microsoft and ask them what they think about this. But I doubt that we'd get a straight answer.
Steve: I've tried doing that before on other issues like this, Leo. And, you know, it's not useful. So...
Leo: In this case, you know, Microsoft often says, well, don't reveal this stuff because give us a chance to fix it because it could be a security issue. But the security issue has already been revealed. We're not revealing anything that isn't already known. We're just asking why is it in there.
Steve: Yeah.
Leo: And the answer is not very encouraging. It does make you think maybe open source is a better way to go for an operating system. At least if it were in there, somebody would have had a chance to see it.
Steve: Well, and setting this length of the metafile record to one, that breaks the metafile processing. It's not possible to, like, execute some code, then go back and finish things up gracefully. I mean, you've got a thread running on your own code, in your own image. And everything is, like, over at that point. I mean, it just makes no sense.>>