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

WMF Vulnerability is an Intentional Backdoor? 788

Posted by Zonk
from the take-with-a-grain-of-salt dept.
An anonymous reader writes "Steve Gibson alleges that the WMF vulnerability in Windows was neither a bug, nor a feature designed without security in mind, but was actually an intentionally placed backdoor. In a more detailed explanation, Gibson explains that the way SetAbortProc works in metafiles does not bear even the slightest resemblance to the way it works when used by a program while printing. Based on the information presented, it really does look like an intentional backdoor." There's a transcript available of the 'Security Now!' podcast where Gibson discusses this.
This discussion has been archived. No new comments can be posted.

WMF Vulnerability is an Intentional Backdoor?

Comments Filter:
  • by AltGrendel (175092) <ag-slashdot AT exit0 DOT us> on Friday January 13, 2006 @01:40PM (#14464898) Homepage
    I could see someone deliberatly doing this, maybe a contractor or a disgruntled employee.

    Its happened before and it will happen again. Whether this is the case remains to be seen.

    • by NtroP (649992) on Friday January 13, 2006 @01:57PM (#14465104)
      I could see someone deliberatly doing this, maybe a contractor or a disgruntled employee.
      The problem with that argument is that in order to exploit this backdoor you'd have to get the target computer to load a WMF file. The main practical way to do this would be to embed it in a web page and have the target visit that page. The only sites that all windows machines access on a regular basis are Microsoft's. The employee would also have to have access to Microsoft's web site to exploit this reliably.

      This seems to be only useful if MS itself wanted to use it. Use your imagination as to what they'd do with it. I can think of all kinds of things.

      • by QuietLagoon (813062) on Friday January 13, 2006 @03:05PM (#14465732)
        The only sites that all windows machines access on a regular basis are Microsoft's.

        I presume you are willing to show the details of your extensive research that determined this factoid....

        • Most Windows computers at one point have connected to Windows Update, also IE defaults to MSN, isn't there a getting started page as well when you first open IE after install?

          It's just simple observation to say that the only site that would be consistent on every Windows system is a Microsoft site, somewhat how on my mac I am connected to apple after a clean install when I open Safari. One could say the only site that would be consistent on every mac would be apple.com.

          -PS I don't think it was an intentiona
      • by mrseigen (518390) on Friday January 13, 2006 @04:17PM (#14466417) Homepage Journal
        I'm not quite sure why they'd want to use it. End-users already trust Microsoft implicitly because they made the operating system, so if they wanted to, for instance, install some software on all Windows machines that reports home if it detects a pirated copy, they could just do it through a service pack update. Most people would willingly install it (or click the little automatic button in Windows Update), and there'd be none of this Tom Clancy technothriller intrigue.

        I can't personally think of any kind of official reason why Microsoft would want to shove code onto Windows machines just from visiting their website. They've got tons of other ways of doing this.
    • by dc29A (636871) on Friday January 13, 2006 @02:15PM (#14465291)
      I could see someone deliberatly doing this, maybe a contractor or a disgruntled employee.
      - How about a totally stupid idea that MS thought was good?

      I mean MS has a long history of ignoring security for usability, lock in and whatnot. WMF dates back to close to 10 years, back when MS really didn't give a damn about security. Even after a the big Gates propaganda email and Trusted Computing Initiative and all the hoopla, XP SP2 allows blank passwords for administrators, the user created during installation is an administrator, again if password is blank no one gives a shit. Remote registry is on by default. RPC on by default. Administrative shares are on by default. Not to mention a plethora of completely useless services.

      MS just doesn't understand security. This WMF example is nothing different. It's some ancient code that never got looked at. Add to that the fact everyone and his mother is root, AND that the OS is a big bowl of spaghetti (hi2u IE deep in kernel), you get another attack vector vs Windows systems.

      Did someone maliciously implement this WMF "feature"? I doubt it. It looks like another regular MS security hole that shows that MS has no clue about security.
      • by mohaine (62567) on Friday January 13, 2006 @03:19PM (#14465867) Homepage
        I thought this as well, but if you RTFA, you would see that Gibson doesn't think the SetAbortProc WMF exploit works the way it should.

        According to the docs, SetAbortProc should provide a pointer to callback function that is called when a print is aborted. This in itself sounds like a security hole, but it could only be fired if the print is canceled, and then it can only run a preexisting callback method, not arbitary code.

        According to Gibson, if you call SetAbortProc with a special key, it will instantly start running arbitary code from within the WMF. No cancelled print or preexisting method calls are requried.

        If Gibson is correct, this bug is much different then how it looks on the surface.

    • by Stripe7 (571267) on Friday January 13, 2006 @02:26PM (#14465397)
      Someone mentioned on Groklaw that the exploit also exists in wine which just implements the WMF spec.
  • NSA (Score:5, Funny)

    by Anonymous Coward on Friday January 13, 2006 @01:40PM (#14464899)
    Well, how else is the NSA going to fight terrorism?
  • Government backdoor? (Score:5, Interesting)

    by Jerry_Duplicate (126840) on Friday January 13, 2006 @01:40PM (#14464904)
    There was talk about the NSA/CIA having a close relationship with Microsoft and being able to exploit backdoors in Windows. This could have all been conspiracy theories, but the fact that this vulnerability existed throughout the Windows line kinda seems odd..

    If this isn't a glaring example on why you should support open source, I don't know what is....
    • by Dystopian Rebel (714995) on Friday January 13, 2006 @01:53PM (#14465053) Journal
      but the fact that this vulnerability existed throughout the Windows line kinda seems odd.


      The function in question has existed for a long time. The exploit is in Windows 2000 and more recent. From the transcript:

      But the only conclusion I can draw is that there has been code from at least Windows 2000 on, and in all current versions, and even, you know, future versions, until it was discovered, which was deliberately put in there by some group, we don't know at what level or how large in Microsoft, that gave them the ability that they who knew how to get their Windows systems to silently and secretly run code contained in an image, those people would be able to do that on remotely located Windows machines...
    • Of course Windows is the dominant corporate operating system in the U.S., and there are far more intelligence agencies around the world who engage in corporate espionage than just the NSA/CIA (actually, the U.S. is probably behind in corporate espionage compared to say the Chinese or French - we are too worried about terrorist or whatnot). The idea that the NSA/CIA would encourage something that would be used against Americans by foriegn powers as much or more than against the "enemies" of the U.S. makes th
    • Yes, because it's impossible for an identical problem to exist in WINE [zdnet.com], and therefore open source solves all problems.
    • The first NSA-induced backdoor that was well documented was in Windows 95/98/ME and NT4 and later. A reasonably good writeup is found at http://www.heise.de/tp/r4/artikel/5/5263/1.html [heise.de] (english).

      Needless to say, I am not at all surprised that there might be all sorts of backdoors in Windows that we may never know about. This is a really good reason *not* to use it in any environment requiring security.
      • by monkeydo (173558) on Friday January 13, 2006 @02:56PM (#14465642) Homepage
        Paraniod speculation. Much like the current story.
      • by man_of_mr_e (217855) on Friday January 13, 2006 @04:15PM (#14466399)
        Actually, Bruce Schneier's analysis is somewhat different.

        http://www.schneier.com/crypto-gram-9909.html#NSAK eyinMicrosoftCryptoAPI [schneier.com]

        The fact is, the majority of the people making claims about this don't even understand what it does. The majority of the speculation isn't possible. It doesn't give anyone (Not even Microsoft, much less the NSA) a backdoor into your computer.
    • If this is an intentional backdoor, it is the crappiest one, EVER!

      You'd want something in the base system of ALL Windows version, which couldn't be disabled AT ALL, doesn't require a user to be logged-in as an admin, or stupid enough to open anything sent to them.

      If I was making a backdoor, I'd put it in something basic... Have the IP stack open a port when recieving a specially-crafted packet. Have the filesystem driver silently execute a file if it find a special signature in it (eg. code embedded in a
  • Length==1 (Score:5, Insightful)

    by atfrase (879806) on Friday January 13, 2006 @01:41PM (#14464918)
    This does look awfully like a special-case trigger. The idea of a backdoor is to have it look for a specifically crafted but completely nonsensical and invalid input sequence -- this serves as the "key" to the backdoor, ensuring that no other designer or user accidentally stumbles onto it. Since we assume that legitimate users and developers will only provide valid input, we design our "key" to be definitely invalid. For me, that length==1 trigger is the most convincing evidence. It's not just that it's the wrong input, it's that it's the one specific value of wrong input that triggers the behavior. That seems like design.
    • Re:Length==1 (Score:4, Insightful)

      by stevied (169) * on Friday January 13, 2006 @01:49PM (#14464999)
      Obviously SetAbortProc should not be implemented for WMF playback, but assuming somebody screwed up and just called the normal version of Escape(), could the behaviour we're seeing here not somehow be the result of not checking the validity of the length parameter properly, performing some arithmetic on it, and possibly falling through to some other code that happens to a jump or call?
      • Re:Length==1 (Score:4, Interesting)

        by Shimmer (3036) <brianberns@gmail.com> on Friday January 13, 2006 @02:03PM (#14465165) Homepage Journal
        You're right, of course. Everyone who's saying this is "obviously" intentional are jumping the gun in a big way. I've got $5 right here that says it's an accident.

        "Never ascribe to malice that which is adequately explained by incompetence."
      • by IPFreely (47576) <mark@mwiley.org> on Friday January 13, 2006 @03:01PM (#14465698) Homepage Journal
        It that is all it was, then the the same thread would jump into the user code. But wait...

        I found was that, when I deliberately lied about the size of this record and set the size to one and no other value, and I gave this particular byte sequence that makes no sense for a metafile, then Windows created a thread and jumped into my code, began executing my code.

        So, it accidently created a new thread, and directed the new thread to start executing code at the specific position? That's a whole different level of accident.

        Oh, and Shimmer, I'll take that 5$.

    • Re:Length==1 (Score:5, Insightful)

      by Procyon101 (61366) on Friday January 13, 2006 @01:49PM (#14465010) Journal
      Possibly, but I doubt it's a Microsoft sanctioned backdoor. Any "OFFICIAL" backdoor from MS would have a much more complex key to get in than "1".

      I can see this being a programmer supplied backdoor, like a hook for easter eggs, but based on the other security work done in MS, anything that can be gotten into that is there on purpose is locked up pretty tight to any casual attempts.
      • Re:Length==1 (Score:5, Interesting)

        by atfrase (879806) on Friday January 13, 2006 @01:57PM (#14465101)
        Agreed, it doesn't seem like the kind of "feature" that was designed in top-secret MS design documents or developed in meetings.

        But I still have a hard time seeing how code would *accidentally* behave like this. An invalid length should abort processing right off the bad, for one thing; "falling through" might be an explanation, but what possible code could be "fallen through" into that would set CPU execution *inside* the metafile -- moreover, would set CPU execution to the *next byte* after the erroneous header block. That's awfully convenient; if it were a mistake, I'd expect code execution to begin at some other random location, probably influenced by whatever happened to be in the register or some temporary pointer variable at the time. But the very next byte? That's too insanely convenient -- you get to provide your key *and* your payload in the *same* place.

        You could argue that buffer overrun exploits do the same thing, but the idea of the buffer overflow is to specifically overwrite the function-return pointer to *make* it point at your code. In this case, the exploit doesn't have to specify the location of the code to execute, Windows does that for you. Too convenient.
        • > but what possible code could be "fallen through" into
          > that would set CPU execution *inside* the metafile

          Actually, I think it was done for performance releases (remember, existed back in the Win 3.0 days).

          Back in ye olden days, there was a common software practise called self modifying code. It was used in some implementations of FORTH, but it was far more popular on systems that had few registers like C64. It was generally used as a way to dramatically speed up code on those slow processors.

          Have a
    • Thread Creation (Score:5, Insightful)

      by Lagged2Death (31596) on Friday January 13, 2006 @01:57PM (#14465099)
      For me, that length==1 trigger is the most convincing evidence.

      I don't think it's surprising that a piece of code might behave in an odd way if it's given invalid input, i.e., if a buffer length is wrong.

      I think the real giveaway here is that Windows creates a new thread when presented with this magic length. That's like rolling out the red carpet for the attacking Huns. I don't think the average buffer overflow type exploit gets it's own thread or process.

      And of course it's still possible that it was all a mistake. The C language can be used to write some extremely tangled code, if one is so inclined. Something like an incorrectly used setjmp/longjmp could have effects like this.
      • Re:Thread Creation (Score:5, Insightful)

        by atfrase (879806) on Friday January 13, 2006 @02:03PM (#14465171)
        I don't think it's surprising that a piece of code might behave in an odd way if it's given invalid input, i.e., if a buffer length is wrong.

        Again, agreed. But again, the catch is in the particular kind of odd behavior. If I were writing that code and it hit an invalid length, I'd probably abort processing of the whole file, presuming data corruption. Failing that I'd just skip over the flawed block and proceed with processing the next one. In that case, I could imagine not checking the length very carefully and just going to " + " to process the next block -- this would produce the observed "next byte" pointer.

        The problem is in the semantics: I said *process* the next block, not *execute* it. If anything this would just cascade into more error cases, since the data that was expected to be the "next block" would almost definitely also have a malformed header (since it wasn't intended to be a header at all), etc.

        So, I guess you're right - the tipoff is still that actual code is executed without having to be specifically pointed to (i.e. buffer overrun), and that it's executed in its own thread, rather than taking over the processing thread that was interpreting the metafile in the first place.
        • Re:Thread Creation (Score:4, Insightful)

          by 0123456 (636235) on Friday January 13, 2006 @02:22PM (#14465361)
          "it's executed in its own thread, rather than taking over the processing thread that was interpreting the metafile in the first place."

          But that's only an issue if the WMF-processing code doesn't create a new thread in order to call the subroutine in the valid case. In reality you'd almost certainly want the callback to happen in its own thread, rather than to allow anyone to run abitrary code in the same thread as the print server.
      • by RingDev (879105) on Friday January 13, 2006 @02:22PM (#14465364) Homepage Journal
        Code encounters escape character

        exit standard processing

        encounter SetAbortProc

        open thread to communicate with windows print manager

        thread attempts to read [length] bytes for sub value, encounters overrun

        this is where I'm guessing the real horrendous problem lies. I'm guessing that the original code ignores exceptions while pulling in the sub value, so in this case where code hits an overrun, instead of that sub value getting a few bytes of data, it just graps until . In this case that sub value winds up being the payload.

        So there you go, key and payload on an independent thread because of a bad exception handler in a 12 year old block of code.

        -Rick
      • Re:Thread Creation (Score:3, Insightful)

        by Ancil (622971)

        I think the real giveaway here is that Windows creates a new thread when presented with this magic length. That's like rolling out the red carpet for the attacking Huns. I don't think the average buffer overflow type exploit gets it's own thread or process.

        I don't find this (or the originial article) convincing. He makes a wildly unsubstantiated claim about the WMF vulnerability being intentional.

        The whole Escape/SetAbortProc vulnerability is built around some (admittedly stupid) functionality in WMF

    • Easy one to test. (Score:3, Insightful)

      by jd (1658)
      There are many ways in which 1 could purely coincidentally be tested for - using multiple bitwise operations that don't completely cover the word, for example.

      However, there are a few very specific ways in which you would write code to deliberately look for that specific value in a specific portion of an operation. These ways can be checked by inspecting a disassembled version of the code. (But do this outside of the US, or the DMCA droids will Use The Force.)

      Since WINE shows the same hole and the coders ar

    • Re:Length==1 (Score:5, Informative)

      by StarDrifter (144026) on Friday January 13, 2006 @03:33PM (#14466008)
      For me, that length==1 trigger is the most convincing evidence.

      It might have been convincing if it were true. The vulnerability checker [hexblog.com] from Ilfak Guilfanov's site uses length==17 to trigger the exploit (Look in the wmfhdr.wmf file in the source zip. The length is a little-endian DWORD at offset 0x12.)

      The Metasploit module [metasploit.com] uses a length of 4. Check out the following snippet:

          #
          # StandardMetaRecord - Escape()
          #
          pack('Vvv',

              # DWORD Size; /* Total size of the record in WORDs */
              4,

              # WORD Function; /* Function number (defined in WINDOWS.H) */
              int(rand(256) << 8) + 0x26,

              # WORD Parameters[]; /* Parameter values passed to function */
              9,
          ). $shellcode .

      I think Steve Gibson is confused.
  • do you mean (Score:4, Interesting)

    by Anonymous Coward on Friday January 13, 2006 @01:42PM (#14464925)

    This Steve Gibson [grcsucks.com] ?, yeah he is a real security expert, along with his podcast boy wonder we have much to be afraid of

    • The name means nothing. It's the facts that matter. Whether he is a one-day hacker or some looney, he discovered that for Length==1, (a completely invalid value that makes no sense for WMF's), Windows creates a new thread and starts executing the code.

      IMHO your "debunking steve gibson" site is nothing but a smokescreen to divert the attention from Microsoft's vulnerabilities and backdoors.
      • by undeadly (941339) on Friday January 13, 2006 @02:21PM (#14465354)
        IMHO your "debunking steve gibson" site is nothing but a smokescreen to divert the attention from Microsoft's vulnerabilities and backdoors.

        In my not so humble opinion, you don't know what you are talking about. Go read some of the links in that site, and you'll see that Steve Gibson is one of the many "security experts" that have no clue but gives dangerous and very wrong "solutions".

        • by TheNumberless (650099) on Friday January 13, 2006 @03:51PM (#14466194)
          In my not so humble opinion, you don't know what you are talking about. Go read some of the links in that site, and you'll see that Steve Gibson is one of the many "security experts" that have no clue but gives dangerous and very wrong "solutions".

          In my ever-so-humble opinion you completely missed the point of the parent. The reputation, sanity, motives, and anything else dealing with the person making the claim has nothing to do with the validity of the claim itself.

          In this particular instance, there is at least some apparent merit to the idea that this was an intentional backdoor, and that merit would be there regardless of who points it out.

          If you want to discredit the idea that this is an intentional backdoor (of which I am far from convinced), then you should attack the argument directly, not the man making it.
  • SetAbortProc (Score:3, Informative)

    by jwegy (775655) on Friday January 13, 2006 @01:45PM (#14464951)
    Yeah, SetAbortProc is used for cancelling print jobs. Here is the MSDN documentation: SetAbortProc [microsoft.com]
  • Possible uses? (Score:4, Interesting)

    by Kitsune78 (941644) on Friday January 13, 2006 @01:46PM (#14464962)
    The freakish thing about this, is that if it is indeed a backdoor, it an odd way to go about it. You can't force someone to try to view a WMF. What would its purpose be? You can't use it to get into the exact box you want to, just into a random box that perhaps picks up your WMF from a webpage, or displayed in an application.
    • Re:Possible uses? (Score:5, Interesting)

      by RexRhino (769423) on Friday January 13, 2006 @01:53PM (#14465058)
      Digital Rights Management... If you can control a box using a WMF file, there is all sorts of digital rights management mischieve you can do to prevent a machine from copying a file, or decoding a file, or whatever.
      • It's a ten year old or so vulnerability. It predates DRM, so I doubt it was built for that originally. Sure, it may have DRM uses, but it couldn't have been made for DRM.
    • The freakish thing about this, is that if it is indeed a backdoor, it an odd way to go about it. You can't force someone to try to view a WMF

      That we know of that is. This has been lurking about in every version of windows since 95, right? And it's taken until now to be brought to light. How many other similar seemingly innocent bits of code in those millions of lines of legacy windows code do similar things? The question is not what can this exploit do on its own, but what can it do in concert with others

  • by m50d (797211) on Friday January 13, 2006 @01:46PM (#14464968) Homepage Journal
    That's why they're bugs. Seriously, I don't think the fact that it behaves differently from how it does in a printer is any indication it was deliberately written that way. More likely this was an attempt to disable the code that went wrong.
    • That's why they're bugs. Seriously, I don't think the fact that it behaves differently from how it does in a printer is any indication it was deliberately written that way. More likely this was an attempt to disable the code that went wrong.

      You're talking out of your ass. RTFA.

      This is (IMNSHO) not a bug. How would you accidentally introduce a bug that for one specific, non-valid, value the program would start executing code that has no place being there in the first place. This has nothing to do w

  • Lawsuit time (Score:5, Interesting)

    by Animats (122034) on Friday January 13, 2006 @01:47PM (#14464980) Homepage
    Someone involved in a WMA-related lawsuit needs to subpoena, from Microsoft, all the source code and all the change control information for this small part of Windows. Then the original programmers need to be found and deposed under oath. This is standard legal procedure for something like this.

    It's possible to get to the bottom of this by legal means.

  • by Marxist Hacker 42 (638312) * <seebert42@gmail.com> on Friday January 13, 2006 @01:47PM (#14464983) Homepage Journal
    I think it's a beneficial back door- in fact, I wouldn't be at all surprised to find that they'll need to update "Windows Update" after all the patches are in place.
  • Magic Lantern? (Score:5, Interesting)

    by Tackhead (54550) on Friday January 13, 2006 @01:47PM (#14464985)
    Sometimes even a blind squirrel gets a nut.

    The notion of a backdoor in Windows isn't new. Perhaps the WMF vulnerability was one of the vectors used by Magic Lantern [wired.com], which was the code word for at least one of the FBI's keylogger programs. Magic Lantern was notable in that antivirus providers participated with the Feebs in a gentleman's agreement to not look for it.

    It's certainly a dumb enough solution that the IT-challenged FBI might go for it.

    On relative dumbness and smartness, I'd expect smart spies, namely those who work for two other notable three-letter-agencies, to use somewhat more interesting techniques. If it were me, I'd take advantage of equipment I had in place at critical infrastructure points to conduct MITM attacks between a PC and Windows Update servers, in order to transparently install my spookware on only those machines that specifically identify themselves - by means of GUID or whatever other stuff I could glean from the Windows Genuine Advantage and other DRM-related bitstreams - as belonging to my target population.

    Paranoid? If you're not paranoid, you're not thinking far enough ahead.

  • by Sycraft-fu (314770) on Friday January 13, 2006 @01:49PM (#14464997)
    Please remember this is the same Steve Gibson who claims to have invented a new amazing "nanoprobe" technology for port scanning which he claims is a first to the world and can do just about everything. Of course turns out to just be specially crafted TCP packets with no payload, which nmap has done since forever.

    The guy is a massive alarmist and I wouldn't take anything he says seriously. He loves to cry about the end of the digital world type scenarios, perhaps because he really believes it, or perhaps because it gets him more business.
  • by joshtimmons (241649) on Friday January 13, 2006 @01:49PM (#14464998) Homepage
    I agree with the author that the length prefix is something of a smoking gun. It begs the question of "how do we know it was fixed..." For example, they could change it to execute the datastream when length is set to a new trigger value; or a stronger backdoor would ignore any unsigned code. Still there, but harder to test for.

    It's a straightforward way to add a backdoor that will bypass firewalls, etc. It can be triggered by a browsed page, email, etc. It's better than gif/jpeg encoding because those are more "platform independent." and the payload would be more likely noticed by a 3rd party decoder.

    On the other hand, isn't this flagged as an attempt to execute code on a data page?

    Also, if it were official, doesn't MS have easier ways into a general box - say through security updates, or even the entire existing code base?
  • by Anonymous Coward on Friday January 13, 2006 @01:49PM (#14465000)
    Steve Gibson is not a security expert

    http://www.grcsucks.com/ [grcsucks.com]
    • by NtroP (649992) on Friday January 13, 2006 @02:28PM (#14465410)
      Steve Gibson is not a security expert
      I'm not a security expert either. But if I came up with this evidence, how would that change the reality of the situation. The evidence stands on its own merit. His reputation has nothing to do with it. This is easily verifiable by anyone with at least his level of knowledge. It will be interesting to see what happens when other "real" experts start looking at this.
  • What about wine? (Score:3, Interesting)

    by Meltr (45049) on Friday January 13, 2006 @01:53PM (#14465047)
    I thought the same vulnerability exists in wine?

    http://it.slashdot.org/article.pl?sid=06/01/06/204 3203 [slashdot.org]
    • Re:What about wine? (Score:3, Informative)

      by Deanalator (806515)
      The only thing that I can think of would be blind reverse engineering or something. No offense to whoever submitted the code, as Im sure that can be taken as a massive insult (I know I would be annoyed if someone made accusations like that about my code). Maybe the wine developer was just very anal about the specs and didn't realize what could be done with it, but it is a good defensive point for microsoft.
  • Yeah... (Score:5, Informative)

    by TheAwfulTruth (325623) on Friday January 13, 2006 @01:53PM (#14465052) Homepage
    Isn't this the same Steve Gibson that was freaking out about how Raw Sockets in XP were going to destroy the world a couple of years ago?

    S.G. is a flaming idiot, he looks for (and imagines) ghosts and spooks in every corner. Then flogs his conspiracy theories to promote himself and his buisness. This probably holds about as much water as the "discovery" of cold fusion and Korean human cloning.

    Why aren't we reporting on REAL bugs like the 4 security vulnerabilities found in iTunes this week which opens both Windows and Mac users to external attack? Was the Microsoft bashing quota too low this week?

    What is becoming of /.?
    • Re:Yeah... (Score:5, Insightful)

      by NtroP (649992) on Friday January 13, 2006 @02:15PM (#14465303)
      Isn't this the same Steve Gibson that was freaking out about how Raw Sockets in XP were going to destroy the world a couple of years ago?
      Didn't that get quietly fixed in a subsequent update and therefore NOT become an issue? He may be an alarmist, but he's normally a Pro-MS guy. In this case, I think he's on to something.
  • by east coast (590680) on Friday January 13, 2006 @01:54PM (#14465070)
    I can't believe it, Jim. That girl's standing over there listening and you're telling him about our back doors?

    You guys are so dumb, I'd go straight through Falken's Maze.

    I just hope David Lightman isn't reading this... we'd only have a few days until it was all over for us...
  • Patch (Score:3, Insightful)

    by Paradise Pete (33184) on Friday January 13, 2006 @01:57PM (#14465107) Journal
    If it were intentional you'd think they would have been able to patch it a little more quickly.
  • by nweaver (113078) on Friday January 13, 2006 @01:58PM (#14465118) Homepage
    Who writes an evil backdoor, which dates back to Win3.1 days (when you didn't NEED an evil back door, and Windows had no clue what this Internet thing was about), and then DOCUMENTS it?

    Lest we forget that Wine also proved vulnerable, and it was a clean-reimplementation of the specs!
  • This guy is a moron. (Score:5, Informative)

    by gregarican (694358) on Friday January 13, 2006 @02:05PM (#14465186) Homepage
    I browsed over several posts on his website and come away with the conclusion that he is a few fries short of a Happy Meal. Here's one posting that I found really amusing:

    "Thank you Microsoft for blessing us with a patch to fix the products
    you currently sell. The products that compete with Linux and Macintosh.
    Excellent job at diverting the our attention away from the fact that
    Windows 95, Windows 98, Windows 98SE, Windows Millennium Edition, and
    Windows NT4 remain vulnerable. Neat trick convincing people that "the
    vulnerability is not critical because an exploitable attack vector has
    not been identified that would yield a Critical severity rating for
    these versions."

    Lemme see here. Windows 95 is 11 years old. Windows 98 is 8 years old. Windows ME is 6 years old. And Windows NT4 is 9 years old. How many other operating systems offer patches and support product versions for software that is that old?

    Ridiculous.
    • I still have two systems in my house that run Win98 -- because of the applications I need to use. They'll probably disappear in the next two years, but if you look at web logs on a public site, you'll probably see 10% of the browsers are still coming from Win98.

      It's not dead yet. You just wish it were. ;)
    • still in use (Score:5, Interesting)

      by Anonymous Coward on Friday January 13, 2006 @02:30PM (#14465431)
      The 98 series and NT4 are still in widespread (millions and millions) use. This is called a "problem" then. The auto industry in the US tried to pull this stunt of obsoleting and stopping support for their products in short time frames (sometimes within the SAME model year!) and got legally smacked down for it. Now they are required to provide replacement parts for ten years. Just because normal business productlaws and warranties aren't applied to software-yet, and they certainly should be-doesn't mean it wouldn't be a good idea. Planned obsolesence and forced upgrades might be a spiffy way for some corps to extract a lot more dineros from your wallet, but it doesn't mean it's a good idea for you the consumer/end user...unless you are a pure "caveat emptor" anything-goes styled capitalist. Thankfully, most people see the illogic in that sort of system and that is why we have evolved some consumer protection laws. It is not a perfect solution, but it is light years ahead of legalised snakeoil like it was before. Eventually these sorts of laws will be applied to software,because even the dullest clicker is starting to bingo to the fact that most of this forced upgrade stuff is a cash cow dodge.
    • Sun and HP for two (Score:5, Informative)

      by Secrity (742221) on Friday January 13, 2006 @03:03PM (#14465717)
      "Windows 95 is 11 years old. Windows 98 is 8 years old. Windows ME is 6 years old. And Windows NT4 is 9 years old. How many other operating systems offer patches and support product versions for software that is that old?"

      I know of at least two. Both Sun and HP still provide support or patches for versions of UNIX System V that are older than Windows 98.
  • by digitaldc (879047) * on Friday January 13, 2006 @02:09PM (#14465228)
    If it is intentional, I don't see how it possibly got past the Microsoft Security Engineers.
  • by criznach (583777) on Friday January 13, 2006 @02:14PM (#14465281)
    My question is this... If the guy is smart enough to know that windows has kicked off a thread and executed his code, and he's smart enough to experiment with buffer-overflow exploits, why hasn't he stepped through the WMF interpreter code? Could it be that he doesn't want to admit that he has for legal reasons? I know that if I had discovered this problem, that's just what I would do. Call DebugBreak() and you have a call stack. You'd think that the handler for this SetAbortProc function would be pretty identifiable. So... Who's got the balls (or the time, in my case) to do it? That's our answer. Chris.
  • by RequiemX (926964) on Friday January 13, 2006 @02:14PM (#14465286)
    Most backdoor hole problems can be patched with the application (of) Preperation H.
  • by ErMaC (131019) <ermacNO@SPAMermacstudios.org> on Friday January 13, 2006 @02:15PM (#14465295) Homepage
    While the guy makes some good points, there's one point I think he's overlooking. He claims motive for this would be to allow Microsoft or someone else to get into older/current Windows systems as an intentional backdoor...

    If that's the case, they chose a dumb place to put it, because the exploit doesn't even work on Windows 2000 and below without some program installed to handle WMF files. From Larry Seltzer's blog (linked from F-Secure):

    http://blog.ziffdavis.com/seltzer/archive/2006/01/ 03/39684.aspx [ziffdavis.com]

    Except for Windows XP and Windows Server 2003, no Windows versions, in their default configuration, have a default association for WMF files, and none of their Paint programs or any other standard programs installed with them can read WMF files. One ironic point to conclude is that not until their most recent operating system versions did Microsoft include a default handler - the Windows Picture and Fax Viewer - for what has been, for years, an obsolete file format. And now it comes back to bite them.

    That means that unless Microsoft used some OTHER backdoor to install a handler for it, this backdoor is useless. I suspect this is merely an oversight on their part, and that it just ends up looking bad when you view it from the outside. The only way to know is to see the source code and well, we know how likely that is.

    A real backdoor would be something remotely exploitable via the network, as opposed to hiding inside a file or something like that.

  • Not sure... (Score:3, Insightful)

    by BRSQUIRRL (69271) on Friday January 13, 2006 @02:21PM (#14465352)
    This looks weird but it still needs more research, especially given Gibson's somewhat dodgy reputation.

    1 as an input value is one of those classic boundary conditions that developers should always specifically test against (but sometimes don't...along with 0, negative numbers, MAX_whatever, etc)...so I'm not convinced that it was just a coding error. If the "magic key" length was something completely random like 6385492, then I would be more suspicious.

    C'mon MS...let's see the code!
    • Re:Not sure... (Score:3, Insightful)

      by Dachannien (617929)
      Your supposition would require that no record in a WMF file could be 6385492 words long - or, more specifically, that there is a known maximum less than the maximum storeable value. As Gibson mentioned, the minimum record size is 6 words, which frees up the values 0 through 5 to be chosen as your magic key (or perhaps negative numbers if you use signed values for the record size). Picking one of those values would have been a lot quicker than trying to construct a maximum sized record and determining its
  • by blair1q (305137) on Friday January 13, 2006 @02:28PM (#14465414) Journal
    posting a URL on /. causes the server to crash?
  • by matman (71405) on Friday January 13, 2006 @03:15PM (#14465831)
    Having read the whole thing, I do think that Steve may be jumping to conclusions a bit too quickly.

    I think that we ARE talking about the SETABORTPROC vuln that everyone has been talking about; Steve just finds that the vuln doesn't work quite the same way that he was expecting. It seems that Steve is basing his accusation on the fact that he had to set the length field of the code containing WMF record to 1 (an illegal value) in order to get his code to execute. While this seems odd (and sounds like a "magic value"), there is likely a better explanation. Here's one possibility... The advisory from Secunia at http://secunia.com/advisories/18255/ [secunia.com] says that the embedded code executes when any error is detected in parsing the WMF file (not only [or ever?] when canceling printing). Maybe the SETABORTPROC function was originally intended for printing but was overloaded to handle parse error callbacks? Depending on how the parsing code was written, it may treat the invalid length value as such a parsing error, but may have already indexed the the beginning of the code block (since it knows the length of the record header) - it just doesn't know when the code block ends. It can then start executing the code block, even though it is an error in the code block's record that caused the error. I wonder if the code block would execute if the correct length was specified but the NEXT record in the WMF contained a similar error (like an invalid length field).

    He may very well be correct that someone has intentionally included this mechanism as a backdoor, but he is being premature in making such claims without first consulting the people who have a lot more experience with this vuln than he does. By the way, MS gives access to their source code to a LOT of outside parties - I'm sure that Steve could have found someone to take a look for him.

    I don't mean to make an ad hominem attack (this podcast is actually fairly accurate - just jumps to conclusions), but Steve isn't exactly known for being a respected researcher in the security industry - he's a bit of a poser and sensationalist/alarmist. My gut feel is that Steve is continuing on his sensationalist streak, jumping to conclusions and trying to drum up more excitement. He frequently hypes issues to crazy levels and tries to make himself look like a hero/expert. In fact, he usually offers little insight and often tries to pass off regurgitation (often inaccurate) as original research. Just listen to him in this recording talking about "rolling up his sleeves" and "wrote all my own code", etc. Look up his stuff on nano-probes (http://grc.com/np/np.htm [grc.com]) for some funny stuff. I am a security professional and can tell you that much of his writing is BS and/or hyped/obfuscated wording for technologies and techniques that have been in common usage for years and years before he writes about them. I just can't help but take Steve's claims with a grain of salt.

It's time to boot, do your boot ROMs know where your disk controllers are?

Working...