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

 



Forgot your password?
typodupeerror
×

Two Unofficial IE Patches Block Attacks 233

Pentrex writes "eWeek reports that two well-respected Internet security companies (eEye and Determina) have released unofficial patches to correct the vulnerability being exploited to load spyware, bots and Trojan downloaders on Windows machines. Microsoft isn't sanctioning the third-party patches, which include source code for review. As always, the advice is to weigh the risks before opting for an unofficial hotfix."
This discussion has been archived. No new comments can be posted.

Two Unofficial IE Patches Block Attacks

Comments Filter:
  • by NilObject ( 522433 ) on Tuesday March 28, 2006 @09:28PM (#15015009)
    There's two other patches out there that work pretty damn well:

    1 [apple.com] and 2. [mozilla.com]
  • Free as in... (Score:3, Insightful)

    by HolyCrapSCOsux ( 700114 ) on Tuesday March 28, 2006 @09:30PM (#15015013)
    Some folks would like you to believe that free as in beer software is a horrible thing.

    The question is, would people patch if they had to pay for them?

    • Re:Free as in... (Score:2, Insightful)

      by monkaduck ( 902823 )
      If they were told to, yes. Never underestimate the lemmingness of the human species.
    • Re:Free as in... (Score:3, Interesting)

      by Arandir ( 19206 )
      In an old interview Bill Gates said, and I paraphrase, "people don't pay for bug fixes." This explains a lot.
    • Yes, history proves this:-

      Windows 3.1
      Windows 98
      Windows ME (Bwah ha ha)
      Windows XP
      and ultimately Vista.

      People will pay for bug fixes if you market them well enough...

      • You forgot Windows 95 a/b/c and Windows 98SE but who keeping track. Actualy Windows 95 might be stretching it because they m,ostly taunted new features and easier hardware instalations but i guess that would fix the old config.sys and having to get the IRQs correct and all.
      • Wowzorz. Newer operating systems are not "bug fixes" for older ones. Believe it or not, Windows XP has a few more features over 3.1...

        • Re:Bug fixes (Score:3, Insightful)

          XP has relatively few new features over Windows 2000 which is why I didn't list Win 2k (Or Windows NT for that matter)

          Win 3.1 was an (admitedly significant) upgrade of 3.0 which they charged for.

          Similarly 98 was incremental on 95, 98SE on 98, Me on 98SE all of which you had to pay for yet none of which offered significantly more than bug fixes & drivers.

          That's my point.

  • by El Cubano ( 631386 ) on Tuesday March 28, 2006 @09:33PM (#15015026)

    As always, the advice is to weigh the risks before opting for an unofficial hotfix.

    Is this not something that smart admins/companies so even with official patches and fixes? To me, the fact that the source was released shows that these people are quite serious about being taken seriously. I suppose that is better than MS assurances that they extensively tested the fix before release.

  • by MoxFulder ( 159829 ) on Tuesday March 28, 2006 @09:33PM (#15015030) Homepage
    I don't even understand how they manage to *write* third-party patches. I mean, it must be hard as hell to do without the IE source code. I think they write a separate DLL which acts as an intermediary to the flawed insecure library or something, but it sounds like an enormous pain-in-the-ass process. Or do these companies have access to MS code through Shared Source program or something?

    Yep, the more I watch the ills that befall the Microsoft-bound, the more I'm happy with my decision to go Linux-only a few years back.
    • by Anonymous Coward on Tuesday March 28, 2006 @10:02PM (#15015141)
      We certainly don't have access to Microsoft source code. I ran Internet Explorer in a debugger and traced through the execution of the exploit (which was publicly available at this point). Most memory corruption vulnerabilities result in an exception, which is caught by the debugger. Once you have the location of the exception, you can identify which function the vulnerable code is in.

      Once I had the name of faulty function, I disassembled it using IDA Pro and found the bug by reading the disassembly. With enough reverse engineering experience reading disassembled code is not much harder than reading C source code. It just takes longer.

      The IE vulnerability is caused by a funcion called with incorrect parameters which returns SUCCESS instead of an error code. The caller belives that the function suceeded and tries to use an uninitialized variable. The patch is a single byte change in mshtml.dll. The patched function now returns a valid error code and the vulnerability is stopped.

      This free patch is just a demonstration of what we do every month as part of our LiveShield product. It is a lot more advanced, but the idea is similar. We use the vulnerability analysis techniques described above to create "shields" that detect and stop specific Microsoft vulnerabilities. The coolest part is that the shields can be inserted and removed at runtime, without having to reboot any of the running applications.

      Alexander Sotirov
      Security Research
      Determina Inc.
    • by romka1 ( 891990 ) on Tuesday March 28, 2006 @10:03PM (#15015146) Homepage
      "The fix is a DLL that gets injected into all applications via the AppInit_DLLs registry key," Sotirov wrote in a message posted to security mailing lists. He said the DLL fixes the bug by patching a single byte in MSHTML.DLL when it is loaded in memory. "This change makes the 'createTextRange()' function return an error code instead of returning 0. This exactly how the problem was fixed in the latest IE7 beta from March 20," Sotirov explained.
      from the article
  • by WillAffleckUW ( 858324 ) on Tuesday March 28, 2006 @09:33PM (#15015031) Homepage Journal
    Of course, I'll probably be retired before they're out.
  • weigh the risks (Score:3, Insightful)

    by enrevanche ( 953125 ) on Tuesday March 28, 2006 @09:35PM (#15015038)
    Certainly you should weigh the risks with any patch but since an "official" patch would come from the originators of the flaw (and numerous others) why should it be considered any better than an "unofficial" patch? At least these patches can be scrutinized by the outside world for problems. A MS patch will be forever hidden. The perils of closed source!
    • Because if an official patch breaks your OS, you can get help for it from Microsoft. More people call MS for support than you'd think.
      • Are you serious? Have you ever actually called Microsoft to see what happens when one of their patches break... One or more of the following:
          - Reinstall windows with no 3rd party apps. Install patch, still broken - refer to your dealer for a hardware issue
          - The above and it breaks after 3rd party app is installed - refer to the 3rd party vendor
          - etc. etc.
      • >>Because if an official patch breaks your OS, you can get help for it from Microsoft.

        Yeah. I called microsoft tech support after Windows decided not to boot after I upgraded IE, and they told me I could pay them $200 for help. I'm thinking that relying on MS to help you if somehting breaks is a bad plan.
        • I have never called microsoft outside an install issue. I have had bad CDs out of the box, had to get new product numbers because windows XP wouldn't activate, and old NVIDIA drivers causing the install to crap out.

          You get free install support but have to pay after a certain time. Everything else can be fixed by searching the interweb thought. You some times have to go deep into the search before you find somethign usefull. There seems to be alot of incomplete errors out there in a seach were someone either
  • by E IS mC(Square) ( 721736 ) on Tuesday March 28, 2006 @09:35PM (#15015042) Journal
    Given the fact that the average IE user would not even be aware of the flaw, how would he even know such third party patches even exist?

    Most of them are going to be patched only when MS releases the patch, AND they have selected to be updated automatically.

    Its a horrible situation.
  • by dtfinch ( 661405 ) *
    If third parties can regularly patch your bugs before you do, without access to the source, after giving you a generous head start... Well, I guess that could mean a lot of things. They're definitely lazy, to say the least.
    • If by "lazy" you mean "they need to test every single change made to their software extensively, and don't have the luxury of being able to throw out third-party hacks with no long-term support requirements", then sure they're being lazy. You'll notice that they're fixing both these issues with their monthly updates on April 11th(I think?) if you look around.
    • by tshak ( 173364 )
      ... or they run through rigorous tests since they have to answer to millions of customers on millions of different system configurations. I'm not saying that MS shouldn't be faster about patching, but they have improved their turnaound and there's only so much you can do if you care about rigorous quality assurance.
    • by patio11 ( 857072 ) on Tuesday March 28, 2006 @10:26PM (#15015245)
      Microsoft releases one patch day a month because their corporate customers, the lion's share of their market, demand it. And they demand it because "release a million little patches as soon as that individual patch is done" is unworkable in a corporate environment. You can plan around one big patch a month -- the magic word is "scheduled downtime". It is less bad for some customers to be periodically marginally more vulnerable for a period of two weeks or so then to be continusouly vulnerable to unscheduled downtime due to patching. "Publish early and often" works well with an enthusiast running one machine but when you've got an IT department overseeing a cast of thousands spread over 14 time zones things get a little more dicey.
      • Isn't that what Windows SUS is for?
        • Yes, but it's hard to predict what patches require reboots and what patches will subtlely change certain services. And Windows Software Update Services normally isn't applied to personal machines and personal laptops and production services managed by third parties: scheduling one day a month to risk important services and make sure your IT staff is ready to stay late and roll things back out if they break is pretty important.
      • If a company wants to wait to install patches on a fixed schedule, long after the patches have been released, nobody can stop them. There is some benefit to patching unpublicized vulnerabilities on a schedule, but if the details of a vulnerability is already public knowledge, then there's nothing to be gained by any of Microsoft's customers by delaying the availability of a patch.
      • by apoc.famine ( 621563 ) <apoc.famine@g m a i l . com> on Tuesday March 28, 2006 @11:43PM (#15015518) Journal
        I'm missing the part where the sense is....If MS released all patches as soon as they were ready, everyone who wanted to patch right away could. If large corporate IT depts still want to patch every 2nd tuesday, they still can! Scheduled Downtime is Scheduled Downtime is Scheduled Downtime. I see no connection between when MS releases a patch and when an IT department schedules their downtime to roll that patch out. (Well, other than the fact that the patch has to come first. ;)

        This whole "scheduled patching" bit really is BS. All it does is leave critical problems unpatched longer than necessary, so that managers can point to MS when bad shit happens to the network. "Well, we couldn't patch until two days after patch-day, because we needed to test the patches." works lots better than "We got fucked because I decided that it wasn't critical enough to test and deploy right away."

        While I can see where it would make a lot of people more confortable to know that there is patching every third Wed or something, I just don't see the value in withholding critical patches because "they aren't scheduled yet". At the very worst, let the IT departments decide if they want to schedule additional downtime, because ultimately, they know whether it will affect their systems or not. But then again, MS knows best, all the time, doesn't it?
        • The *theory* is most exploits occur AFTER a patch is released by Microsoft (reverse engineer the patch). As a result, by scheduling a time the patches are released, it allows IT departments to schedule time to review and deploy the patches in a timely manner.

          The issue arises when exploits are known in the wild before the patch is available. When is a suitable time to release the patch? How big of a risk does a exploit need to be before it is considered critical enough to justify an out-of-schedule patch rel
        • But then again, MS knows best, all the time, doesn't it?

          It doesn't matter what MS does or doesn't know, their customers have demanded it.
      • by Anonymous Coward
        No, applying patches is not free. But you are missing the point. If patching was a fairly rare occurrence, then it would not be nearly the problem that it is. release a million little patches as soon as that individual patch is done - you probably thought that was an overstatement; it is not. Microsoft just patches far too much to make updating their products anything but a continual hassle.

        From descriptions of the fix elsewhere here, it is a stupid mistake that never should have made it through any kind of
      • " Microsoft releases one patch day a month because their corporate customers, the lion's share of their market, demand it."

        The customers demanded less security holes that demanded patches, not less frequent updates of critical security fixes. It also helps polishing the statistics if you lump several patches together and release them all at one day every month. Big corporations dont use Windows Update without testing the patches either. Even if Microsoft release all the patches fast when they are ready big
  • Are there likely to be any conflicts or issues when Microsoft issues official patches that overwrite or only partially overwrite changes the patch made?
  • Who exactly is going to be using these patches? Think about it for a moment, since when did security savvy computer users, let alone experts, use IE?? True they may fire it up to go to a specific site or two that requires it or works better with it, but for general surfing? I don't think so. Anyone with the good sense God gave the common radish is using Mozilla, Firefox, Opera, or in the case of Macs Safari.

    I can see a use for these patches in a corporate environment where (for whatever reason) IE is a
  • Tested and deployed (Score:3, Informative)

    by ninja_assault_kitten ( 883141 ) on Tuesday March 28, 2006 @10:25PM (#15015235)
    I had our IT department test and deploy the silent installation this morning. We're a web-based software company and there's been zero reported impact to our development staff as 6pm EST.

    While it's clearly not the best solution, it does work and provides a much needed layer for the vast majority of corporations who simply cannot and will not disable active script.
  • well (Score:3, Funny)

    by Trailer Trash ( 60756 ) on Tuesday March 28, 2006 @10:32PM (#15015272) Homepage
    As always, the advice is to weigh the risks before opting for an unofficial hotfix

    Anybody who has the ability to weigh risks is already using firefox.

  • As always, the advice is to weigh the risks before opting for an unofficial hotfix.

    Of course, Microsoft [computerworld.com] and other vendors [72.14.203.104] always get their patches correct the first time.

  • In memory fix (Score:5, Insightful)

    by roman_mir ( 125474 ) on Tuesday March 28, 2006 @10:57PM (#15015361) Homepage Journal
    the patch fixes the affected DLL in memory by overwriting a byte that is stored in RAM for MSHTML.DLL this begs a freaking question, should a modern OS even allow some application to modify behaviour of another application in memory, especially behaviour of a system level application, an OS DLL? I believe the patch needs to be installed from an administrator account, but even then, this doesn't mean that it is good design decision, to allow an arbitrary application to overwrite in memory code of another application. Of-course if that wasn't possible this specific patch couldn't exist, but still, the OS allows questionable application behaviour to say the least.
    • this begs a freaking question, should a modern OS even allow some application to modify behaviour of another application in memory, especially behaviour of a system level application, an OS DLL?

      Rememer please, this is windows we are talking about. How would anyone write viruses and pervasive spyware without this feature?

      (lets all say it together, this is not a security hole / bug, it's a feature )

    • Re:In memory fix (Score:3, Interesting)

      by Zenki ( 31868 )
      Then how do you expect debugging to work? Pretty much all OS's offer an API to let the debugger read/write bytes from program memory. A similar hack could be done on Linux by writing into /proc.
      • Re:In memory fix (Score:3, Interesting)

        by roman_mir ( 125474 )
        Then how do you expect debugging to work? Pretty much all OS's offer an API to let the debugger read/write bytes from program memory. A similar hack could be done on Linux by writing into /proc. - debugging could be done in read only mode, but if necessary it could be done in a simulated (virtual machine) environment without such security restrictions. You cannot insist that this 'feature' is a good thing for application security.
        • If someone untrusted has admin access to your machine, it's really game over for security. They can replace applications, dlls, run programs and change settings at will, they don't need to go to the trouble of replacing a running dll with a specially patched version via this API.
    • this begs a freaking question, should a modern OS even allow some application to modify behaviour of another application in memory, especially behaviour of a system level application, an OS DLL?

      OpenBSD has W^X built-in, which, in-fact, elminates this. Each segment of memory is exclusively marked as either WRITE or EXECUTE, to prevent security exploits.

      Linux can also get somewhat similar security features using PaX or ExecSheild.
    • Re:In memory fix (Score:3, Interesting)

      by baadger ( 764884 )
      This 'patch' isn't accessing or modifying the memory of 'another application'. What these vendors have created is a DLL that can be loaded by an application to patch the mshtml dll instance in memory for the application in which it is loaded.

      Next they use the AppInit_DLL registry key, which essentially forces the Operating System to load this DLL into all applications that link against user32.dll (I think), hence no hackery is going across address space boundaries, there is nothing wrong with self modifying
  • Anyone remember? (Score:5, Insightful)

    by WalterGR ( 106787 ) on Tuesday March 28, 2006 @11:12PM (#15015404) Homepage

    Does anyone remember the previous third-party patch to IE? This is from December of '03.

    Slashdot: "Open Source Firm Releases Patch for IE Bug [UPDATED]"

    An open source and freeware software development web site has released a patch to fix the URL spoofing vulnerability in Internet Explorer... Update: Sadly, the patch appears to contain a buffer overflow and some possibly-malicious code. (link [slashdot.org])
  • opensource? (Score:4, Interesting)

    by sumdumass ( 711423 ) on Tuesday March 28, 2006 @11:15PM (#15015416) Journal
    It would be interesting to see microsfts official patch when it becomes availible and attempt to see how close it is to these unofficial patches.

    Maybe the code would be completley different but would it achieve its goal by going about the same ways as the unofficial patch? Or would it be patched on a level deeper then we could access. I guess the most interesting part would be that a third party without access to the source code could actualy come together with a solution before microsoft. What would be more interesting is seeing how close those solutions match match each other. Sort of a test to how these third party programers can predict the neccesity or orders of different code they only have limited access to.
    • Re:opensource? (Score:2, Informative)

      by Zarel ( 900479 )
      From the article:
      "The fix is a DLL that gets injected into all applications via the AppInit_DLLs registry key," Sotirov wrote in a message posted to security mailing lists. He said the DLL fixes the bug by patching a single byte in MSHTML.DLL when it is loaded in memory. "This change makes the 'createTextRange()' function return an error code instead of returning 0. This exactly how the problem was fixed in the latest IE7 beta from March 20," Sotirov explained.
  • As always, the advice is to weigh the risks before opting for an unofficial hotfix.
    Well, I'd rather balance between going on with a security hole in my PC and running an unofficial patch to close it.
  • by g0bshiTe ( 596213 ) on Wednesday March 29, 2006 @10:59AM (#15017642)
    I wonder how this makes Microsoft feel, and imagine the embarassment from having 3rd parties release hot fixes (work arounds, or patches) before your release cycle.

    It's like the security community is slapping them in the face and saying that their current model of using patch cycles is not good enough for threats on todays internet.

    In my opinion this makes Microsoft look very bad, this is that I know of the second time a patch has been released for an MS product before an official fix release.

    And they even produce sourcecode for community scrutiny/review.


    To eEye and others making these patches for MS products, thanks guys for making sure my parents don't get inundated by malware.

It is easier to write an incorrect program than understand a correct one.

Working...