Slashdot Mirror


Microsoft Responds to WMF Vulnerability

beuges writes "In an entry on the Microsoft Security Response Center Blog, Stephen Toulouse explains exactly how the WMF flaw could be triggered. BetaNews has an overview of the company's response." From the BetaNews article: "This code exists on every version of Windows since version 3.0, security firms have said. When this functionality was introduced, Toulouse said the security landscape differed from what it is now and metafile records were completely trusted by the operating system. Gibson claimed that the flaw could be exploited only by using a byte size of 1 in the metafile record, which Toulouse says is incorrect. He surmised that Gibson's tests had the offending function as the last entry in the metafile, which caused only incorrect sizes to trigger the flaw." We've previous reported on the backdoor claim.

11 of 221 comments (clear)

  1. Every version since 3.0? by Captain_Thunder · · Score: 5, Insightful

    That's quite a long time to have a flaw in your OS. Maybe they should focus more on security rather than a fancy new AeroGlass interface.

    --
    My journal: Clicky. Read it because it
    1. Re:Every version since 3.0? by HugePedlar · · Score: 4, Insightful

      Indeed. Sometimes, late at night, I worry about legacy code. Are we ever going to receive a brand new OS from Microsoft, or will each release merely be an upgrade from older versions?

      I understand the importance of being able to run old programs, but surely Vista could have included a virtual machine or something for XP compatibility - is it really that hard to create a new OS from scratch with proper security etc. as a starting point, not an add-on? Yes it would be a mammoth task, but MS is pretty big, you know.

      I don't know - when you have vulnerable code from Windows 3.1 in your latest release, don't you want to just cut the cord and start again?

      --
      Argh.
    2. Re:Every version since 3.0? by CastrTroy · · Score: 4, Insightful

      Actually, they didn't actually rewrite from scratch. They used BSD, I think. The problem with this, is that if Microsoft chooses something too close to Unix, then it will be easier for people to move away from their operating system. The reason that many people don't switch now, is that moving is very abrupt, and you not only have to change the OS, but many of the applications at the same time. If the OS was unix based, the move could be much more gradual. The funny thing I remember is that the microsoft research lab created an OS that was based on security from the bottom up, and it still ran faster than windows XP. Which I realize isn't that hard, since it's so slow, but shows that you can build a secure OS, that still performs well.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    3. Re:Every version since 3.0? by poot_rootbeer · · Score: 4, Insightful

      Are we ever going to receive a brand new OS from Microsoft, or will each release merely be an upgrade from older versions?

      Did Windows NT 3.1 count, or is it disqualified for inheriting code from VMS and OS/2?

      Linux can trace its kernel lineage back to 1991, and many of its utilities are much much older than that. Are we ever going to receive a brand new OS from Torvalds?

      What's the incentive for anyone to re-invent an operating system from scratch? A desire to create the next BeOS? There's too much collected knowledge in the decades' worth of "legacy" OS code that would be foolish to throw out.

  2. "Landscape has changed" by jav1231 · · Score: 5, Insightful

    I think maybe Windows' landscape has changed but security wasn't so passe' to other software makers. I wonder how much arbitrary code could have been executed by UNIX or even Netware in those days? And I leave open the possibility that it could have. In the long run, this was left uncheck and maybe forgotten for what, 12-15 years now? And more importantly, was brought right into the server code from the desktop code.
    I think therein lies the fundamental problem with Windows and why SA's warned for years about Microsoft's assbackwards approach to security. Windows is at it's heart a desktop OS and as such has a reverse understanding of security.

  3. Re:Ah those were the days. by maxwell+demon · · Score: 3, Insightful
    everyone used telnet and ftp

    I think at that time, the typical protocols for those tasks on a PC were "walk to the computer you want to work on" and "floppy disk". Internet just wasn't that common outside academic institutions.
    And Windows 3.x was single-user anyway (i.e. as soon as you had physical access to a computer, you didn't need to play any tricks with WMF files, you just could put your code in a .COM or .EXE and start it directly).
    --
    The Tao of math: The numbers you can count are not the real numbers.
  4. Re:Inverse security evolution by BoneFlower · · Score: 3, Insightful

    My guess is they redid the printing system, and didn't fully check what other windows systems were affected.

  5. Re:Inverse security evolution by cnettel · · Score: 3, Insightful
    Or even that printing under NT has used different drivers and different stuff in general than 9x. 95 and classic NT device drivers are REALLY different, although 98 and later supported WDM drivers by emulating a (small) subset of the NT kernel.

    Put another way: In NT 4 and later, GDI calls are translated to kernel service calls, in 32-bit. In 9x, it's thunking to a globally mapped 16-bit DLL...

  6. Why XP/2000 and not 9X? by KevinColyer · · Score: 3, Insightful

    I wonder whether the reason the wmf vulnerability was fixed in 9X and then broken in XP/2000 has to do with the way the NT stream was created. If I understand it correctly the initially diverged from Win 3.0. Perhaps the code was "fixed" in 9X but they reverted to the NT core code as the development went on into 2000/XP. I hear a lot about the compartmentalisation at MS.

    I am inclined to believe in incompetence before conspiracy theories... (although incompetence does not leave me all warm and glowy)

  7. Re:MS shooting itself in the foot? by XMilkProject · · Score: 3, Insightful

    Get over yourself.

    And for what it's worth, I don't consider it a bug, or a failure, or anything else like that. It's a feature that was implemented in the format. You should always be careful when running formats that can contain executable code, just as you would with a .exe or .scr file.

    From MSDN:
    A metafile contains records that describe a sequence of application programming interface (API) calls. Metafiles can be recorded (constructed) and played back (displayed).

    A metafile is not a 'graphics format' exactly. It is rather a macro of API calls. Obviously one would suspect that such a thing could be used to execute malicious code.

    --
    Big ones, small ones, some as big as yer 'ead!
    Give 'em a twist, a flick o' the wrist...
  8. Re:Illegal byte size in the metafile record by Jerry+Coffin · · Score: 3, Insightful
    Yeah, so? Most bugs of this kind is triggered by passing "broken" data.

    It's important (from MS' viewpoint) because Gibson used the incorrect data to support a claim that this was an intentional backdoor. Given Gibson's general modus operandi, I'm sure the data being entirely incorrect won't slow him down a bit, but at least anybody with a somewhat unclouded view of reality realizes he was full of nonsense.

    While you can trigger this with broken data, those who RTFA realize that the broken data is entirely incidental.

    --
    The universe is a figment of its own imagination.