http://grc.com/securitynow.htm

Contains a series of podcasts concerning Windows and Internet security, between Steve Gibson and Leo LaPorte.  I have learned quite a lot.  A new episode comes out every week.

The latest episode, 22, discusses Steve Gibsons' research into the recently exposed WMF flaw.  The bottom line... he believes this was a backdoor planted by MicroSoft to enable them to execute code/fixes, bypassing firewall, AV, and spyware precautions.

farrier
Posted on 2006-01-14 12:23:46 by farrier

The bottom line... he believes this was a backdoor planted by MicroSoft to enable them to execute code/fixes, bypassing firewall, AV, and spyware precautions.


Those conspirators crack me up sometimes.  :roll:
No one, no matter how stupid he is (or monopolistic as the microsoft, which actually can afford some slips from time to time), will take the chance of implementing intentional security vulnerability for their own unauthorized access.
Posted on 2006-01-14 15:27:05 by arafel
I'm far from bein a conspirator but I do find it funny that one can execute real code through a jpg or a wmf. That should not be possible ever, unless you want it to happen. (I haven't yet looked at those videos, and probaly won't ;) Just don't have the time for it atm :p)
Posted on 2006-01-14 15:39:41 by JimmyClif
So when a web/mail/whatever server can't handle some piece of data, giving a nice vulnerability - It's ok. Usual vulnerability, nothing interesting.
But when same happens with graphics rendering engine - intentional!?
Posted on 2006-01-14 16:29:27 by arafel

The latest episode, 22, discusses Steve Gibsons' research into the recently exposed WMF flaw.  The bottom line... he believes this was a backdoor planted by MicroSoft to enable them to execute code/fixes, bypassing firewall, AV, and spyware precautions.


So he's gone from being a harmless crackpot to a full-blow lunatic with paranoid delusions...
Posted on 2006-01-14 18:25:39 by stormix
arafel,

Kind of...A jpg should be getting unpacked and blitted on the screen, if corrupt abort. Not rocket science. I don't say they do it on purpose, I don't see the big picture and I never created a player or even a jpg unpacker / displayer to be in any kind of position to talk here, but I can't imagine that if I had coded a jpg displayer that it would ever execute any code hidden into a picture - if you know what I mean ;)

stormix,

:lol:
Posted on 2006-01-14 21:43:55 by JimmyClif
hi,

the WMF vulnerability is like any other... Surely is not intentional.

And the fact of be a graph format dont mean that it executing arbitrary code is a bigger mistake than a vuln in other place.

Is not a JMP EAX that is badly used... Is a stack return address that is overwrited: any that receive user data (and is sloppy coded) can suffer this problem

Saying that is intentional coz is in a graph file, and "jpg where never supposed to have code" is not knowing nothing about exploits. HELO strings in SMTP servers also dont are supposed to have code inside ;)

ancev

ps: now that i read a bit more about this particular vuln, seens that (altought is not intentional, i believe), its a bad design error - not a classical buffer overflow or a format string
Posted on 2006-01-15 08:42:31 by ancev
A thing you must keep in mind: Gibson is a sensationalist that wants attention. He even admits that he hasn't really analyzed the flaw, he just tried various ways of emitting a WMF file until he made it exploit - and then he goes on to make these wild accusations.

http://www.donationcoder.com/Forums/bb/index.php?topic=1993.0
Posted on 2006-01-15 11:21:06 by f0dder
JimmiClif,

I can't understand why to make such distinction between regular exploits and wmf related one.

Exploit basically is: A processing B -> if B is supplied incorrectly -> A processes B in a wrong way.

No matter how stupid and generic above example is, it's actually exactly how every single exploit works. Whenever its' a buffer overflow, format string or bad and inadvertent design (WMF).
I see no reason why something should be considered exceptional only because the processing party (A) and processed data (B) do not fail under the same category as every other case.

...Though such vulnerability like in WMF may seem a bit suspicious, it's can be hard to believe that someone will unintentionally make such weird security flaw in design. However please note that WMF was designed about 15 years ago (windows 3.1 era if i not mistaken) and do you remember how much exactly emphasis was put on security back then?



