Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Windows Operating Systems Software Bug Programming IT Technology

Microsoft Responds to WMF Vulnerability 221

Posted by Zonk from the not-intentional dept.
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.
This discussion has been archived. No new comments can be posted.

Microsoft Responds to WMF Vulnerability More

Microsoft Responds to WMF Vulnerability

Comments Filter:

  • Every version since 3.0? (Score:5, Insightful)

    by Captain_Thunder ( 937821 ) on Monday January 16, 2006 @08:37AM (#14480921) Homepage Journal
    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.

    • Re:Every version since 3.0? (Score:5, Interesting)

      by Shano ( 179535 ) on Monday January 16, 2006 @08:45AM (#14480951)

      The WMF vulnerability isn't a programming flaw, it's a problem with the original spec. The code may have been rewritten many times, and the potential for damage never noticed. Indeed, the WINE people did reimplement it, complete with the vulnerability.

      While it seems obvious that allowing arbitrary code to execute, it is clearly sufficiently non-obvious that a flaw in a well-documented spec went unnoticed for more than 10 years.

      What's most likely is that security wasn't a big thing when the spec was written (this much we know), and the WMF code was never audited because is "obviously" isn't related to security. After all, nobody uses it any more, WMF isn't used much on the web, and it's "just" an image format.

      I would be worried about how many similar flaws may exist. I'm willing to forgive them for missing this one (and I'm not a Windows user), but if it doesn't lead to a proper audit of legacy APIs, the next time around they deserve everything they get.

      • Re:Every version since 3.0? (Score:5, Funny)

        by tpgp ( 48001 ) on Monday January 16, 2006 @09:11AM (#14481067) Homepage
        Indeed, the WINE people did reimplement it, complete with the vulnerability.

        Yep - the WINE people are reimplementing the windows API bug-for-bug ;-)
        • Yep - the WINE people are reimplementing the windows API bug-for-bug ;-)

          Otherwise sotware would not crash as expected.

          • Yep - the WINE people are reimplementing the windows API bug-for-bug ;-)

            Otherwise sotware would not crash as expected.

            Actually, that's been incredibly useful for me: I don't have any Windows machines, but I (admittedly haphazardly) maintain a Win32 port of some software.

            This has helped me find bugs in Microsoft's own implementation of Win32- or if you'd prefer, bugs in the MSDN documentation.

            The WINE people have spent a considerable amount of time inspecting Win32 function calls- more time I'm sure than Mi

      • This "feature" points to a fundamental flaw in Windows that is really impossible to fix without a complete re-write of the OS.

        Windows was designed as a stand alone OS without network connections so it is full of problems like this. They are fundamental to the architecture.

        OTOH, the *nix OSs were designed from the start for a network environment with appropriate security.

        Windows will never be ready for the net without a complete re-write.

      • The design specification has to have been reviewed and revised many times as Windows advanced through Win3.0, Win95, Win98, etc, to Vista. While I can see that a subtle undocumented bug buried in legacy code could have survived through these changes, I find it really hard to understand how something dangerous in the highly visible design specification documents could have survived these multiple periods of intense scrutiny. The only possibilities I can think of is that either Microsoft deliberately avoided

        • Would one of the Microsoft minions want to explain how anything other than criminal negligence or conspiracy to defraud customers could have allowed this exploit to be carried forward-- and amplified-- through so many major reviews and revisions of the design specifications?

          I am not a Microsoft minion, but if I were, I'd propably be more worried with the endless task of trying to stop IE and Outlook from executing everything they happen to come accross in the Internet, rather than the possibility that t

    • Re:Every version since 3.0? (Score:5, Insightful)

      by HugePedlar ( 900427 ) on Monday January 16, 2006 @08:46AM (#14480957) Homepage
      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?
      • Indeed. Sometimes, late at night, I worry about legacy code

        That's what you worry about at night? I tend to worry about whether or not I've held her long enough that I can get out of bed and leave.

      • Re:Every version since 3.0? (Score:5, Insightful)

        by poot_rootbeer ( 188613 ) on Monday January 16, 2006 @01:16PM (#14482883)
        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.
    • You're absolutely right, they should have held off releasing Windows 3.1 until it was thoroughly beta and security tested. Hell, if they did that, Linux wouldn't be 10 years behind.
    • Wrong!! RTFA! It was 'WMF Support' that was introduced in Windows 3.0. The 'vulnerability' didn't come (according to Microsoft) [technet.com] until "...all that GDI functionality was allowed to be called from metafiles." There is nothing inherently insecure about a .wmf file, it is the *way* that the records in it are processed in Windows XP that creates the vulnerability.

      You can rest easy with your Windows 3.0 as it is is secure against the .wmf security access.
    • Maybe they should focus more on security rather than a fancy new AeroGlass interface. ...because UI design experience and artistic ability are all you need to carry out security research and code audits!

  • Ah those were the days. (Score:5, Funny)

    by DrSkwid ( 118965 ) on Monday January 16, 2006 @08:39AM (#14480931) Journal
    > metafile records were completely trusted by the operating system

    when there were no disgruntled employees and no spies (international or industrial)

    everyone used telnet and ftp

    and there was no user 0

    • Re:Ah those were the days. (Score:4, Insightful)

      by maxwell demon ( 590494 ) on Monday January 16, 2006 @09:03AM (#14481031) Journal
      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).
      • You are forgetting 1 significant product :

        Novell Netware
        • This reminds me of how "aware" of TCP/IP networking Microsoft was. They didn't own their own TCP/IP stack until sometime around the early to mid 1990's. It was 1992( IIRC ) that I had an AMD based 386/40 with 10MB of RAM running on a companys TCP/IP and Novell networks. The OS on this PC was IBMs OS/2 and I used it for email, filesharing, backups, development, and to keep me from having to run to the labs Sun computers( via the PMX Xserver ).

          ya, nobody did networking or worried about network security in THO

  • Why does Windows have so much legacy? (Score:5, Interesting)

    by antifoidulus ( 807088 ) on Monday January 16, 2006 @08:45AM (#14480955) Homepage Journal
    Windows 3.0?! Ok, if it was a problem back then, why didn't it get fixed when the security environment changed? Windows has too much of a legacy going for it, and I'm surprised they held on to it this long. Apple realized that it's legacy code was no good years ago and succesfully ditched it in favor of something more modern, why can't windows do the same?

    • Re:Why does Windows have so much legacy? (Score:5, Funny)

      by heavy snowfall ( 847023 ) on Monday January 16, 2006 @08:53AM (#14480984) Journal
      More importantly: when is the patch for 3.1 and MS Bob coming out?
    • "Apple realized that it's legacy code was no good years ago and succesfully ditched it in favor of something more modern"

      No. Apple ditched their code in favor of something that predates Windows.

      • "Apple realized that it's legacy code was no good years ago and succesfully ditched it in favor of something more modern"

        No. Apple ditched their code in favor of something that predates Windows.

        Those two statements don't contradict each other. Just because something was produced later doesn't mean it's more modern. A newly made horse carriage is less modern than a 50 years old car.

    • Re:Why does Windows have so much legacy? (Score:5, Informative)

      by IamTheRealMike ( 537420 ) on Monday January 16, 2006 @09:48AM (#14481256)
      Windows 3.0?! Ok, if it was a problem back then, why didn't it get fixed when the security environment changed?

      There are a large number of 16 bit (ie Win3.0/3.1) apps out there that are still in industrial use. They tend to be obscure things - applications for subtitling TV transmissions, interfacing to medical kit etc. Although it may be hard for you to believe there are no apps out there more than 10 years old in fact there are, and often the computers these apps run on are upgraded to new versions of Windows as time goes by (because it'd be a huge pain to have like 8 versions of Windows in use in a single organisation).

      Fixing this flaw does in fact break backwards compatibility, and that means somewhere some random app we've never heard is is broken right about now - of this I am almost certain. That has a cost, and nobody wants to break peoples apps and cause network admins headaches without good reason.

      Apple realized that it's legacy code was no good years ago and succesfully ditched it in favor of something more modern, why can't windows do the same?

      Apple did no such thing - they maintained a compatibility mode in the OS and more importantly kept the Carbon APIs around mostly complete so legacy code could be ported over very easily. And of course, Apple had hardly any mission-critical apps running on their platform anyway so the pain and cost was much less than it would be for Microsoft.

      In fact, Windows does run Windows 3.1 apps in a VM type process these days, it's called a WoW (Windows on Windows) VM, but the integration is so tight most users never even realise it. Except for looking a bit dated the apps continue to run correctly and appear on the same desktop etc. In other words, Microsoft already did what you asked for!

      Now it didn't mitigate this vulnerability, because the Microsoft developers who wrote the Windows Image/Fax viewer wanted to support every file format they could, and when supporting WMF was so easy why not do it? They unfortunately didn't get the memo about this being a potential attack vector: this is a failure of corporate communications, and perhaps over-zealous developers, not a failure of operating system design.

      As an interesting historical aside, Raymond Chen has said that back in the early days of the Windows 95 project there were in fact two competing approaches to 3.1 compatibility: a VMware type approach where the 16 bit environment ran inside a window box that was in turn running a copy of Windows 3.1 .... and the approach they actually ended up using which was based on API thunks. The thunk approach was more complex but had much better integration, much lower resource usage (not running two operating systems on top of each other) and in usability tests came out on top every time. Everybody who tried the tight integration approach preferred it, and MS management felt they couldn't ask users to put up with a very jarring experience - potentially forever, in the case of apps that'd never be ported to Win32.

      • > Fixing this flaw does in fact break backwards compatibility, and that means somewhere some random app we've never heard is is broken right about now - of this I am almost certain

        A worldwide botnet that cripples the Internet is the potential price to pay for (ass-) backwards compatibility? No fucking thanks. Hint: if you want real backwards compatibility, release the source. Then it's a small matter of changing a few lines when your critical functionality becomes a virus infection vector.
      • You all do realize that Gibson found the flaw in Windows 2000, not Windows 3.0?

        Microsoft said that the flaw DATES from Windows 3.0, and is present in all versions since then.

        NOT JUST WINDOWS 3.0! (Sheesh!!!)
        • You all do realize that Gibson found the flaw in Windows 2000, not Windows 3.0?

          Please read comments before you respond to them. For instance, the following things were mentioned in the article that are newer than Windows 3.0:

          1. Windows 3.1
          2. Windows 95
          3. "Windows Image/Fax viewer" AKA Microsoft Picture and Fax Viewer, introduced in Windows XP
      • There are a large number of 16 bit (ie Win3.0/3.1) apps out there that are still in industrial use. They tend to be obscure things - applications for subtitling TV transmissions, interfacing to medical kit etc.
        i'd imagine a great many of those are unlikely to run on the NT lineage (reliance on direct hardware access etc) and they probablly run on dedicated pcs anyway.

        still its a good indication on why you should require source for anything you rely on that isn't well supported off the shelf software.
      • In fact, Windows does run Windows 3.1 apps in a VM type process these days, it's called a WoW (Windows on Windows) VM

        So that's what the "wow" in wowexec means . . . and here I always thought it was some overworked coder saying "wow, we actually managed to get this ancient crapola working". You learn something new every day!

      • Part of the design for how Windows95 ran Windows3.x code probably had to do with how the competition ran that code. For instance, IBM was selling a million copies a month of 32bit OS/2 when Windows95 was finally released and OS/2 was a major threat during the formative years of Chicago. Running those old apps in a VM like OS/2 did, resulted in two different look/feels and really made the old Windows3.x stuff seem old and outdated to the user. Microsoft needed users to THINK they had a new system even when r
    • Windows has too much of a legacy going for it, and I'm surprised they held on to it this long. Apple realized that it's legacy code was no good years ago and succesfully ditched it in favor of something more modern, why can't windows do the same?

      Apple?! With all due respect to Apple fans, their market share is insignificant next to Windows. There are tons of manufacturing and industrial shops using software running on Windows 3.1, DOS, OS/2, OS/9000 and other "legacy" operating systems.

      Apple's segment of

  • Security a top priority since 2002 (Score:4, Informative)

    by sl4shd0rk ( 755837 ) on Monday January 16, 2006 @08:51AM (#14480975)
    It's nice to know they are taking such a proactive stance on the issue of security. http://news.com.com/2100-1001-816880.html [com.com]

  • Inverse security evolution (Score:5, Interesting)

    by maxwell demon ( 590494 ) on Monday January 16, 2006 @08:53AM (#14480987) Journal
    An interesting quote from the first link:

    With WMF we want to be very clear: the Windows 9x platform is not vulnerable to any "Critical" attack vector. The reason Windows 9x is not vulnerable to a "Critical" attack vector is because an additional step exists in the Win9x platform: When not printing to a printer, applications will simply never process the SetAbortProc record.

    Which makes me wonder, why on earth did they remove that security measure in later versions of Windows?

    • Re:Inverse security evolution (Score:4, Insightful)

      by BoneFlower ( 107640 ) <anniethebruce@ g m a i l . c om> on Monday January 16, 2006 @09:10AM (#14481065) Journal
      My guess is they redid the printing system, and didn't fully check what other windows systems were affected.

      • Re:Inverse security evolution (Score:4, Insightful)

        by cnettel ( 836611 ) on Monday January 16, 2006 @09:28AM (#14481130)
        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...

    • They didn't remove it, it was just never added to the new program (windows printer and fax viewer) when it was written. If this was there as a fix in win9x then this shows why it's important to update specifications with security fixes, but it could just as easily be different application writers taking different approaches and one of them incidentally fixing the flaw.
    • Windows 2k, XP, 2k3 are all NT derivatives. 95/98/ME came from the 95 code base. The people responsible for 95 were completely seperate from the people responcible for NT.

      -Rick
    • Remember, Microsoft ONLY considers a security issue CRITICAL when it can automatically propogate on a network. So, because a dialog box will pop up when this flaw is activated means that it is not automatic and therefore not CRITICAL in their eyes. How convenient for them.

      LoB

  • Odd thing to introduce... (Score:5, Interesting)

    by makomk ( 752139 ) on Monday January 16, 2006 @08:58AM (#14481003) Journal
    Seeing as I didn't get an answer last time (probably posted too late), I'll re-post my response [slashdot.org] when this was linked to in a comment in a previous article:

    Interesting - according to the article, Win95/98/ME don't actually run the hook set via SetAbortProc when rendering a metafile (unless you're printing it and the print job is aborted), but some change was introduced in 2000/XP such that it was called after the next metafile record is processed (which is an *extremely* odd thing for Windows to do, considering what SetAbortProc was designed to do). This seems to fit with what people are reporting (and explains why the Metasploit exploit, which adds leading and trailing records, works).

    Maybe Gibson was accidentally on the mark about it being an intentional backdoor. After all, that's about the same time a vulnerable program able to display metafiles was introduced and bundled with Windows (was that in 2000 or XP?).
    • I haven't seen any evidence thus far that a change was introduced in 2000/XP. So far, everything suggests that it's always been in the NT 3.1 line.

      What "saved" windows 9x is that it was a completely different code-base from NT (derived from Win3.x); it was likely altered independently by the 9x product team. But because of the separate code-bases there was no cross-pollination of this change to the NT line. Presumably the recent patch implements an equivalent fix (so that SetAbortProc is only handled whe
    • Nice try, sorry. The WMF implementation change was in Windows 2000, but the Windows Picture and Fax Viewer came in with Windows XP. Windows 2000 by default has no program associated with WMF.

      The Toulouse blog basically proves, as if it weren't obvious, that Gibson is full of crap.

  • Source code leak? (Score:3, Interesting)

    by erroneus ( 253617 ) on Monday January 16, 2006 @08:58AM (#14481006) Homepage
    Has anyone looked at the leaked source code to determine anything from the code written there? I've never actually seen or possessed the code and I wouldn't know where to look even if I did. But I'm sure SOMEONE out there still has it and so I wonder if anyone has examined the source to see if anything interesting appears there?

  • What I found interesting was this quote:

    The reason Windows 9x is not vulnerable to a "Critical" attack vector is because an additional step exists in the Win9x platform: When not printing to a printer, applications will simply never process the SetAbortProc record. Although the vulnerable code does exist in the Win9x platform, all "Critical" attack vectors are blocked by this additional step.

    Well, that explains (sort of) why they didn't feel obligated to update the 9x series, but it lacks a great d

  • "Landscape has changed" (Score:5, Insightful)

    by jav1231 ( 539129 ) on Monday January 16, 2006 @09:01AM (#14481019)
    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.
    • Yup, Windows is a desktop OS that people pretend is a server OS.

      Sure, MS *could* make Windows into a real server OS, but it would require some pretty substantial changes that would alienate their entire click-and-drool sysadmin community. (Not saying all Windows sysadmins are the click-and-drool type, but probably a very large percentage probably are.)
    • Windows was a desktop operating system, and generally they must be able to do many things rather unlike the equivalent server OS which must be able to do only one or two things but very well.

      If you want to compare like with like, you must check Windows against MacOS. Both MacOS Classic and OS X have a very poor track record of security: there have been multiple instant code execution exploits for OS X that can be triggered via a web browser in brand new code, not stuff that was written decades ago. Worse,

      • Citations, please. There hasn't been any virus or trojan exploit in OS X since its inception. Even army.mil is hosted on OS X Server.

        I'm always hearing from random people who say "Oh, it's quite easy to write OS X spyware." Yet we never, ever see it.

    • Re:"Landscape has changed" (Score:5, Informative)

      by multipartmixed ( 163409 ) on Monday January 16, 2006 @10:55AM (#14481692) Homepage
      > I wonder how much arbitrary code could have been executed by UNIX
      > or even Netware in those days?

      Plenty. At one point, it was possible to hack a Sun box running sendmail using nothing more than telnet.

      Yeah, baby, a root shell prompt without even logging. Now THAT was scary.

      • Ah yes, the DEBUG mode in sendmail. I remember it well, since I spent an entire day patching sendmail from various vendors during the Robert Morris, Jr. Internet worm.

        I know there have been lots of other unpleasant security issues with sendmail over the years. However, that particular one could have been completely avoided if the people releasing binary copies of sendmail had read the Makefile.

        Also, another point needs to be made. Sendmail is not a part of the UNIX OS. It is an additional program

    • The "Landscape has changed" reference in the /. article is a bit of a misrepresentation of the Toulouse reference.

      The real point was that this was still the era of non-preemptive (cooperative) multitasking among Windows applications. The point of having a callback was that it was the only way to cancel a print job was through a callback. So there was a reason for having this design, even if it was long-term-stupid.
    • I wonder how much arbitrary code could have been executed by UNIX

      Heh, you don't remember sendmail or BIND do you?

      Of course, the Sendmail and ISC groups appear to have the mind-think of Microsoft, so maybe this isn't really a jab at UNIX, but simply at people who used these pieces of junk...

      I think maybe Windows' landscape has changed

      Yup. They're almost up to 1997.
  • I have always wondered about code from the mid 80's and the East Block.
    Thinking back to http://it.slashdot.org/article.pl?sid=04/03/02/071 9247 [slashdot.org]

    Was M$ helpeing to add a little extra into the USSR as US software flooded east?
    The fun of a free door into any network thanks to M$ moving around the world?

    In America bad code is no problem, it is just for end users.
    In Soviet Union, expensive stolen code kills YOU.

    Was M$ just a CIA front company gone too far?

  • 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

    Then how come only size 1 worked, not other incorrect sizes?
    • Likewise, if you correctly identify the record size, but include the binary code to be executed in place of the expected wmf data to say draw a line, what would cause the setabort event to trigger?

      Presumably if a record exists that has invalid data, some sort of failure will happen. Whether that is the first record, last record, or some arbitrary record in the middle of the wmf file. What Steve has reported is that if he sets an invalid record size of 1 on that record, it causes the system to treat the data

  • Why XP/2000 and not 9X? (Score:3, Insightful)

    by KevinColyer ( 883316 ) on Monday January 16, 2006 @09:36AM (#14481179) Homepage
    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)

  • What WINE does (Score:5, Informative)

    by JohnGrahamCumming ( 684871 ) * <slashdotNO@SPAMjgc.org> on Monday January 16, 2006 @09:58AM (#14481295) Homepage Journal
    I think that their implementation contains exactly the same bug as Windows (as others have pointed out) and that if you take a look at the code you can easily see why (and it's not a backdoor).

    First the file dlls/gdi/metafile.c contains a function called PlayMetaFileRecord with the following signature:

    BOOL WINAPI PlayMetaFileRecord( HDC hdc, HANDLETABLE *ht, METARECORD *mr, UINT handles )

    Which is simply WINE's implementation of the same Win32 API (which is documented here: http://msdn.microsoft.com/library/default.asp?url= /library/en-us/gdi/metafile_1yec.asp)

    The third parameter (mr) is a METARECORD pointer (a METARECORD is just an entry in the metafile and is detailed here: http://msdn.microsoft.com/library/default.asp?url= /library/en-us/gdi/metafile_8j1u.asp) and is the all important header with the following definition:

    typedef struct tagMETARECORD { DWORD rdSize; WORD rdFunction; WORD rdParm[1]; } METARECORD, *PMETARECORD;

    With the rdSize being the size of the record in words, the rdFunction being the function and the rdParm the data (which in the case of an exploit would be executable code). PlayMetaFileRecord handles META_ESCAPE like this:

    case META_ESCAPE:
    Escape( hdc, mr->rdParm[0], mr->rdParm[1], (LPCSTR)&mr->rdParm[2], NULL);
    break;

    You'll note that parameter 3 is a pointer into the metafile parameter block, i.e. if executed parameter 3 would execute code in the metafile. Now Escape has implemented like this (dlls/gdi/driver.c):

    INT WINAPI Escape( HDC hdc, INT escape, INT in_count, LPCSTR in_data, LPVOID out_data )

    and the SETABORTPROC is handled with the following code:

    case SETABORTPROC:
    return SetAbortProc( hdc, (ABORTPROC)in_data );

    So if you have an ESCAPE/SETABORTPROC record in a metafile then under WINE the AbortProc is set to point into the metafile (since in_data is corresponds to &mr->rdParm[2]).

    So it's quite clear from the WINE implementation that this is a way to set a pointer into the metafile for execution. All it would take is that the metafile's AbortProc is called and arbitrary code could be executed.

    In WINE at least this looks nothing like an intentional backdoor. It looks more like a bug caused by the fact that Escape is rather powerful and can set a pointer to code.

    Now it's possible in WINE (I believe) to force the AbortProc to execute with another ESCAPE record that has NEWFRAME as the function. Again looking at the Escape code you'll see that NEWFRAME has handled like this:

    case NEWFRAME:
    return EndPage( hdc );

    EndPage is a standard GDI function (see here for documentation: http://msdn.microsoft.com/library/default.asp?url= /library/en-us/gdi/prntspol_0d6b.asp). If you take a look at the implementation in WINE you see the following code (dlls/gdi/printdrv.c):

    INT WINAPI EndPage(HDC hdc)
    {
    ABORTPROC abort_proc;
    INT ret = 0;
    DC *dc = DC_GetDCPtr( hdc );
    if(!dc) return SP_ERROR;

    if (dc->funcs->pEndPage) ret = dc->funcs->pEndPage( dc->physDev );
    abort_proc = dc->pAbortProc;
    GDI_ReleaseObj( hdc );
    if (abort_proc && !abort_proc( hdc, 0 ))
    {
    EndDoc( hdc );
    ret = 0;
    }
    return ret;
    }

    Note that this function always called the Abo

  • FTFA (Score:2, Informative)

    by defile ( 1059 )
    • The vulnerable code has been there since 3.0, but it wasn't exploitable until very recently.
    • Gibson's claim that it was an intentional vulnerability is bogus (it was bogus before, but just in case you needed confirmation, here it is from Microsoft)

    Thanks.

  • Stop, and think for a moment (Score:4, Informative)

    by anzev ( 894391 ) on Monday January 16, 2006 @10:50AM (#14481647)
    Ok, i've been reading about this for much too long. It seems that there are two main issues here, how the flaw went unnoticed and why Microsoft didn't reimplement the whole legacy thing.

    Did anybody even RTFA? I've seen a lot of people already writing that Microsoft should have re-implemented the Legacy code, yadayadayada, write a new OS from scratch, introduce a new virtual machine just for OS compatibility. However, you all missed something very important. WMF is a well-defined standard (not saying a good one, but a well-defined one!) which means that Microsoft (or Wine for that matter) HAS TO IMPLEMENT IT WITH CERTAIN CONSIDERATIONS. One of them, is the SetAbortProc [microsoft.com] procedure that's been causing so much trouble. If Microsoft would failed to implement one part of this standard we would be getting comments like "M$ is 3vil, they don't respect standards...". I bet they're sorry that the security flaw got missed. I think it shows on their stock [google.com] also! But non the less, it's fixed now.

    Come to think of it, I think that, in a world where there were no exploits (PC-wise) the whole callback function scenario was pretty cool. You'd just say that if something fails, notify the user with this procedure in my code, and since you already no it failed (no return false statement :-) ), you can also do some other tasks.

    One more sidenote, Microsoft HAS REIMPLEMENTED the code. This is proven by the following statement in the article:

    With WMF we want to be very clear: the Windows 9x platform is not vulnerable to any "Critical" attack vector. The reason Windows 9x is not vulnerable to a "Critical" attack vector is because an additional step exists in the Win9x platform: When not printing to a printer, applications will simply never process the SetAbortProc record. Although the vulnerable code does exist in the Win9x platform, all "Critical" attack vectors are blocked by this additional step.

    I have no idea why they've let this slip though in the XP.

    • You might do the same... (Score:4, Interesting)

      by Svartalf ( 2997 ) on Monday January 16, 2006 @12:04PM (#14482251) Homepage
      This should have never even been in the WMF specification in the first place .

      It was a bad idea then.
      It's a bad idea now.

      What else is in their specs that's a bad idea?

      Something like this WMF exploit, or perhaps less problematic but still annoying,
      like GetTempFileName- where in 16 bits, you used a zero for the main drive and
      a 1, 2, or so forth for the drive you wanted it to and in 32 bits, it's a string
      with a canonical path to the place you want the temp file to be generated. Oh,
      and by the way, zero's what most people used for their 16-bit code and a null
      (zero on machines of the day...) produced undetermined results from the 32-bit
      version of the API. Sometimes it'd work, sometimes it wouldn't. To be sure,
      that sort of problem code wouldn't have gotten out the door. But if they've done
      that sort of thing with their API's, I wouldn't trust that something never went
      out with issues due to lurkers in the API's and specs that will come back to
      bite someone on the ass down the line.

      What else is lurking in MS' products that we don't know about? If they didn't design
      it with security in mind then, what possesses you to think that they can go back
      after the fact and bolt it on afterwards without causing it's own set of problems?
      That'd be like using a hollow core door on the entry or exit of a house, and
      not having a lock or deadbolt on the door- and then putting just a deadbolt on the
      selfsame door when your house gets entered and people take things from you.

      MS just simply needs to work at some solution to the issue of backwards compatibility
      for their current OS products and start fresh with security in mind when they
      do things. Anything else is like the door analogy I just gave.
      • This should have never even been in the WMF specification in the first place .

        It was a bad idea then.
        It's a bad idea now.

        Except, under the hood, WMF is used to batch together GDI calls, which means it needs this functionality. So how do you fix it?

  • 'ported' isn't really the word (Score:5, Informative)

    by dioscaido ( 541037 ) on Monday January 16, 2006 @11:22AM (#14481919)
    Something that people don't seem to realize is that when a new OS is created for a particular windows family (95/98/ME or NT4/2000/XP/2003/Vista), functions aren't 'ported'. Instead the same codebase is worked on until you arrive at the next version. So once that function was ported over from the 95 family to the NT4 family, it probably remained untouched, with this vulnerability. So it's not necessarily correct to say 'why did they keep porting this function across OS?!'.

    The reality is the windows codebase has a ton of legacy in it. One positive step taken for Vista is that *all* code, including legacy (actually, most importantly, legacy), was SAL annotated so that static analysis of the full codebase could be performed for a large variety of coding mistakes that lead to vulnerabilities. Related to that, all memory/string functions that don't take bounds have been removed from the codebase, which allows SAL to statically analyze for buffer overruns. There's been a few times when thanks to updates to the SAL agent I've had bugs assigned to my code that catch obscure issues. You can read more about the technique at: http://research.microsoft.com/slam/ [microsoft.com] At the same time, WIM is doing a second security sweep of all windows components. This is in no way complete, given that things like this WMF vulnerability still got through, but still it is a start, and is a process that is evolving every day.

    I'd like to point out that in Vista WMF is mitigated by the fact that unless you are logged in as the straight Administrator account, the arbitrary code executed from the WMF exploit will only have limited user access to the system (no access to write to the windows directory, program files directory, and system registry for example) even if the account is part of the Administrators group. Honestly this is probably the #1 reason to move to Vista -- it finally has a coherent LUA story and by default I can run all my apps with low priviledges.
  • Is it true that Microsoft didn't patch all versions of Windows?

    If so, where is the non-MS patch now?

    Is this a sneaky way to force upgrades on older OS's?

    • Is it true that Microsoft didn't patch all versions of Windows?

      It is true that there is no patch for Win 9x/Me. It is also true that they weren't affected in the first place.

      Is this a sneaky way to force upgrades on older OS's?

      The only OSes to which this could apply would be NT 3.1, 3.5, 3.51 and 4.0. MS has been far from sneaky in saying that nobody who cares at all about security should even consider running these anymore.

      I haven't re-installed any of these dinosaurs to check, but my immedi

  • So where does Microsoft refute Gibson?? (Score:4, Informative)

    by dtjohnson ( 102237 ) on Monday January 16, 2006 @01:46PM (#14483164)
    Read more closely. Where does Microsoft actually say that Gibson is wrong? Gibson claimed that Windows XP would read a .wmf file and begin executing a portion of the data file contents as executable code if a metafile record was encountered with a length of one byte. Since the minimum length of a valid metafile record is 6 bytes, Gibson suggests that the behavior was intentional rather than an accident. Microsoft doesn't actually SAY in their response that any of what Gibson claims is wrong:

    Gibson: [grc.com] Except that, when I was pursuing this and finally got it to work, what Windows did when it encountered this Escape function, followed by the SETABORTPROC metafile record, was it jumped immediately to the next byte of code and began to execute it. That is, it was no longer interpreting my metafile records record by record, which is the way metafiles are supposed to be processed.

    Microsoft: [technet.com] If you are seeing that you can only trigger it with an incorrect value, it's probably because your SetAbortProc record is the last record in the metafile.

    Gibson: It turns out that the only way to get Windows to misbehave in this bizarre fashion is to set the length to one, which is an impossible value. I tried setting it to zero. It didn't trigger the exploit. I tried setting it to two, no effect. Three, no effect. Nothing, not even the correct length. Only one.

    Microsoft: The vulnerability can be triggered with correct or incorrect size values.

    Even though the Microsoft guy claims he is going to "get rather technical here" he never specifies what he considers an 'incorrect' or 'correct' size value to be. More importantly, he never refutes the claim that a record with a length of one byte would always cause Windows to spawn a new thread and begin executing 'data' as code.
  • I think we should leave all technology decisions up to politicians. They know what's best for the rest of us. As a matter of fact, I'm thinking of putting up a Web site to encourage companies like Google, IBM, Microsoft and Apple to put politicians on all of their boards so that we're sure to get what's best for the people. Clearly in this case the Korean's are ahead of us!

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Close