Slashdot Mirror
Zero Day Exploit Found in Windows Media Player
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."
Seems to be a bit like finding holes in swiss chese... inevitable....
Physics is nothing like religion. If it was, we'd have an easier time trying to raise money!
Must be Thursday.
P.S.,
This is what part of the alphabet would look like if Q and R were eliminated.
I know overflows are bad, but I honestly don't know much about how the allocator in a typical OS or RTL works. Could such a small (2-4 byte) overflow be used to execute arbitrary code? Is it actually possible to use that small of an overflow to screw up the allocator so badly that it'll execute arbitrary code? Or is this just a potential denial of service?
using namespace slashdot;
troll::post();
FYI, this does not seem to affect Windows Media Player 11, which is available via Windows Update or the WMP site.
It also does not affect Vista, both because Vista comes with WMP 11, and thanks to IE7 running in protected mode. This would likely cause the browser to crash, however.
..., it's a flaw. I'll be impressed if someone can do anything with a 4 bytes heap overflow that happens at a single spot in the program they don'T control. Under ideal circumstances, they'll be able to tamper an integer in WMP.
It's a heap buffer (assuming TFA is right), which means the return address will be nowhere near it. There *could* still be neighboring security-sensitive code, but it's extremely unlikely. 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. This *really* isn't that big of a deal, and calling it a zero-day exploit is downright libel.
Nah.
x86 processors have a local jump instruction that is 4 bytes long. If the exploiter is able to get his code loaded within range of that jump instruction, you're fucked. And really, getting code loaded like that is not a difficult thing to do.
In fact, many x86 operating systems have used such a technique to dynamically patch kernel code. They insert a couple of nop operations after a function prologue. These operations normally do nothing, but can be replaced with a jump instruction at runtime. This allows for the instructions of the existing function to be replaced with ease.
Doesn't affect my Vista machine. Nor my XP Pro machine running IE7 + WMP 11.
Seeing things like this, I can't help but wonder what it might look like if every time a flaw was discovered in *Nix, and a security advisory (even if barely remotely applicable, as in this case) were released,and slashdotted. Maybe this post is flamebait too (seems to be my trend as of late), maybe not. But the title of this particular post, is pretty misleading.
0 day flaw! Congratulations. It's software. I still play games that if they run for more than 2 hours I'm lucky. The real problem is the testing, and the coding that goes into these. You fix one thing, and something else inevitably breaks.
How often does a kernel update in Linux break something that you now have to update, or sometimes roll back alltogether because they won't work.
This post is as Overdramatic as going nuts every single time something in Linux broke or didn't work right. Sometimes MS deserves to be thumped on the head. This time though, seriously, come on. Tell you what, run your 4 byte program that is gonna hax0r my computer. I invite it, might give me something to do.
Umm, do you know what you're talking about? All you do is jump over to your NOOP slide or whatever embedded in the data that slides all the way down to the program disguised as some part of the ASX file.
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.
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).
Support my political activism on Patreon.
Actually, this isn't the second Zero Day Exploit. The first one was a Nullity Day Exploit. But we don't have to worry about that one.
Paul Grosfield - the quicker picker upper.
Microsoft have just given advance notification of what their bundle of patches to be released next Tuesday will contain. There are five general Windows bulletins there - no surprise that the most severe is 'critical' - but I'm kind of surprised to see they have no intention of shipping any Office-related fixes.
But it is not a flaw in the DRM, ao why ahould Microsoft care?
This flaw is not "barely remotely applicable".
The vast majority of Windows users do not run Vista, IE7, or WMP11, even though all are technically available.
So this particular flaw affects most Windows users, and is thus important to those that have to deal with these users and/or their computers.
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
And that's how black holes came about. Read your bibles people!! I quote from it:
"And God saith, I shall divide by zero.
And big black things did appear.
And God saith, I shall not do that again."
If you can't say something nice, make sure you have something heavy to throw.