Can anyone here render an opinion as to whether or not there is any validity to the following statement - and if there is none, then how would you compose a rebuttal?

===========
IE was *NEVER* properly ported to work within Win9X, *it was DESIGNED for the NTs* [the transitional browser Microsoft ALWAYS produces prior to releasing/for a new OS]. Since DAY ONE there have been missing function calls in 9X within IE6 *WHICH ARE NECESSARY FOR FULL SECURITY FUNCTIONING*. One of the KEY elements is the user environment [usrenv] which INCLUDES the security hooks to other NT ONLY security functions ONLY available in those environments. The errors are REPRESSED in 9X, however they DO EXIST.
===========

Yeah... right. Just like motorcycles fail to work right because they lack two more wheels...


Remember: motorcycles and cars, just like the NT and 9x families of OSes, are widely different animals, that's all.

I think it's more than just an issue that these IE file substitutions work (on the surface) on win-98 systems.

The underlying issue is - can IE work as well (from a security or invulnerability POV) on win-9x with these updated files vs an NT-based OS.

The root question revolves around the belief that IE was never properly "ported" to 9x (what-ever that means). The author of the quoted material went on to state that:

"One of the KEY elements is the user environment [usrenv] which INCLUDES the security hooks to other NT ONLY security functions ONLY available in those environments. The errors are REPRESSED in 9X, however they DO EXIST."

The above comment was raised (in another venue) as a response to the idea of transplanting updated IE files from win-2k patches into win-98 systems. I think the take-home message that the author was getting at was that even if the updated files have patched known IE vulnerabilities, the end result would be that a win-9x system running IE6sp1 would not be as "secure" as a win-2k system because of the deficient "porting" of IE to win-9x systems - the roots of which would presumably be 5 to 8 years ago.

As if it would take _more_ than just substituting some IE files on Win-9x in order to truly resolve the underlying vulnerabilities.

I find that logic hard to accept. I don't see where IE6 was any more secure or any less vulnerable to being exploited on an NT system. If anything, the opposite is true IMO. The browser is a major part of the attack surface. The more that browser is integrated into the OS, the more the OS itself becomes part of that attack surface. IMO, 9X systems are more resistant to attacks from the web when IE6 is not used. IE6 has been replaced on all the newer versions of Windows with IE7 and IE8. With security app vendors dropping 9X support, it makes no sense to continue using a vulnerable and obsolete browser when more secure and up to date browsers will run on 9X systems.

Presumably, Microsoft is still patching IE6 because it is still supporting Win-2K, and because of it's decision to (artificially?) prohibit IE7 from being installed on Win-2k, hence the necessity to keep patching IE6.

> IMO, 9X systems are more resistant to attacks from the web when IE6 is not used.

Is that still the case - given this recent security roll-up?

Are you saying that given these files, that a win-9x system would remain vulnerable to web-based exploits compared to win-2k when running IE6 as the browser?

Is there any vulnerability pathway that would still utilize these IE components even if an alternate browser was used?

I haven't looked into the latest IE security updates, what they specifically patch, and where 9X system stand in relation. At best, they fix a couple of specific problems. IE6 can't be made secure with patches and updates. It's been being patched for many years and is no more secure now than it was a few years ago. If ActiveX is installed, IE6 becomes that much more vulnerable.

That would depend on whether 9X systems were vulnerable to the specific exploits to begin with. In the last few years, a fair percentage of new exploits that XP was vulnerable to didn't affect 9X systems. It also depends on the payload they try to deliver through the exploit. At present, a lot of the delivered malicious code is rootkit material, which rarely affects 9X systems. Rootkits are possible on 9X systems, but the percentage of them on the web is small enough that it's not worth writing code specifically for them. On the other hand, if the code specifically targets IE6, it may well work on a 9X system.

