Zero-Day attacks hit Microsoft Office

Zero-Day attacks hit Microsoft Office

Summary: Certain versions of Microsoft Office are being attacked in the wild via a new remote code execution vulnerability, says Microsoft in a disclosure. Microsoft Lync and some versions of Windows are also vulnerable to it.

TOPICS: Security, Microsoft

[Correction: An earlier headline for this story implied that Microsoft Windows and Lync were also suffering zero day attacks. Some versions of these products have the same vulnerability, but the attacks in the wild have only been observed against Microsoft Office.]

Microsoft today disclosed a vulnerability in the graphics code in certain versions of Windows, Office and Lync. They say they have received reports of targeted attacks in the wild using the vulnerability, specifically against Microsoft Office.

The disclosure includes instructions for various workarounds that users may employ to mitigate against attacks. The workarounds include a "Fix It" link to automate the workarounds.

The affected products are:

  • Windows Vista x86, x64
  • Windows Server 2008 x86, x64, Itanium, Server Core
  • Microsoft Office 2003
  • Microsoft Office 2007
  • Microsoft Office 2010 x86, x64 
  • Microsoft Office Compatibility Pack 
  • Microsoft Lync 2010 x86, x64
  • Microsoft Lync 2010 Attendee
  • Microsoft Lync 2013 x86, x64
  • Microsoft Lync Basic 2013 x86, x64

Of these products, only Lync 2013 is a current version. Windows 7 and 8 and Office 2013 and Office 365 are not affected.

Like almost all such vulnerabilities, this one would only allow remote code execution in the context of the affected user, but such attacks can often be combined with a privilege escalation vulnerability exploit to give administrator privileges to the attacker.

The vulnerability, which was reported to Microsoft by Haifei Li of McAfee Labs IPS Team, is due to a bug in the software's handling of specially-crafted TIFF files. The bug results in memory corruption which may be exploited by the attacker to take control of execution.

The workarounds described by Microsoft involve disabling the TIFF codec and using the Enhanced Mitigation Experience Toolkit (EMET) to block execution in the application. EMET can also be deployed through Group Policy.

