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 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.
  • Re:Free as in... (Score:3, Interesting)

    by Arandir ( 19206 ) on Tuesday March 28, 2006 @10:04PM (#15015150) Homepage Journal
    In an old interview Bill Gates said, and I paraphrase, "people don't pay for bug fixes." This explains a lot.
  • by QuantumG ( 50515 ) <qg@biodome.org> on Tuesday March 28, 2006 @10:48PM (#15015339) Homepage Journal
    You should do your work here in Australia. We have laws that guarentee our right to reverse engineer software to fix security issues.
  • 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.
  • by Anonymous Coward on Wednesday March 29, 2006 @12:07AM (#15015632)
    I don't use debuggers as much as you'd think. I prefer to disassemble the code and read it until I understand what's going on, and then confirm it with a debugger. Some other people use debuggers as their primary tool, and resort to disassembers only when they are really stuck. I guess it's just a matter of personal preference and temperament.

    When I do use a debugger, it's usually WinDbg. I like the command line interface and it has very good support for all versions of Windows. A lot of other security researchers use OllyDbg. For kernel debugging I use both WinDbg and SoftIce. SoftIce has the advantage of being able to follow code from user space to kernel space and back, which is very useful for analyzing kernel vulnerabilities.

    Alexander Sotirov
    Security Research
    Determina Inc.
  • Re:In memory fix (Score:3, Interesting)

    by Zenki ( 31868 ) on Wednesday March 29, 2006 @12:11AM (#15015639)
    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 ) on Wednesday March 29, 2006 @12:20AM (#15015672) Homepage Journal
    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.
  • by Anonymous Coward on Wednesday March 29, 2006 @12:27AM (#15015708)
    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 testing that I routinely run my code through. So why the hell did it make it through Microsoft's superior testing that they have guaranteed since making security "job one" [just a hint of sarcasm there].

    Perhaps the problem is really one of testing and verifying the code before it sold to a trusting customer base in the first place! That's right, you heard me; I too am blaming the customer: they fscked up! they trusted Microsoft to actually do something about making their code more secure!
  • Not in a pinch, but regularly. You can't monitor a WSUS server without it.

    Of course, IE on that particular network has a proxy server of 127.0.0.1 pushed out via group policy, with an exemption for the intranet. You could sneak around that by installing a proxy server on the machine you're using, but most of my users aren't that sharp. I've got Firefox 1.5.whatever running on everything now, so I can let my users off the leash a little.

    The only thing I miss about IE is the ability to push settings to the browser via group policy. It's nice to be able to centrally manage an application like that. I haven't found a way to do that for firefox (HINT HINT).
  • Re:In memory fix (Score:3, Interesting)

    by baadger ( 764884 ) on Wednesday March 29, 2006 @05:22AM (#15016545)
    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 code.

    Next you will be asking why this little DLL injection key exists, well it's useful, for making unofficial application patches for one thing, and it has other legitimate uses as well although I believe the key is now depreciated in favour of cleaner methods :P
  • by Anonymous Coward on Wednesday March 29, 2006 @11:44AM (#15017942)
    Extracted from a blog I was reading at http://www.hackdot.org/ [hackdot.org] (related to slashdot?)


    over the past months, I've noticed a trend: A vulnerability is disclosed publicly, usually with PoC exploit code, without informing the vendor, usually Microsoft. Then, all of a sudden, some security company is releasing a 'patch' for this vulnerability that they coded in-house. Said security company gains "the ovation of the people", and lots of free publicity. I'm not sure, but I've got a hunch that the costs associated with anonymously leaking a 0day vulnerability with exploit code and then subsequently releasing a patch for said vulnerability through official, commercial channels, is significantly less than placing an ad on the front page of several major newspapers.... So, financially speaking, it would be a cost-effective marketing strategy to employ, if one were in the position to do so...

    Food for thought, anyhow.

Always draw your curves, then plot your reading.

Working...