3 ms·

You're incorrect. And technically speaking the browser wasn't integrated with the OS (and never was), it was the rendering engine (shdocvw.dll and mshtml.dll).

by ksk 13y ago

You're incorrect. And technically speaking the browser wasn't integrated with the OS (and never was), it was the rendering engine (shdocvw.dll and mshtml.dll). The Windows UI featured HTML elements that the OS rendered via this. The rendering engine is not itself connected to any TCP/IP stack, so remote exploits are impossible. But ofcource if you went to web sites with malicious HTML you could get ownzored because of bugs in the rendering engine. Also you could delete the browser (iexplore.exe) but not the engine as the OS relied on certain UI elements that used this engine. Ofcource if you went ahead and deleted the DLLs anyway, you could make the OS work without the added HTML UI layer (as the judge in the MS antitrust case demonstrated). One could argue that this wasn't the "full" Windows experience but hey.. all that is water under the bridge now. The case is resolved and MS got slapped with a hefty fine.

yuhong 13y ago
Actually IE6 and older tied the IE user interface to the Explorer user interface which shared the same SHDOCVW. IE7 created IEFRAME to separate the Explorer user interface from the IE user interface, but it is still in system32, and so are all the other core IE components like MSHTML, WININET, etc...
- ksk 13y ago
  Are you talking about the UI controls or the browser?iexplore.exe could be deleted at any time. Ofcource because explorer.exe also could handle URLs you could technically still browse via it. (Though I'm pretty sure that by default only URLs in the local/trusted zone were allowed) And then I believe the help component also relied on the rendering engine. Although the hcp:// vulnerabilities were in the protocol handler (helpctr.exe) and the ms-help:// vulnerabilities were also in the protocol handler which allowed the attacker to bypass ASLR/DEP.
  - yuhong 13y ago
    True, HTML Help definitely relies on the IE rendering engine. And yea particularly in IE6 I don't think iexplore.exe itself does very much.
Hrundi 13y ago
> ...But ofcource if you went to web sites with malicious HTML you could get ownzored because of bugs in the rendering engine. It's funny, when the Windows source code was leaked (opened?) in 2004[1], folks soon discovered a vulnerability in the BMP renderer[2]. [1] http://slashdot.org/story/04/02/12/2114228/windows-2000-windows-nt-4-source-code-leaks http://slashdot.org/story/04/02/12/2114228/windows-2000-wind... [2] http://www.securitytracker.com/id/1009067 http://www.securitytracker.com/id/1009067
- ksk 13y ago
  I doubt it had anything to do with the source leak. Most security bugs these days are found via automated means - fuzzing, fault injection, etc. But OTOH these bugs become useful in other ways. I believe there was an ios jailbreak method where you simply visit a website on your iphone (jailbreak.me? .com?) and your device is rooted/jailbroken due to a bug in Safari's PDF renderer.

by ksk 13y ago

yuhong 13y ago

Actually IE6 and older tied the IE user interface to the Explorer user interface which shared the same SHDOCVW. IE7 created IEFRAME to separate the Explorer user interface from the IE user interface, but it is still in system32, and so are all the other core IE components like MSHTML, WININET, etc...

ksk 13y ago
Are you talking about the UI controls or the browser?iexplore.exe could be deleted at any time. Ofcource because explorer.exe also could handle URLs you could technically still browse via it. (Though I'm pretty sure that by default only URLs in the local/trusted zone were allowed) And then I believe the help component also relied on the rendering engine. Although the hcp:// vulnerabilities were in the protocol handler (helpctr.exe) and the ms-help:// vulnerabilities were also in the protocol handler which allowed the attacker to bypass ASLR/DEP.
- yuhong 13y ago
  True, HTML Help definitely relies on the IE rendering engine. And yea particularly in IE6 I don't think iexplore.exe itself does very much.

Hrundi 13y ago

> ...But ofcource if you went to web sites with malicious HTML you could get ownzored because of bugs in the rendering engine. It's funny, when the Windows source code was leaked (opened?) in 2004[1], folks soon discovered a vulnerability in the BMP renderer[2]. [1] http://slashdot.org/story/04/02/12/2114228/windows-2000-windows-nt-4-source-code-leaks http://slashdot.org/story/04/02/12/2114228/windows-2000-wind... [2] http://www.securitytracker.com/id/1009067 http://www.securitytracker.com/id/1009067

ksk 13y ago
I doubt it had anything to do with the source leak. Most security bugs these days are found via automated means - fuzzing, fault injection, etc. But OTOH these bugs become useful in other ways. I believe there was an ios jailbreak method where you simply visit a website on your iphone (jailbreak.me? .com?) and your device is rooted/jailbroken due to a bug in Safari's PDF renderer.