Topics: Security, Microsoft

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • make the EMET a standard feature via Windows Update

    Then just push whatever mitigation is necessary at the time.
    • Not ready for that

      "At this time, EMET is only available in the English language. For more information, see Microsoft Knowledge Base Article 2458544."
    • Yes - very surprised MS hasn't done so on their own

      I don't know why EMET is opt-in, instead of opt-out for the apps that don't support it. Windows is quite backward in this regard, as compared to most Linux and BSD distros.
      • EMET, via a GUI, provides hardening beyond the default DEP/ASLR in Windows

        Similar to what PaX does for GNU/Linux:

        How many GNU/Linux distros ship with PaX (which is currently included in grsecurity)? None that I am aware of.

        And grsecurity generally requires one to download the Linux kernel source, the grsecurity patch and apply the grsecurity patch to the kernel. Which means compiling the Linux kernel. Hi, Mr. Davidson [waves].
        Rabid Howler Monkey
        • EMET, via a GUI

          I've investigated EMET a bit in the past, and it looks like something I'd incorporate as a 'best practices', but, have yet to find a proper GUI for it for simplified distribution across an install base of Windows systems. At the risk of sounding lazy, but instead attempting to not reinvent the wheel, is there a sound EMET GUI and starting point default for EMET for Windows that I'm overlooking?
          • Group policy support exists for EMET

            EMET v3, EMET v3.5 tech preview and EMET v4 all support group policy. Here's a link for v4:


            Group policy is discussed towards the bottom of the article.

            Rabid Howler Monkey
          • Thanks.

            That is exactly the article I was hoping for. Much appreciated.
  • microsoft product at risk.... what about office 2000?

    microsoft product at risk.... what about office 2000?
    • It probably is as well

      but they're not supporting Office 2000 at this point.
      Michael Alan Goff
    • It's no longer supported, so...'s not even mentioned. 5 editions and 14 years after Office 2000 was first released, they probably didn't even test it for the vulnerability.
    • 2000

      xD! should probably upgrade.
      Patrick Hopkins
    • Microsoft products at risk..

      And this is news how exactly???
      The Central Scrutinizer
    • For a bit of context...

      The Space Shuttle Columbia disaster occurred 3 or so years after the release of Office 2000. Just to put into perspective the timeframes under consideration.
  • Larry somthing is hosed with the capcha when I try to email you.

    Larry somthing is hosed with the capcha when I try to email you.
  • Does a TIFF file need self-modifying code?

    My thoughts turn to hardware-level capabilities that should be enabled to prevent memory that's not marked executable to get corrupted and result in execution control. While dynamic function pointers are stored in modifiable memory, corrupting them would just cause execution to start somewhere else in the code base which should just crash the app. If the function pointer points to an attack payload that was in the TIFF and loaded into non-executable RAM, the process should be halted. That leaves me thinking the TIFF graphics routines in these products must respond to the dynamics of the graphic by loading and executing extensions or perhaps by leveraging self-modifying code. Still, these should be completely dynamic extensions or self-modifications. How does a compromised TIFF convince the graphics routines to mark non-executable memory as executable before leveraging a corrupt function pointer to pass execution to a potential TIFF payload?
    • Correction...

      ...these SHOULDN'T be completely dynamic extensions or self-modifications... (in other words they should be well-known -- not something where it's possible the TIFF file delivers executable code to the routine which then marks it executable and subsequently executes it)
    • Return oriented programming - Trampoline code

      TIFFs do not contain function pointers. What you Refer to is DEP - which was put in place years ago. Then ASLR was needed because the attackers started using return oriented programming.
      • But ASLR Should Be There...

        ASLR was at least partially enabled as far back as Vista SP1. Although it can be deactivated for greater compatibility, even IE 8 was ASLR compatible and we're long past that version. It's probably a safe bet that most of the more recent products listed as vulnerable are compatible with ASLR. However as with many successful Windows attacks, these protections are disabled for greater backward compatibility or perhaps ignorance of importance (like all logins running with root authority). Of course depending on how random it truly is, ASLR is not a cure all. Windows randomization has been cited as not "random enough".
        • Of course if I would have paid attention...

          It appears Win7/8 are not affected -- perhaps due to ASLR doing it's job.
    • TIFF files...

      ... are not executable. Libraries load them in memory allocated as data and you need a special API to get an meory segment mapped to be executable (this requires some privileges).
      Nothing you'll allocate with a malloc() or new will be executable even if it is used to store functions pointers or virtual method pointers, pointing to executable memory in your program or in a DLL loaded by your program.
      If by accident your pointers are overwritten by flows in your code, they will however possibly cause your program to run in unknown states and behave strangely, calling code that the program should not have used this way. This is the risk, but it will be impossible to execute code in memory segments of your loaded TIFF file.

      So what can be done : tweaking your programs to force it creating local files (for example creating an URL or command file and convince your program to execute these local files. Antivirus kits will detect the unexpected creation of these malicious files through your tweaked program whose security hole was exploited.

      Be careful in your code about the protection of your code when it create local files: it shuld check the location, and the content before. Be even more careful about where these files are located if your program wants to execute them.
      Web browsers for example will create their files by default in their cache while browsing, but in directories which are marked to not contain any files that can be run without your permission. When you download files, they are moved to your Downloads directory but markend as originating from an external domain, so that the OS will ask your permission before allowing you or any application to execute it (this restriction is levied in program installers that can create the files they want where they want, but the downloaded installer itself will not run without your prior permission given (the OS will adk you before it can run).

      Most exploits however are "social" : they promote themselves as goodies for you and attempt to convince you to download programs and excute them. The OS will ask your permission, but you'll give it to the OS.