I run both Norton and Spybot.
Spybot idenitified two problems:
DSO Exploit and Common Hijacker.
There was no info available on Common Hijacker, but there was info available on DSO Exploit.
This was the description:
"There's a security hole in IE allowing websites to execute code without asking you first. You can find more information at http://security.greymagic.com/adv/gm001-ie
I went there and found the following info:
GreyMagic Security Advisory GM#001-IE
By GreyMagic Software, Israel.
27 Feb 2002. SPYBOT USERS FAQ: Q: Can you help me understand how to resolve this?
A: NO. GreyMagic DOES NOT provide ANY support for this or any other issue we have revealed in our security research. Questions and help queries should be forwarded to Spybot or Microsoft. Emails concerning this issue are automatically filtered and will NOT be read or acknowledged in any way.
Q: Did you put this spyware/exploit/vulnerability on my computer?
A: Absolutely not. GreyMagic detected this issue in Microsoft Internet Explorer and reported it to the public. GreyMagic does not produce nor will it ever produce spyware.
The following text is a technical analysis of the vulnerability. This is the reason Spybot directed you here
Topic: Executing arbitrary commands without Active Scripting or ActiveX.
Discovery date: 25 Feb 2002.
Affected applications: Any application that hosts the WebBrowser control (5.5+) is affected since this exploit does not require Active Scripting or ActiveX. Some of these applications are:
Microsoft Internet Explorer
Microsoft Outlook
Microsoft Outlook Express
Introduction: In an advisory from Jan 10 2002 "The Pull" demonstrated how it is still possible to use an older bug (initially discovered by Dildog) in the <object> HTML element to run arbitrary commands.
Although "The Pull"'s findings were interesting, his analysis of the re-found bug was erroneous, the problem does not lie within the Popup object, the problem is with dynamically inserted HTML fragments at any point in the document.
All "createPopup" does is create a (featureless) window containing an empty HTML document, this does not pose a threat, but later on, that document has HTML injected to it (using innerHTML), which is the actual problem.
For example, the following code will work just the same:
<span id="oSpan"></span>
<script language="jscript" defer>
oSpan.innerHTML='<object classid="clsid:11111111-1111-1111-1111-111111111111" codebase="c:/winnt/system32/calc.exe"></object>';
</script>
(Note: innerHTML is not the only property used to dynamically insert HTML to any element, it is also possible to use outerHTML, insertAdjacentHTML and more to gain the same results.)
Discussion: So now that we identified the origin of the problem we can search for ways to dynamically insert HTML without using any Active Scripting at all. It will then become possible to use this bug in more "protected" environments, such as Microsoft Outlook or Internet Explorer with Active Scripting and ActiveX disabled.
One of the exciting features that came along in IE4 was Data Binding; it enables developers to completely separate any application data from the presentation layer. The data sources (DSO) for Data Binding can be almost anything, CSV files (with TDC), HTML, XML and many more. Data Binding binds HTML elements (data consumers) such as div or span to the DSO without need for a single line of script code.
We found out that when the "dataFormatAs" attribute is set to "HTML" on the consumer, Data Binding internally uses innerHTML in order to insert the data into the element (otherwise innerText is used).
So all we need to do now is supply a DSO that contains the offending <object> element, the rest will be done for us by the Data Binding engine, no scripting needed.
Exploit: In the following example we're using an XML data-island as our DSO and a span element as the data consumer. Using XML is especially comfortable because it can be embedded within the document, without need for external requests that may be stopped by the host application.
<span datasrc="#oExec" datafld="exploit" dataformatas="html"></span>
<xml id="oExec">
<security>
<exploit>
<![CDATA[
<object id="oFile" classid="clsid:11111111-1111-1111-1111-111111111111" codebase="c:/winnt/system32/calc.exe"></object>
]]>
</exploit>
</security>
</xml>
Solution: There is no configuration-tweaking workaround for this bug, it will work as long as the browser parses HTML. The only possible solution must come in the form of a patch from Microsoft.
Update - 3 Mar 2002
Since the injected <object> runs in the "My Computer" Zone changing the Internet Zone's settings didn't affect it, but changing the correct zone's settings will prevent this exploit from running.
Here is the registry information:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0]
Change the value of "1004" (DWORD) to 3.
Many thanks to Axel Pettinger and Garland Hopkins for this workaround.
Tested on: IE5.5 Win98.
IE5.5 NT4.
IE6 Win2000.
IE6 WinXP.
Demonstration: We put together two proof-of-concept demonstrations:
Important Note: If you run anti-virus software, it may complain when you try to run these. This does NOT mean that you have a virus now, or that you're affected or unaffected by this vulnerability.
Simple: attempts to run "c:/winnt/system32/calc.exe".
Advanced: lets the user pick what they want to run.
Disclaimer: The information in this advisory and any of its demonstrations is provided "as is" without warranty of any kind.
GreyMagic Software is not liable for any direct or indirect damages caused as a result of using the information or demonstrations provided in any part of this advisory.
~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~
How do I (or even "should I?) enter the registry to change the DWORD from 1004 to 3?
Spybot idenitified two problems:
DSO Exploit and Common Hijacker.
There was no info available on Common Hijacker, but there was info available on DSO Exploit.
This was the description:
"There's a security hole in IE allowing websites to execute code without asking you first. You can find more information at http://security.greymagic.com/adv/gm001-ie
I went there and found the following info:
GreyMagic Security Advisory GM#001-IE
By GreyMagic Software, Israel.
27 Feb 2002. SPYBOT USERS FAQ: Q: Can you help me understand how to resolve this?
A: NO. GreyMagic DOES NOT provide ANY support for this or any other issue we have revealed in our security research. Questions and help queries should be forwarded to Spybot or Microsoft. Emails concerning this issue are automatically filtered and will NOT be read or acknowledged in any way.
Q: Did you put this spyware/exploit/vulnerability on my computer?
A: Absolutely not. GreyMagic detected this issue in Microsoft Internet Explorer and reported it to the public. GreyMagic does not produce nor will it ever produce spyware.
The following text is a technical analysis of the vulnerability. This is the reason Spybot directed you here
Topic: Executing arbitrary commands without Active Scripting or ActiveX.
Discovery date: 25 Feb 2002.
Affected applications: Any application that hosts the WebBrowser control (5.5+) is affected since this exploit does not require Active Scripting or ActiveX. Some of these applications are:
Microsoft Internet Explorer
Microsoft Outlook
Microsoft Outlook Express
Introduction: In an advisory from Jan 10 2002 "The Pull" demonstrated how it is still possible to use an older bug (initially discovered by Dildog) in the <object> HTML element to run arbitrary commands.
Although "The Pull"'s findings were interesting, his analysis of the re-found bug was erroneous, the problem does not lie within the Popup object, the problem is with dynamically inserted HTML fragments at any point in the document.
All "createPopup" does is create a (featureless) window containing an empty HTML document, this does not pose a threat, but later on, that document has HTML injected to it (using innerHTML), which is the actual problem.
For example, the following code will work just the same:
<span id="oSpan"></span>
<script language="jscript" defer>
oSpan.innerHTML='<object classid="clsid:11111111-1111-1111-1111-111111111111" codebase="c:/winnt/system32/calc.exe"></object>';
</script>
(Note: innerHTML is not the only property used to dynamically insert HTML to any element, it is also possible to use outerHTML, insertAdjacentHTML and more to gain the same results.)
Discussion: So now that we identified the origin of the problem we can search for ways to dynamically insert HTML without using any Active Scripting at all. It will then become possible to use this bug in more "protected" environments, such as Microsoft Outlook or Internet Explorer with Active Scripting and ActiveX disabled.
One of the exciting features that came along in IE4 was Data Binding; it enables developers to completely separate any application data from the presentation layer. The data sources (DSO) for Data Binding can be almost anything, CSV files (with TDC), HTML, XML and many more. Data Binding binds HTML elements (data consumers) such as div or span to the DSO without need for a single line of script code.
We found out that when the "dataFormatAs" attribute is set to "HTML" on the consumer, Data Binding internally uses innerHTML in order to insert the data into the element (otherwise innerText is used).
So all we need to do now is supply a DSO that contains the offending <object> element, the rest will be done for us by the Data Binding engine, no scripting needed.
Exploit: In the following example we're using an XML data-island as our DSO and a span element as the data consumer. Using XML is especially comfortable because it can be embedded within the document, without need for external requests that may be stopped by the host application.
<span datasrc="#oExec" datafld="exploit" dataformatas="html"></span>
<xml id="oExec">
<security>
<exploit>
<![CDATA[
<object id="oFile" classid="clsid:11111111-1111-1111-1111-111111111111" codebase="c:/winnt/system32/calc.exe"></object>
]]>
</exploit>
</security>
</xml>
Solution: There is no configuration-tweaking workaround for this bug, it will work as long as the browser parses HTML. The only possible solution must come in the form of a patch from Microsoft.
Update - 3 Mar 2002
Since the injected <object> runs in the "My Computer" Zone changing the Internet Zone's settings didn't affect it, but changing the correct zone's settings will prevent this exploit from running.
Here is the registry information:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0]
Change the value of "1004" (DWORD) to 3.
Many thanks to Axel Pettinger and Garland Hopkins for this workaround.
Tested on: IE5.5 Win98.
IE5.5 NT4.
IE6 Win2000.
IE6 WinXP.
Demonstration: We put together two proof-of-concept demonstrations:
Important Note: If you run anti-virus software, it may complain when you try to run these. This does NOT mean that you have a virus now, or that you're affected or unaffected by this vulnerability.
Simple: attempts to run "c:/winnt/system32/calc.exe".
Advanced: lets the user pick what they want to run.
Disclaimer: The information in this advisory and any of its demonstrations is provided "as is" without warranty of any kind.
GreyMagic Software is not liable for any direct or indirect damages caused as a result of using the information or demonstrations provided in any part of this advisory.
~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~
How do I (or even "should I?) enter the registry to change the DWORD from 1004 to 3?
