Opened 3 years ago
#20423 new defect
Oracle VirtualBox SharedClipboard Use After Free Vulnerability
| Reported by: | info_starlabs | Owned by: | |
|---|---|---|---|
| Component: | clipboard | Version: | VirtualBox 6.1.22 |
| Keywords: | Cc: | billy@… | |
| Guest type: | Linux | Host type: | Linux |
Description
Oracle VirtualBox SharedClipboard Use After Free Vulnerability
Affected Software
Oracle VM VirtualBox 6.1.22
Description of Vulnerability
This vulnerability allows guest VM to cause denial of service in the context of the host hypervisor. High privileged code on the target guest system is required to exploit this vulnerability.
Technical Details
VirtualBox provide a HostService named "VBoxSharedClipboard" to perform the operation of shared clipboard between Host and Guest. The guest sends the request through HGCM (Host-Guest Communication Manager). The vulnerability is when guest quickly send VMMDevReq_HGCMDisconnect and VMMDevReq_HGCMCall64 to the same service sequentially. That service will operate the VMMDevReq_HGCMCall64 after the VMMDevReq_HGCMDisconnect. So pvClient the internal object used in service has been released when it perform disconnect function. But Later HGCMCall will use that freed object to operate guest requested function and cause use after free.
In code [1], it free the pCtx and later will be used in HGCMCall
svcDisconnect ->
ShClSvcImplDisconnect
Code highlighting:
int ShClSvcImplDisconnect(PSHCLCLIENT pClient) { LogFlowFuncEnter(); PSHCLCONTEXT pCtx = pClient->State.pCtx; AssertPtr(pCtx); /* Drop the reference to the client, in case it is still there. This * will cause any outstanding clipboard data requests from X11 to fail * immediately. */ pCtx->fShuttingDown = true; int rc = ShClX11ThreadStop(&pCtx->X11); /** @todo handle this slightly more reasonably, or be really sure * it won't go wrong. */ AssertRC(rc); ShClX11Destroy(&pCtx->X11); RTCritSectDelete(&pCtx->CritSect); RTMemFree(pCtx); // code [1] LogFlowFuncLeaveRC(rc); return rc; }
When the guest send a VBOX_SHCL_GUEST_FN_REPORT_FORMATS request and guest's uMode is set to VBOX_SHCL_MODE_BIDIRECTIONAL or VBOX_SHCL_MODE_GUEST_TO_HOST
which is not default setting in code [2], it will perform the following function. In function XtAppAddTimeOut, it will get crashed.
Code highlighting:
static int shClSvcClientReportFormats(PSHCLCLIENT pClient, uint32_t cParms, VBOXHGCMSVCPARM paParms[]) { /* * Check if the service mode allows this operation and whether the guest is * supposed to be reading from the host. */ uint32_t uMode = ShClSvcGetMode(); if ( uMode == VBOX_SHCL_MODE_BIDIRECTIONAL //code [2] || uMode == VBOX_SHCL_MODE_GUEST_TO_HOST) { /* likely */ } else return VERR_ACCESS_DENIED;
svcCall ->
shClSvcClientReportFormats->
ShClSvcImplFormatAnnounce->
ShClX11ReportFormatsToX11->
clipThreadScheduleCall->
XtAppAddTimeOut->
clipThreadScheduleCall
Code highlighting:
static int clipThreadScheduleCall(PSHCLX11CTX pCtx, void (*proc)(void *, void *), void *client_data) { LogFlowFunc(("proc=%p, client_data=%p\n", proc, client_data)); #ifndef TESTCASE XtAppAddTimeOut(pCtx->pAppContext, 0, (XtTimerCallbackProc)proc, (XtPointer)client_data); ssize_t cbWritten = write(pCtx->wakeupPipeWrite, WAKE_UP_STRING, WAKE_UP_STRING_LEN); Assert(cbWritten == WAKE_UP_STRING_LEN);
The POC
The following are step by step guide for replicating the bug:
- Upload the file
poc.candinternal.hinto the guest - Compile the poc by
gcc poc.c -o poc - Run
pocas root
Requirements
- The Host OS must be Linux
- Attacker must be able to run high-privileged code on the guest
- The setting of Shared Clipboard need to be
Guest to HostorBidirectional
The PoC and full description in markdown of the vulnerability