There's several. PDFs, java, media files and Flash are some that come to mind. These can be a bigger problem for 9X users than they would be on newer systems, mainly because 9X users often have to use older versions with known vulnerabilities. The 9X compatible version of Adobe Acrobat is one example. Specifically crafted commands can be added to files in these formats that will start IE6 and can send specific commands to it, such as go to a specific server and download and execute a file. I believe that MS office documents can also be used for this. Not browsing with IE6 reduces the risk of its being exploited, but to eliminate the risk it either has to be removed or completely blocked from executing. The policy editor and HIPS software are two options for controlling the activities of Internet Explorer and the other software that integrates with it. A software firewall can also prevent IE from gaining web access regardless of what launches it.

Indeed it's artificial from a functionality standpoint (I was able to get IE8 working on W2K with some hackery during the betas), but Microsoft doesn't want to pay to support writing new code on a platform they've already retired to their extended support sustained engineering group (read security updates but no bugfixes). If there are bugs introduced to the platform with IE7 (and trust me, IE7 nor IE8 after being hacked down worked well, but they did work) then Microsoft would have to pay someone to follow up with code fixes, make sure it's tested across the myriad of platforms they support, possibly multiple patch levels for systems that could apply the updates, etc. Even if IE7 had released in 2004 or 2005, we probably wouldn't have seen it for the platform - IE6 on W2K didn't get any of the XPSP2 updates that IE6 got on XP, and that was actually done while W2K was in mainstream support and was getting new packages.

This is retarded. IE5 and up come with NT API emulator which implements all missing APIs required for IE on 9x platforms (mostly Unicode functions). No, IE is not tied to NT security model (at least before SP2).

I'm going to post here the arguments made by a certain person that claims that IE6 either was never properly designed for or could never properly run on win-98 because it's various security mechanisms were designed with NT-based OS's in mind. These comments were sparked by the suggestion that file substitutions from the last win-2K ie security rollup are viable if not effective for win-98.

He claims that some supporting material can be found here:

http://peoplescounsel.org/ref/gen/ie_XPfiles_errors.htm

And here is a summary of what he said recently. Again, all I'm looking for is material to use to counter his claims.

He starts by responding to the "delay-load dependency module was not found" and "module has an unresolved import due to a missing export function" errors:

---begin quoted material---

NOW spend a little time trying to figure out WHY those exist...HINT - What other files were necessary to modify to *ALLOW* the installation and usage of IE6 in Win9X?"

Then figure out [hint - actually look at] the updates installed ONLY FOR IE6 and their relationships - HINT - WHY were these files necessarily and constantly modified to ONLY work with IE6?

When you get that figured out [though I doubt you will] go back through the updates to the LAST browser designed for the 9X/ME OSs and what those contained. HINT - the files necessary for IE6 usage were NOT installed nor were they constantly modified throughout the IE6 support era.

When you get through all that WITH the proper knowledge and understand of the inter-interoperability and relational characteristics {which in your case will not occur} ponder upon *WHY not installing IE6* still allows the 9X system to function as it was designed and should... whereas AFTER installing IE6 even such basic elements like copy and moveare affected.

SHOW YOUR LINKS TO NEW DEPENDENCY WALKER *PROFILING* LINKS AFTER INSTALLING THESE PURPORTED UPDATES. Make sure to include profiles for IE6, Explorer, and some of the other generally installed, like Office.

HOWEVER, since merely showing installation ability proves nothing of value to the 9X user unless these files actually perform some function:

SHOW YOUR LINKS TO TEST RESULTS WHICH ADDRESS THE SUPPOSED FLAWS AFFECTING THE 9X/ME OSs WHICH HAVE BEEN CORRECTED WITH THE INSTALLATION OF THESE PURPORTED UPDATES USING 9X/ME SPECIFIC TESTS.

---end quoted material---

That's not how it works! We have no duty whatever of showing your unnamed contender anything. Let him/her do his/hers homework and provide evidence of flaws or exploits that *actually* can run in Win 9x / IE6 SP1 patched to the utmost, but which cannot harm Win 2k / IE6 similarly patched to the utmost. Until such evidence is presented, I really think we have more pressing busisness that to be led by the noses into doing extensive security testing for free for an unknown third party. He/she, in my view, is nothing more than a provocator, and, as such, ought to be disregarded.

