BHO and dlls

[rcgreen]

I wonder who had the bright idea of letting one program (the BHO)
trespass on the memory image of another running program (Internet Explorer)
without generating a seg fault. It violates basic multitasking theory,
but BHOs are <snicker>so useful, and provide such wonderful
functionality.</snicker>

[ildjarn]

I wonder who had the bright idea of letting one program (the BHO)
trespass on the memory image of another running program (Internet Explorer)
without generating a seg fault. It violates basic multitasking theory,
but BHOs are <snicker>so useful, and provide such wonderful
functionality.</snicker>

From the 2 articles posted it wasnt saying that it was writing into the ie processes memory, it was rewriting some dlls back to unpatched versions so that it becomes vuln again, dlls are just files like .so's which as the necesitation of tripwire proves get over written by things all the time in nix systems, i mean hundreds of rootkits exist for linux that rewrite system functions, its the same prinipal in play.

Windows memory managment will not allow you to write to other processes localmemory however there is a small amount of global memory (i think its a page in windows) that all applications can write to but it is limited so not many applications will take advantage of it, got a heap for storing data.

[rcgreen]

The BHO just modifies Internet Explorer’s image which means that no files are written to the disk. In other words, such a machine will look completely patched to Windows

Maybe I'm misinterpreting this, but that's what this person seems
to be saying. I assume that a BHO is allowed to rewrite IEs memory
because IE is designed to permit it. I was being facetious about
memory management, because this vulnerability, like all of Windows
vulnerabilities, was put there deliberately, because they thought
it was a good idea at the time. They never dreamed that anyone
would ever write a malicious BHO.

[nihil]

Hmmm,

The way I understood it was that a lot of applications have files that they load or use when they are started. After that they do not use the original file until the next restart.

At this point in time the original file is vulnerable as the system does not have a lock on it, so you just replace them with older, vulnerable versions.

AFAIK Windows doesn't actually check its files for updates, it has some sort of table with the patches that have been applied. So, to Windows update and other tools that use this table, it seems to be up to date, even though the patch has since vanished.

[rcgreen]

If, as they say, the various DLLs used by IE appear to be the latest
patched versions, the BHO loads the older unpatched code at the time
you open IE, not from the good DLLs, but from itself. The only way
to know you are infected is if you happen to be informed that this BHO
is a bad guy. It doesn't modify the files, but loads the code at runtime.
So it's a combination of problems. Users shouldn't install every BHO
that is advertised free on the net. But it's also a design issue. IE is designed
to allow BHOs to modify the way it acts, and they are way too
easy to install. Who needs seventeen toolbars and assorted "download managers"?