Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Windows Operating Systems Software Security IT

Zero Day Exploit Found in Windows Media Player 177

Posted by CowboyNeal from the back-to-old-tricks dept.
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."
This discussion has been archived. No new comments can be posted.

Zero Day Exploit Found in Windows Media Player More

Zero Day Exploit Found in Windows Media Player

Comments Filter:

  • Finding holes in a MS product.... (Score:5, Insightful)

    by TJ_Phazerhacki ( 520002 ) on Thursday December 07, 2006 @10:36PM (#17157732) Journal
    Seems to be a bit like finding holes in swiss chese... inevitable....

  • Another 0-day? (Score:5, Funny)

    by gregleimbeck ( 975759 ) on Thursday December 07, 2006 @10:37PM (#17157738) Homepage
    Must be Thursday.

    • Re: (Score:2, Funny)

      by TheShadowHawk ( 789754 )
      I thought it was Tuesdays, Thursdays and Sundays when holes are found. I guess they are right on track. :P
    • Microsoft could never get the hang of Thursdays.

    • Re: (Score:3, Insightful)

      by h2g2bob ( 948006 )
      Speaking of 0-day, what does 0-day mean, and why is it placed randomly in front of exciting new exploits?

      • Re:Another 0-day? (Score:4, Informative)

        by jfedor ( 27894 ) <jfedor@jfedor.org> on Friday December 08, 2006 @09:06AM (#17161426) Homepage
        It doesn't mean anything (well, except for "unpatched as of yet" or "disclosed in a not-very-responsible way"). In the pirated movies/games community "zero-day" means that the illegal release was done on the same day that the movie was released to theaters or the game was put on shelves in stores. In the security vulnerabilities community the term is used because many people think it sounds like something a hacker would say (a hacker like Angelina Jolie that is).

        -jfedor

      • Speaking of 0-day, what does 0-day mean, and why is it placed randomly in front of exciting new exploits?

        In the case of viruses, it means by the time they know there is a potential exploit, it's out in the wild being a real exploit.

        Contrast this with the kind of exploits which someone say "this is a proof of concept vulnerability", but it's not really a dangerous thing since it only shows how someone could potentially use the exploit.

        Basically, it's real, dangerous, and already happening by the time they kn

    • Oh, So Happy It's Thursday (Score:4, Funny)

      by wowbagger ( 69688 ) on Friday December 08, 2006 @07:36AM (#17160680) Homepage Journal
      Microsoft had two
      Oh
      So
      Happy
      It's
      Thursday
      moments this week so far: Tuesday's 0-day in Word (which has an exploit) and this one Friday (which currently does not have an exploit).

  • How is this dangerous? (Score:4, Interesting)

    by JanusFury ( 452699 ) <.moc.liamg. .ta. .ddag.nivek.> on Thursday December 07, 2006 @10:37PM (#17157742) Homepage Journal
    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?

    • Re: (Score:1, Insightful)

      by Anonymous Coward
      It depends on what 2-4 bytes can be overwritten with this, obviously. It could be anywhere from completely harmless to critically bad, depending.

    • Re:How is this dangerous? (Score:5, Informative)

      by LO0G ( 606364 ) on Thursday December 07, 2006 @11:49PM (#17158330)
      It depends on your heap allocator. IIRC, on the Windows XP heap (without service packs) an application could be owned with just a 1 byte heap overflow (if the phase of the moon was right). On XP SP2's heap it's WAY harder to exploit overflows, because the heap was hardened against this kind of attack. On Vista, it's even harder, the heap was hardened well beyond what was done in XP SP2.

      I have no idea of how exploitable the various *nix or OSX heap implementations are - I'm sure that some are even more exploitable than XP's heap was (the original 4.2 BSD heap was very exploitable, IIRC), and I'm also sure that some of them are hardened as well as Vista's.

      But heap hardening just makes exploitation harder (this is true of ALL defense-in-depth techniques). Even if your platform has a hardened heap and NX protection and stack canaries and ASLR, it's still possible to successfully exploit a vulnerability - it's many many orders of magnitude harder than if those features weren't present, but it's still possible to attack the system.

  • Does Not Affect WMP 11 or Vista (Score:5, Informative)

    by ThinkFr33ly ( 902481 ) on Thursday December 07, 2006 @10:42PM (#17157774)
    FYI, this does not seem to affect Windows Media Player 11, which is available via Windows Update or the WMP site [microsoft.com].

    It also does not affect Vista, both because Vista comes with WMP 11, and thanks to IE7 running in protected mode [microsoft.com]. This would likely cause the browser to crash, however.
    • It's the one where Microsoft decided they will decide when and where and on what devices to allow you to play your media.

      Any bright minds out there that willingly use these things lost control of all of their personal media.
      http://www.microsoft.com/windows/windowsmedia/play er/faq/drm.mspx [microsoft.com]

      http://www.theinquirer.net/default.aspx?article=34 523 [theinquirer.net] is in plain engrish.

      I certainly hope you aren't running either Vista or WMP11.

      • Re: (Score:3, Funny)

        by Propaganda13 ( 312548 )
        Just re-installed Windows on a computer and updated everything except WMP11.

        Don't worry I installed Debian too.

      • Re: (Score:1, Interesting)

        by Anonymous Coward

        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

        • Oh yeah? How about when I rip a CD to HDD and it adds DRM to the files? How about when it doesn't let me watch a cable show (which I bloody payed for already) because it has DRM bits in it that say I can't watch it on my computer? How about not being able to record TV shows for personal use (which is perfectly legal) for the same reason? How about one day a vendor pushes a recall for certain DRM'ed files through a WMP update and I lose the ability to play my own freaking files?

          Yeah, WMP and DRM are really "
          • In WMP11 and previous versions, there is an option to not copy protect music. It's just one checkbox. Or you can not use the WMA format and use mp3 or whatever. Or you can not use WMP at all.

            I have no idea about how DRM in cable works though. I record all my shows using a VCR because it's analog and the shows look warmer than using digital recording.

    • Re: (Score:2)

      by mpe ( 36238 )
      FYI, this does not seem to affect Windows Media Player 11, which is available via Windows Update or the WMP site.

      Problem is that WMP 11 contains even more DRM. DRM adds much more complexity to a media player, including the trusting of external sites.

  • It's not an exploit ... (Score:4, Insightful)

    by jfclavette ( 961511 ) on Thursday December 07, 2006 @10:42PM (#17157790)
    ..., 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.

    • All it takes is a jump instruction. (Score:5, Informative)

      by Anonymous Coward on Thursday December 07, 2006 @11:02PM (#17157962)
      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.

      • Re:All it takes is a jump instruction. (Score:5, Interesting)

        by EvanED ( 569694 ) <evaned@g[ ]l.com ['mai' in gap]> on Thursday December 07, 2006 @11:16PM (#17158062)
        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.

        • 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 jus

      • Re: (Score:2)

        by QuantumG ( 50515 ) *

        x86 processors have a local jump instruction that is 4 bytes long.
        Wow, news to me. Is this just a regular 2 byte branch instruction with two prefixes on it? Or maybe you're thinking of a 5 byte jump instruction.

      • Re: (Score:2, Interesting)

        by tjcrowder ( 899845 )

        And really, getting code loaded like that is not a difficult thing to do.

        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 vu

        • Re: (Score:2)

          by plover ( 150551 ) *

          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

          And it took them until Visual Studio 2005 for them to bite that last bullet. In case you haven't used it yet, they've added a set of "safer" routines to the standard C runtime library. They They are not backward compatible. Now, instead of sprintf(), you call sprintf_s(), which takes the traditional output buffer pointer plus a new parameter indicating the length of the output buffer. It also validates the format string, although if you let the users modify that you'll still have problems (and the do

      • x86 processors have a local jump instruction that is 4 bytes long.

        x86's local jump is two bytes long. One byte for the prefix (74/75 for conditional, EB for unconditional) and one byte for the offset.

  • If it's not dangerous... (Score:3, Insightful)

    by bunbuntheminilop ( 935594 ) on Thursday December 07, 2006 @10:47PM (#17157830)
    as people have commented, then why is it zero day? Doesn't zero day mean there is an exploit already?

  • zero-day exploit (Score:3, Insightful)

    by EvanED ( 569694 ) <evaned@g[ ]l.com ['mai' in gap]> on Thursday December 07, 2006 @10:47PM (#17157834)
    Since when did a "potentially exploitable heap buffer overflow" become a zero-day exploit?

    • Re: (Score:2, Informative)

      by Bargearse ( 68504 )
      When Slashdot get their hands on it :)
      Neither the linked article, or the eEye alert, say that there is an exploit available, just that it's a flaw.

      And eEye somehow missed listing "upgrade to the unaffected WMP11" as a form of mitigation.

    • "Since when did a "potentially exploitable heap buffer overflow" become a zero-day exploit?"

      Happy now :)

      was zero-day exploit (Score:4, lets not talk about the potential flaw)

  • 4 bytes IS ENOUGH (Score:1, Insightful)

    by Anonymous Coward
    for those people that don't understand security or how to exploit a buffer overflow, In many cases 1 byte can be enough, you rewrite a function return address with your own address. That does not mean this is definitely exploitable, but don't let the fact that it is only 4 bytes fool you.

    • Re:4 bytes IS ENOUGH (Score:5, Interesting)

      by EvanED ( 569694 ) <evaned@g[ ]l.com ['mai' in gap]> on Thursday December 07, 2006 @10:55PM (#17157898)
      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.

      • Re:4 bytes IS ENOUGH (Score:5, Interesting)

        by bluefoxlucid ( 723572 ) on Thursday December 07, 2006 @11:35PM (#17158214) Homepage Journal

        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).

        • Re: (Score:1)

          by EvanED ( 569694 )
          I'm not saying that something like this isn't exploitable, I'm just saying that the chance is extremely low.

          For your plan to work:
          1. The following memory would likely have to be deallocated (this depends on the malloc implementation, but assuming that it keeps track of a free list, the block that you corrupt would have to be deallocated before that address was used for anything), so the following would have to be done at the first allocation following this deallocation
          2. You would have to be able to determi

  • Hmm... (Score:4, Funny)

    by Anonymous Coward on Thursday December 07, 2006 @10:59PM (#17157942)
    Nah. [imageshack.us]

  • GG Misleading Post (Score:5, Insightful)

    by PixieDust ( 971386 ) on Thursday December 07, 2006 @11:17PM (#17158068)
    Ok, so this flaw is there. It's a bug.

    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.

    • Re: (Score:2)

      by lahvak ( 69490 )
      4 bytes are more than enough. All you need to do is load your program into that buffer, and put a jump instruction to the entry point of the program (if you are overwriting executable code) or simply the address of the entry point (if you manage to overwrite a function return address). It seems that in this case, the memory being on the heap, it's none of those two cases, on the other hand, from my pld days of programming in assembly under DOS, we did all sorts of tricks with allocating memory, loading in

    • Slight difference (Score:5, Insightful)

      by ZxCv ( 6138 ) on Friday December 08, 2006 @03:01AM (#17159458) Homepage
      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.
    • Not a broken Linux, but a broken Apple;

      http://news.com.com/MySpace+to+Apple+Fix+that+worm /2100-7349_3-6141031.html [com.com]

      Reported to slashdot 3 days ago, story accepted, never published.

      You are soo correct, if it is Microsoft it is critical news. If it is anyone else, it's covered up.

      • Re: (Score:2)

        by jZnat ( 793348 ) *
        It was probably rejected because nobody at Slashdot cares about MySpace in the slightest.
    • What exactly is misleading about the post. Is there *not* a zero day bug in Windows Media player. Does it not relate to WMVCORE.DLL.

      "Doesn't affect my Vista machine. Nor my XP Pro machine running IE7 + WMP 11"

      What version of WMVCORE.DLL does WMP 11 use and is there a security advisory saying XP is not affected.

      ""the function at 7D7A8F27 in WMVCORE.DLL version 9.0.0.3250, and at 086E586E in WMVCORE.DLL [intelliadmin.com] version 10.0.0.3802"

      ""I can't help but wonder what it might look like if every time a flaw wa

  • No plans to fix the Word flaw (Score:5, Interesting)

    by jginspace ( 678908 ) <jginspace@nosPam.yahoo.com> on Thursday December 07, 2006 @11:44PM (#17158300) Homepage Journal
    Microsoft have just given advance notification [microsoft.com] 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.

  • It could be fixed already (Score:4, Funny)

    by Anonymous Coward on Thursday December 07, 2006 @11:45PM (#17158304)
    But it is not a flaw in the DRM, ao why ahould Microsoft care?
  • From the article:

    Exploitability due to the corruption of the adjacent heap block's header is assumed likely but research is ongoing.

    It's "likely"?

    That sounds to me like something could *potentially* happen, but they haven't been able to actually prove it yet. And, the date on this discovery (according to the source article) was over two weeks ago. By now, wouldn't they have concluded something with their research?

    The company does, however, sell a product to help mitigate "issues" like this.. which they link to at the bottom of their article.

    • Re: (Score:2)

      by EvanED ( 569694 )
      That sounds to me like something could *potentially* happen, but they haven't been able to actually prove it yet. And, the date on this discovery (according to the source article) was over two weeks ago. By now, wouldn't they have concluded something with their research?

      No... not at all. They're just very liberal with their definition of "zero-day"...
    • It seems that eEye are only linking to the '0-day' (for loose definitions of 0-day) vulnerabilities that their products can detect and protect against. There are many, many more 0-days that are out there, including an .asx 0-day (a true 0-day) which is more serious than this, and older as well. The only difference is that it doesn't target WMP.

      The recent coverage of ASX Playlist issues in various security mailing lists and forums seems somewhat strange. For the uninitiated, here is a quick wrapup:

      XMPlay
  • 4 bytes should be enough for anybody

  • Is it just me, or did these "zero day exploits" suddenly come out of nowhere?

    We used to hear about all kinds of interesting security vulnerabilities, flaws, buffer overruns, etc. Did someone reclassify everything as a "zero day exploit"?

  • Zero-day exploit (Score:4, Funny)

    by Schraegstrichpunkt ( 931443 ) on Friday December 08, 2006 @01:24AM (#17158986) Homepage
    Was a new version of Windows Media Player released today or something?
  • wtf, where's the exploit??? This is just an announcement of a weakness... TFA calls it a Zero-Day Flaw...
    • The recent coverage of ASX Playlist issues seems somewhat strange. For the uninitiated, here is a quick wrapup:

      XMPlay ASX buffer overflow PoC code posted to milw0rm - 21 November

      This PoC demonstrated an exploitable buffer overflow condition in the handling of 'ref href' URIs. A CVE entry (CVE-2006-6063 - though this only identifies the .m3u method of exploiting the vulnerability) appears around the same time, and reporting is carried by the usual third parties. With no fix present, this remains an effect

  • VideoLAN - VLC Media Player [videolan.org] is an all-in-one open source and cross platform program which does much more than WMP: it's an user-friendly player, but also a powerful and flexible transcoder for almost every audio/video format and even a stream server supporting various network protocols.

    Worth a try as a better replacement, especially for power users.

  • So, I can't open Word files because of an unfixed risk, and I can't open sound files because of an unfixed risk. Wonderful if you're running the average business..

    After switching to OpenOffice and VideoLAN, I guess the leap to Linux isn't that far if it wasn't for the fact that you'd have to switch a whole infrastructure and find a new support environment. Not that easy, but more and more attractive, and it appears to have an ever improving ROI...

  • Fix (Score:2)

    by pe1chl ( 90186 )
    Maybe instead of (or in addition to) fixing things like this, they should distribute a tutorial on how to setup the system to use less-privileged users instead of being logged in as Admin all the time.

    Also, they should more actively spread bad press about companies that release products that require administrator rights to be used.
    Those companies should be pointed out as part of the reason for security problems and hacked systems.
  • Again, please please please let's all stop using C and use an alternative like Ada, Cyclone or D!

    And no, this is no troll, it's reality: with a language like C, problems like buffer overflows are very easy to do...

    At this day an age, a buffer length check is not a serious hit on performance!
  • It's lame that something like this makes the front page. The report [eeye.com] makes no mention of version, no proof of concept code is available. Ah but they DO try to sell your their security application which supposedly protects from this vulnerability.

    • Re: (Score:2)

      by figleaf ( 672550 )
      It does mention the file versions. From the fileversions you can determine that WMP9 & WMP10 can "supposedly" be exploited.
      WMP11 doesn't have the issue.
  • Use WINAMP!

    The new versions of Winamp will play any file that WMP Plays. That, combined with WMP Classic, QT Alternative, Real Alternative, and The Matroska codecs and I'm all set. Heck, my XP box is still running WMP 9! I just dissassociate it with all files, and then stop using it. I never need to touch it again after that.

    My Ubuntu box will also play any of the above thanks to Easy Ubuntu. I just loaded up what I wanted, and away I go. (although I wish Amarok was available for the Gnome interface.
  • Is it just me or does anyone else wonder why a MEDIA PLAYER is even exploitable? Why is it so hard to secure an application that plays/views data files. Can't you build in some limitations to prevent this problem? I mean, after all, it's nothing more than a "viewer" of data files (streamed or local). MSFT continues to add "functionality" to it's media player and now they are reaping what they sow. Media players don't need scripting and all the other "functionality" MSFT *thinks* we need. Just pla
  • Well, for Word, they suggested not opening or saving Word documents.

    That's one app down.

    I suppose for the Player, they suggest...not playing anything.

    Another app down.

    What's left? Excel? Access? We already KNOW Outlook Express and Outlook and IE are toast on a daily basis.

    And corporations still USE this crap?

    Suckers.

Slashdot Top Deals

To be awake is to be alive. -- Henry David Thoreau, in "Walden"

Close