January 4, 2011

Microsoft today warned Windows users about a previously unknown security vulnerability that could allow attackers to install malware simply by getting users to view a malicious image in a Web browser or document.

Microsoft said in a security advisory that the problem stems from a bug in the Windows Graphics Rendering Engine on Vista, Server 2003, and Windows XP. The software giant said that it is working on a patch for the flaw, but that it isn’t aware of any active attacks exploiting the security hole…yet.

According to the CVE listing cited in the advisory, the vulnerability was discovered by a pair of security researchers who presented their findings at a security conference in Korea late last year.

Microsoft has made available a “FixIt” tool to blunt the threat of attacks against the flaw until the company can issue a proper patch. To apply this fix, visit this link and click the “Fix it” icon in the box under the “Enable” heading. If for some reason the Fix it tool doesn’t play nice with your system, you can always reverse the change by re-visiting that page and clicking the icon under the “Disable” heading.

Microsoft released a record number of security updates last year, and at the rate that new Windows flaws are being discovered and disclosed, the company is likely to set new records again in 2011. Over the weekend, security researcher Michael Zalewski, a Google employee, released details about a previously unreported flaw in Internet Explorer. Zalewski said he released the information after learning that details of the flaw had accidentally been indexed by Google’s search bots, and subsequently downloaded by someone using a Chinese Internet address.

Patch Tuesday is next week, and it will be interesting to see whether Microsoft addresses another outstanding vulnerability in IE: Two days before Christmas, Microsoft warned that hackers were likely to begin exploiting a flaw present in all versions of IE, using a widely publicized method of attack that evades two of the key security defenses built in Windows 7 and Windows Vista.

Update, Jan. 5, 5:45 p.m. ET: Added a link to the Fix It tool.

