Zero Day Exploit Found in Windows Media Player 177
filenavigator writes "Another zero day flaw has been reported in Windows Media player. It comes only one day after a serious zero day flaw was found in word. The flaw is dangerous because it involves IE and Outlook's ability to automatically launch .asx files. No fix from Microsoft has been announced yet."
How is this dangerous? (Score:4, Interesting)
Re:Danger: Four-byte programs could be launched? (Score:3, Interesting)
Re:4 bytes IS ENOUGH (Score:5, Interesting)
Re:All it takes is a jump instruction. (Score:5, Interesting)
At absolute worst, you could do what at least one paper calls a non-control-data attack and corrupt some other piece of data that was next to it in the heap. Except every malloc implementation I know puts a header struct at the beginning of each block, so even if two pieces of heap data ended next to each other you wouldn't be able to reach the actual data with just a 4 byte overflow, and the best you could hope for is to corrupt the header. This is very unlikely to have any exploitable effects, and is just likely to kill the process.
Ever hear of the JUMP instruction? (Score:4, Interesting)
I don't know how large they are in x86 assembly, but the 86HC11 I used to write for didn't have any instructions bigger than four bytes unless I sadly misremember. Four bytes would've been plenty.
Don't laugh. Plenty of exploits have been coded that have more difficult requirements for the exploit to work.
Re:4 bytes IS ENOUGH (Score:5, Interesting)
Worst case that's remotely likely would be that you corrupt the header that markes the beginning of the next heap block and wreak havoc with future malloc calls. Probably nothing controllable though.
Alter the next heap header to point to a location on the stack as the next free block, and send another chunk of data so malloc() is called and allocates from there. Then write your code/retp change and wait. (Or something equally bizarre)
A couple bytes overflow in the heap is abusable enough to screw with pointers; and in some cases it suddenly turns into a big overflow in situations we didn't predict (this happened with an old libpng CVE, and with an Apache flaw where the overflow was always exactly "k`" until someone figured out how to do better).
No plans to fix the Word flaw (Score:5, Interesting)
Re:WMP11 Has Serious Exploit (Score:1, Interesting)
With WMP11, both your DRMed music and your clear music will play. On other platforms, only your clear music will play. Well, on the Apple platform your Apple DRMed music will play. (Speaking of Apple, it should be known that their DRM is just as bad).
If you don't like DRM, don't buy DRMed music. WMP11 will play your clear music just fine. Meanwhile, people who are buying DRMed music will be able to play it in WMP11 without affecting the experience of those who refuse to buy DRMed music.
Also, it is not Microsoft that chooses when, where, and on what devices you may play your media. They merely provided the mechanisms that allow content providers to make those decisions. Content providers are free to let you do anything you want with your music, or provide clear content entirely. Again, if you think a content provider's policy is too restrictive, do not buy music from them.
In short, I fail to see where this is a failing of WMP11 or Vista.
Re:WMP11 EULA Time Bomb (Score:3, Interesting)
Uncertain. Hopefully you aren't getting the content from CD's. This is verbatim from the EULA:
"If the file is a song you ripped from a CD with the Copy protect music option turned on, you might be able to restore your usage rights by playing the file. You will be prompted to connect to a Microsoft Web page that explains how to restore your rights a limited number of times."
So, the CD you paid for unlimited rights to play where you want has been revoked. Permanently.
And you agreed to it. Can you go back to WMP10?
Re:All it takes is a jump instruction. (Score:2, Interesting)
It's easy (in the context of attacking a computer via a media file) to load code into a data segment, sure. But not into a text (code) segment. So the jump instruction does a local jump to -- oops, access violation.
It is truly amazing, though, that six-seven years after Microsoft really started talking big about dealing with their security problems, they still haven't managed to complete a code review to deal with buffer overrun vulnerabilities. I'm sympathetic to their massive codebase, but in many cases finding buffer overrun vulnerabilities is trained monkey work -- and Microsoft has the money to contract a large number of monkeys, train them, and sic 'em on the code. Sure, there's also a lot of work there for skilled programmers and even engineers -- a lot of their stuff is written in languages like C and C++ where you can pass a buffer to a method without its bounding information -- but surely they could have the monkeys at least flag up what the more skilled people need to look at. It's been a long time, guys. Lots of code, sure, but lots of years, too.