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."
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();
Um, depending on what's in the data you overflow into, there's still *potentially* plenty you can do. (They're all very unlikely, but the potential is there.) There's other security-sensitive data besides the return address, and other buffer overflow exploits than overwriting that to jump into malicious code.
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.
This is a heap buffer, assuming TFA's right. What programs execute instructions from the heap and so have the potential to be overwritten by a jump?
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.
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.
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.