25 thoughts on “Microsoft Warns of Image Problem

  1. Russ

    A missing piece in the link to Microsoft’s bulletin is where the payload comes from. Over and over it repeats “execute code in the security context of the logged-on user” but that is only part of the issue. I want to know if the malicious code is embedded in the malicious image itself somehow (I can start tracking image filesizes), if it must be included as a separate file (does viewing a malicious pic in the spam automatically execute attached .js or .exe, because those attachments are easily blocked), or does it call collect to homebase and retrieve the Trojan (or whatever) from the Internet? Are all three things possible, and more?

    Using my imagination, I think the biggest avenue of attack will be malicious ads that use these crafted images to force malware onto machines without the user realizing the true nature of the infection.

    [dons tinfoil hat]
    Perhaps even now the banner ad under Brian’s headshot could be quietly installing a keystroke logger! Who would be the wiser?
    [tinfoil hat removed]

    1. Thomas Milne

      [borrows tinfoil hat]
      Forget Firefox vs IE- it’s time to switch to Lynx!!!

      1. Rabid Howler Monkey

        Although humorous, this is the proper line of thinking. How might a user encounter a maliciously formed image? A malicious advert on a legitimate web page. An email attachment, and not just standalone images, or an inline image if one views their email as html.

        How would one defend against such an exploit without using one-time solutions such as modifying the ACL for a specific dll file? Or using Lynx, Links or Elinks. ๐Ÿ™‚ Through virtualization (or sandboxing) of some sort.

        A poster below mentioned the Coyotos project. This will lead to EROS and CapROS. These projects appear either to have stalled or died on the vine.

        Here’s my 2 cents on an up-and-coming operating system designed with security in mind, Qubes OS. Not a Linux distro, but a Xen distro. And it’s open-source. By the Invisible Things Lab. Remember the Blue Pill? It’s currently in alpha, but is moving along towards a beta release. Some links:



        Just note that your processor will need to support hardware virtualization in order to run Qubes.

    2. Silemess

      I’m inclined to agree that the mitigating factors and suggested work arounds are rather vague. If we’re at risk on the web from specially crafted websites, does it matter what browser we’re using?

      I have to assume that FTP leaves you vulnerable as you might pick up the file and its thumbnail to bring it home to share on the network, instead of just hitting your computer. Fortunately, we don’t go poking into unknown servers, but how long before some of these compromised machines are used to leverage the most out of this vulnerability.

      1. InfoSec Pro

        doesn’t matter what browser, this in Microsoft’s code. The PoC used MS tools but that was to make it easier to get around DEP etc. It seems to me there’s a fairly good chance the same vuln could be exploited on other browsers just not as easily. It is possible that other browsers might have defenses that would be effective against it, but that is not certain. Bet your system on that if you so choose, depends on how specifically targeted you are. Where I sit we can’t depend on it.

        1. InfoSec Pro

          to clarify, when I said “protecting against it” I meant blocking exploits, not curing the vuln. Think of it as maybe having a better DEP or an effective sandbox (something like Adobe X is supposed to be).

  2. BuddhaChu

    After reading the article’s title, I thought Microsoft was worried about *its* image.

    I see what you did there Mr. Krebs. Well played sir! ๐Ÿ˜‰

  3. John Budda

    After reading the articleโ€™s title, I thought Microsoft was worried about *its* image.

    I see what you did there Mr. Krebs. Well played sir! ๐Ÿ˜‰

  4. Michael Kingsford Gray

    Well, that’s what any company deserves for writing code in a language that allows untrapped memory overflows.
    We see it again, and again, and again.
    Code written in C or C++ for operating systems should be illegal.

    1. Dominic

      So that rules out Windows by your own admission. It also rules out any linux distributions because the kernel is written in C, the command shell in bash, the GUI in C or C++. You need to distinguish between the underlying system and the packages installed on top of it to find much written in other languages. If you’re lucky you might find some Python kicking around.
      Can anyone shed any light on the underlying language used to create OSX?

      1. wiredog

        Since OSX is BSD, which is Unix, the kernel is probably written in C, or some variant of it.

        1. Scott D

          I wonder if Apple does the ‘dog food’ experiment?

          They do have their ‘own’ development tools and push Objective C on their developer crowd. They have used their development resources to further LLVM .

          One of the keys to kernel security is not the language, but the library of system routines (in the Windoze world this equates to the dreaded DLL mess). While DEP and ASLR are ‘foundational’ items you really also have to modify the core string handling routines used in the kernel and key system components. Apple could likely make a huge jump in kernel security by recoding string handling functions, as part of a kernel code audit, to avoid buffer overflows (not trying to negate their impact after the fact with ASLR/DEP ).

          Yes, I am speaking from a ‘familiarity’ of the OpenBSD perspective.

          This thread makes the key point that secure systems have to built upon a base of development tools and philosophies that cause robust code to be generated.

          The OpenBSD devs went as far as to fork GCC (the most pervasive compiler tool in the open source world – all Linux distros are built with/by it) to add ASLR/DEP equivalents (credit to IBM here, it was their ProPolice research that led to this work) ….years, perhaps over a decade ago in parallel to redeveloping the string handling functions.

          The other key phrase in the above vulnerability discussion is ‘executed with the privileges of the logged on user’.

          Microsoft has a very ‘grainy’ user/priv model and it very hard, neigh impossible, to use a priv-sep model in the DLL environment.

          If you look under the hood in Mac OS X you will see that Apple has been adding ‘unprivileged’ user/group ids (ie NOT root or in Windoze: administrator) that are used by the various background processes (open up terminal and cat /etc/passwd — not so dangerous as the file is not actually used any more – Apple has directory-a-fied everything). Note all of the ids that are ‘_’ (underscore prefixed). This effectively reduces the files that these processes can modify to those in the same group/user id. Radically different than the situation in Windows with the svchost ‘processes’.

          Yes, sorry, but again the OpenBSD devs applied this same approach …years ago.

          The sandboxing that Google has recently ‘done’ for Adobe (talk about poor software dev tools/practices!) is also an echo of what is known as a chroot jail in the Unix/Linux/BSD world. This, again, is something that was employed in the OpenBSD world long, long ago.

          The reality is that MS Office doesn’t run on OpenBSD. Damn…..

          1. Rabid Howler Monkey

            It’s not just the lack of MS Office or other popular ISV software that keeps many users away from OpenBSD.

            OpenBSD kernel updates, although they occur much less frequently than in Windows or Linux, require the user to download a patch to a specific directory where the kernel is rebuilt via the CLI. And this assumes that he/she gets past the OpenBSD install where he/she is dropped into a root terminal window and must use the CLI to create a non-root user …

            OpenBSD is indeed the most rock-solid OS available today. And didn’t they also harden X.org? The user, however, must be very CLI savvy.

      1. Dominic

        Writing in assembler doesn’t negate the ability to have bad code.

        1. Bob

          Sorry forgot the tags!! But surely it’s obvious that a modern OS multi-Mb kernel couldn’t be completely written in Assembler. Nightmare to maintain!

          Most Higher Level languages don’t have the performance needed and their interpretors/compilers were probably written as C++/C program in the first place (ahhh.. recursion)! The Linux kernel has to be written in C to get access to low-level hardware and for performance (I gather even C++ – without legacy C code tags – wouldn’t cut the mustard).

          1. Steve

            That’s the reason why the first thing that the coyotos (coyotos.org) team did was design a system programming language (BitC) about which formal reasoning could be applied.

    1. Nogero

      Virtually all operating systems are written in C, or use a platform descendant from C.

  5. John

    How MANY TIMES will MSFT re-use this very same vulnerability?

    How comes security experts do not remember how old it is?

    When will be such obvious backdoor system be considered unlawful?

Comments are closed.