The person in question has a history of demanding negative-proof. In other words, if the use of win-2k IE files on a win-98 system is proposed, he will ask for proof that there are NO problems caused by the files. I believe it's impossible to prove a negative - which means the discussion usually ends in a stalemate. It has been asked many times, but the person will never post evidence of a positive occurance of something that proves his point.

I was not expecting that anyone here should perform any of the tasks he describes. I was hoping that someone could make sense out of the first 4 paragraphs and comment on them.

It makes no specific sense at all. In fact, when one installs IE7 on Win XP, dependency walker finds the same types of unsatisfied dependencies, because IE7 was created to run both on XP and on Vista. And since both are NT-Family OSes, his/her central argument is flawed. All these missing dependencies just show that dependency walker is not a very bright software piece, that was created before those types of dual-use files even existed and it knows nothing about them, and hence yields false positives. That's all there is to it. Nothing more.

What does he mean by "What other files were necessary to modify to *ALLOW* the installation and usage of IE6 in Win9X?" ???

Are there any such system files that are replaced when IE6 is installed on win-98?

Yes. shlwapi.dll and shfolder.dll come immediately to mind, but there are others. That's the meaning of "integrated". IE6 is not a standalone browser. Then again, I fail to see what's the relevance of it. The unofficial updates, MDIECU, for instance, only update files that already existed in IE6SP1, which was released when Microsoft still supported fully Win 9x/ME, so that any major modification to the system was made at installation time, not at update time. While there were many issues with IE6 SP1, I'm sure it's not "essentially flawed" neither on 9x-family, nor on NT-family OSes. It was superceeded on the NT-family OSes, but for the 9x-family it is the most up-to-date MS browser that can be used. You either decide you can live with that, or drop it and use a third party browser, but part of IE6 cannot be removed without crippling the system, so you're stuck with it, whether you like it or not. The unofficial updates, at best, make it more secure. But surely they cannot render it more insecure: at worst it remains as secure as it was to begin with.

You'll have to get this person to define "properly". If he means "works properly, browses web pages, and loads activex controls just like XP and 2000", then the statment is patently false - IE6 was ported back to Win9x properly. If he means "isn't as secure on Win9x or Windows 2000 as it is on Windows XP SP2 and higher", then he is somewhat correct. There are additional security mechanisms in place that are specific to running IE6 on Windows XP with Service Pack 2 or higher that do not exist downlevel in IE6 on Win9x or Windows 2000, although this doesn't make IE6 "SP1" (which is what IE6's version is for Win9x and Windows 2000) any less secure that it was when it was originally built and ported back in August of 2001 - it just makes it not as secure as it would be if the user was running IE6 on Windows XP Service Pack 2 (this is IE6 "SP2", and will indeed only run on XP systems).

Your unnamed source is going to have to provide some proof of this - I believe he's probably comparing IE6 SP1 on Win9x with IE6 SP2 on Windows XP SP2, rather than comparing IE6 SP1 on Win9x with IE6 SP1 on Windows 2000 or Windows XP RTM or SP1. The OS shell depends on IE6 to be installed to perform functions, NOT the other way around - IE6 will behave similarly on an NT-based platform like Windows 2000 or Windows XP as it would on a Win9x platform like Windows 98 or Windows ME, because the browser functionality itself is NOT dependent on the underlying OS.

There's not much more to discuss - the shell relies on IE, not the other way around, which is the common misconception most people have about the integration of IE into the Windows OS. A lot of people assume IE relies on Windows components for functionality, and the truth is actually the reverse. Sure IE6 relies on OS APIs to handle operations like writing files to disk, accessing the sockets layer to transmit packets, etc, but so does every other application that runs on Windows - IE is not special in this regard. However, IE self-contains all of the browsing functionality needed by the browser, and as such I cannot understand how one could assume IE6 is less secure on Win9x than it is on Windows 2000 or Windows XP RTM or SP1. There is no *browsing* feature that IE6 does on Win9x that it does *any* differently on Windows 2000 or Windows XP RTM or Windows XP SP1.

With that, there really isn't anything further to discuss about the initial post. If there were specific questions, or specific points of statement of fact to address, we could probably discuss further. Otherwise, the answers here are likely the best answers you're going to get.