edit: The above was directed more towards Steve Gibsons and people who blindly claim iit to be some kind of conspiracy.
Your point of view I do understand.  8)
Posted on 2006-01-15 11:43:03 by arafel
As for "the abort thingamajig shouldn't be present in the file" statements, as far as I can tell metafiles are more or less just a dump of GDI commands - so it does make sense that this record can be present, even if it's not really useful.
Posted on 2006-01-15 12:26:12 by f0dder
Back door in M$ code versus a over looked buffer overflow. 

Well, we could sue for all our money back in a class action suit for illegal access to software that Microsoft already owns and we have a permenant use license.

I think M$ not that slow to allow a good reason to get our money back.  ;)

Regards,  P1  8)

Posted on 2006-01-15 15:24:37 by Pone
It's not a buffer overflow, but a design flaw in the WMF file format. What actually happened was this: metafiles were actually GDI command pipelines at first, and one of the commands that could be pipelined was the SetAbortProc function, that allows an application to set a callback when an error occurs. This is still used to catch some printer errors.

Then MS had the idea of dumping these pipelines to a file format, in order to support vector graphics. So they marshalled all data that was originally layed out in memory, and that's the WMF file format. In the process of marshalling everything, they forgot about the SetAbortProc function - so any WMf file can set a callback! This is very bad, specially because the parser actually helps the attacker: there's no need to guess the shellcode address in memory, since the parser will happily calculate it for you. :mad:

Well, actually not *any* metafile has this problem. This has been patched in a number of places (there are some 5 variants of the WMF file format, roughly, and none of them is vulnerable). But the original 16-bit non-placeable format, still supported for backwards compatibility with legacy versions of Windows, remained vulnerable.

As for Gibson's remarks, he makes quite a few mistakes in his description of the bug, proving that he didn't put much more of five minutes on his "forensic analysis". :)  One f them is the claim that the only way to trigger the bug is to place a "magical number" inside the WMF file, so a well-formed file can't trigger the bug.

This is false - a well formed file does trigger it. He just screwed up in his tests: the callback function is supposed to be called on error, if it's the last record in the file there won't be an error, and thus the function never gets called. But if you break the file, there will be an error, and the function will be called. You can still trigger the bug by adding more records to the file, and causing an error in any of them.

Besides this, nothing tells whether this flaw was intentional or not - or if it was, whether it was planted by a discontent employee or Bill Gates himself. ;) Also, the conspiracy would have to include the open source folks, as WINE was also vulnerable! :D

To add to that, Internet Explorer won't render metafiles without the aid of special plugins, and Windows 2000 doesn't come with any program at all to open these files (the extension is not even registered in the shell). So what's the use of a backdoor that doesn't even work? :) If MS wanted to put backdoors in Windows, there were far better ways.

More likely this is the result of MS's age-old practice of putting ease of use before security... :roll:

LATER: Here's MS response:

http://blogs.technet.com/msrc/archive/2006/01/13/417431.aspx
Posted on 2006-01-16 10:13:53 by QvasiModo

It's not a buffer overflow, but a design flaw in the WMF file format. What actually happened was this: metafiles were actually GDI command pipelines at first, and one of the commands that could be pipelined was the SetAbortProc function, that allows an application to set a callback when an error occurs. This is still used to catch some printer errors. ...
Well, I guess all the hackers will look for all the other call back style interfaces in all the other OS files.

Regards,  P1  8)
Posted on 2006-01-16 10:49:33 by P1
It actually is a 'jmp eax', to the poster above. See CallExploitProc.

For the curious, I disassembled a few key pieces.

This is the actual meta record processing that invokes the procedure:

.text:77F25912 PlayMetaFileLoop:                       ; CODE XREF: sub_77F23F47+198j
.text:77F25912                                        ; EnumMetaFile+29Dj
.text:77F25912                cmp    esi, ebx
.text:77F25914                jz      loc_77F24134
.text:77F2591A                cmp    esi, 0FFFFFFFFh
.text:77F2591D                jz      short canceljob
.text:77F2591F                cmp    , ebx
.text:77F25922                jnz    short loc_77F2592D
.text:77F25924                mov    eax,
.text:77F25927                test    byte ptr , 8
.text:77F2592B                jz      short canceljob
.text:77F2592D
.text:77F2592D loc_77F2592D:                          ; CODE XREF: EnumMetaFile+268j
.text:77F2592D                mov    eax, dword ptr
.text:77F25930                cmp    eax, ebx
.text:77F25932                jz      short continuejob ; if eax = 0, continue processing
.text:77F25934                mov    eax,   ; get proc addr from cmnd
.text:77F25937                cmp    eax, ebx        ; if no function, don't call
.text:77F25939                jnz    CallExploitFunction ; else, go invoke it
.text:77F2593F
.text:77F2593F continuejob:                            ; CODE XREF: EnumMetaFile+278j
.text:77F2593F                                        ; .text:77F33404j
.text:77F2593F                push        ; UINT
.text:77F25942                push    esi            ; LPMETARECORD
.text:77F25943                push        ; LPHANDLETABLE
.text:77F25946                push    edi            ; HDC
.text:77F25947                call    PlayMetaFileRecord
.text:77F2594C                push    esi
.text:77F2594D                push   
.text:77F25950                call    sub_77F270B4
.text:77F25955                mov    esi, eax
.text:77F25957                jmp    short PlayMetaFileLoop
.text:77F25957 EnumMetaFile    endp
.text:77F25957

