VirtualBox 3D acceleration of virtual machine escape vulnerabilities in the advanced use-vulnerability warning-the black bar safety net

2014-08-06T00:00:00
ID MYHACK58:62201452193
Type myhack58
Reporter 佚名
Modified 2014-08-06T00:00:00

Description

In the previous blog, we share a affect the Xen hypervisor client-to-host guest-to-host escape vulnerability the use of technology. In this new blog article we will focus on another VM escape vulnerability, VirtualBox the.

A few months ago, our core security friends released a about the impact of VirtualBox multiple memory corruption vulnerability issues that could allow in the clientOSof the user/program to escape the virtual machine and the hostoperating systemexecuting arbitrary code.

A few weeks ago, the REcon 2 0 1 4 during the year, Francisco Falcon has proved to be a combination of these vulnerabilities and use them to achieve in a 3 2-bit windows host on the client-to-host guest-to-host escape.

In this blog, we will share in the 6 4-bit windows 8 on the host using only one Vulnerability, CVE-2 0 1 4-0 9 8 3, to achieve a reliable virtual machine escape the use of technology, and did not make the VirtualBox process crashes, also known as a process a continuation of it.

1: the vulnerability of the technical analysis

Multiple memory corruption vulnerabilities exist in the OpenGL graphics VirtualBox 3D acceleration. In this analysis, we will focus on the CVE-2 0 1 4-0 9 8 3 in.

From clientoperating system, the client will increase increase to a multiple amount of services such as: drag-and-drop, shared clipboard, the graphics rendering and the like. One of the services is referred to as“shared OpenGL”in. When the 3D acceleration in VirtualBox enabled default disabled, can be by client/server model provides remote rendering of OpenGL graphics. The clientOSas a client sends a rendering of the message to“VBoxGuest.sys”the driver, the driver followed by PMIO/MMIO forwards the message to parse it to the host as a server. More about VirtualBox and the 3D details of the reference here.

In many of the rendering of the message has a name"CR_MESSAGE_OPCODES"rendering of the message, its structure by the operation code of the command identifier. In the server-end hostoperating system to"crUnpack()"function handles all of the operation code.

static void crServerDispatchMessage(CRConnection conn, CRMessage msg) { const CRMessageOpcodes msg_opcodes; CRASSERT(msg->header. type == CR_MESSAGE_OPCODES); msg_opcodes = (const CRMessageOpcodes )msg; data_ptr = (const char ) msg_opcodes + sizeof(CRMessageOpcodes) + opcodeBytes; crUnpack(data_ptr, / first command operands / data_ptr - 1, / first command opcode / msg_opcodes->numOpcodes, / operation code number / &(cr_server. dispatch)); / the CR dispatch table */

In install VirtualBox by in"src/VBox/HostServices/SharedOpenGL/unpacker/unpack.py"the python script to automatically generate the"crUnpack()"Function,This function can be used as a switch, and according to the operation code processing different functions.

By sending a message containing the operation code"CR_VERTEXATTRIB4NUBARB_OPCODE" (0xEA)of the message,"crUnpack()"call"crUnpackVertexAttrib4NubARB()",this function parses from the clientOSwithout any verification or check of the render message.

static void crUnpackVertexAttrib4NubARB(void) { GLuint index = READ_DATA( 0, GLuint ); GLubyte x = READ_DATA( 4, GLubyte ); GLubyte y = READ_DATA( 5, GLubyte ); GLubyte z = READ_DATA( 6, GLubyte ); GLubyte w = READ_DATA( 7, GLubyte ); cr_unpackDispatch. VertexAttrib4NubARB( index, x, y, z, w ); INCR_DATA_PTR( 8 ); } void SERVER_DISPATCH_APIENTRY crServerDispatchVertexAttrib4Nubarb(GLuint index, GLubyte x, GLubyte y, GLubyte z, GLubyte w ) { cr_server. head_spu->dispatch_table. VertexAttrib4NubARB(index, x, y, z, w ); cr_server. current. c. vertexAttrib. ub4[index] = cr_unpackData; }

Due to the missing array index validation, located in the"cr_server. current. c. vertexAttrib. ub4" array after the memory can be "cr_unpackData"damage.

[1] [2] [3] [4] [5] next