......

.text:77F333FE CallExploitFunction:                    ; CODE XREF: EnumMetaFile+27Fj
.text:77F333FE                push    ebx
.text:77F333FF                push    edi
.text:77F33400                call    eax
.text:77F33402                test    eax, eax
.text:77F33404                jnz    continuejob
.text:77F3340A                jmp    canceljob


Up-stream is a check to make sure a META_ESCAPE function isn't 0F WMCOMMENT in the unpatched version. In the patched version, they also checked for 0F SETABORTPROC. Here's the patched code that uses a new function to check to make sure the function isn't 9 or F:


loc_7D828D4B:                          ; CODE XREF: .text:7D828648j
.text:7D828D4B                movzx  ecx, word ptr
.text:7D828D4F                push    ecx
.text:7D828D50                call    IsEscapeAllowed  ; check type 09 of 0F  - unpatched only checks for 0fh here
.text:7D828D55                test    eax, eax
.text:7D828D57                jz      NotAllowed      ; default
.text:7D828D5D                push    0
.text:7D828D5F                lea    eax,
.text:7D828D62                push    eax
.text:7D828D63                movzx  eax, word ptr
.text:7D828D67                push    eax
.text:7D828D68                push    ecx
.text:7D828D69                push    dword ptr
.text:7D828D6C                call    Escape
.text:7D828D71                jmp    loc_7D82861B

...

.text:7D8427B5 IsEscapeAllowed proc near              ; CODE XREF: .text:7D828D50p
.text:7D8427B5
.text:7D8427B5 arg_4          = dword ptr  8
.text:7D8427B5
.text:7D8427B5                mov    edi, edi
.text:7D8427B7                push    ebp
.text:7D8427B8                mov    ebp, esp
.text:7D8427BA                xor    eax, eax
.text:7D8427BC                cmp    , 9      ; SETABORTPROC?
.text:7D8427C0                jz      short Disallow
.text:7D8427C2                cmp    , 0Fh  ; MFCOMMENT ?
.text:7D8427C6                jz      short Disallow
.text:7D8427C8                inc    eax
.text:7D8427C9
.text:7D8427C9 Disallow:                              ; CODE XREF: IsEscapeAllowed+Bj
.text:7D8427C9                                        ; IsEscapeAllowed+11j
.text:7D8427C9                pop    ebp
.text:7D8427CA                retn    4
.text:7D8427CA IsEscapeAllowed endp
.text:7D8427CA


Latez
Posted on 2006-01-16 19:12:52 by db90h
a little offtpic, but is it true windows sends your requests on port 80 to MS each time you do a "file search" on your HD?
Posted on 2006-01-17 11:48:05 by HeLLoWorld
That sounds ridiculous, helloworld. XP does contact Microsoft servers on port 80, but afaik that is related to product key authentication and windows updates...
Posted on 2006-01-17 12:22:02 by f0dder
that was on fravias site.

its supposed to be tested and observed.
Posted on 2006-01-17 12:50:35 by HeLLoWorld
Not so strange... remember when IE used to keep a hidden history of visited webpages :(

It that's way different from a backdoor, this one may have an economic benefit (marketing for example).
Posted on 2006-01-17 17:39:52 by QvasiModo
Doesn't it still keep a history of visited webpages?

I'm glad it does - URL auto-complete and "history search" are features I use often.
Posted on 2006-01-17 17:52:38 by f0dder
The hidden one you can't delete? I thought it had been removed already >:(
Posted on 2006-01-17 18:08:05 by QvasiModo