Changeset 58406 in vbox for trunk/src/VBox/HostDrivers/Support
- Timestamp:
- Oct 26, 2015 12:33:42 AM (9 years ago)
- svn:sync-xref-src-repo-rev:
- 103644
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/src/VBox/HostDrivers/Support/SUPR3HardenedMain.cpp
r58405 r58406 25 25 */ 26 26 27 /** @page pg_hardening VirtualBoxVM Process Hardening28 * 29 * The VM process hardening is to prevent malicious software from using30 * VirtualBox as a vehicle to obtain kernel level access.31 * 32 * The VirtualBox VMM requires supervisor (kernel) level access to the CPU. For33 * both practical and historical reasons, part of the VMM is realized in ring-3,34 * with a rich interface to the kernel part. While the device emulations can be35 * e xecuted exclusively in ring-3, we have performance optimizations that loads36 * device emulation code into ring-0 and our special raw-mode execution context37 * (none VT-x/AMD-V mode) for handling frequent operations a lot more38 * efficiently. These share data between all three context (ring-3, ring-0 and39 * raw-mode). All this poses a rather broad attack surface, which the hardening40 * protects.27 /** @page pg_hardening %VirtualBox %VM Process Hardening 28 * 29 * The %VM process hardening is to prevent malicious software from using 30 * %VirtualBox as a vehicle to obtain kernel level access. 31 * 32 * The %VirtualBox %VMM requires supervisor (kernel) level access to the CPU. 33 * For both practical and historical reasons, part of the %VMM is realized in 34 * ring-3, with a rich interface to the kernel part. While the device 35 * emulations can be executed exclusively in ring-3, we have performance 36 * optimizations that loads device emulation code into ring-0 and our special 37 * raw-mode execution context (none VT-x/AMD-V mode) for handling frequent 38 * operations a lot more efficiently. These share data between all three 39 * context (ring-3, ring-0 and raw-mode). All this poses a rather broad attack 40 * surface, which the hardening protects. 41 41 * 42 42 * The hardening focuses primarily on restricting access to the support driver, … … 44 44 * instigator of the communication between ring-3 and the ring-0 and raw-mode 45 45 * contexts. A secondary focus is to make sure malicious code cannot be loaded 46 * and executed in the VM process. Exactly how we go about this depends a lot46 * and executed in the %VM process. Exactly how we go about this depends a lot 47 47 * on the host OS. 48 48 * … … 57 57 * systems. 58 58 * - \\Device\\VBoxDrvStub on Windows for protecting the second stub 59 * process and its child, the VM process. This is an open+close59 * process and its child, the %VM process. This is an open+close 60 60 * interface, only available to partially verified stub processes. 61 61 * - \\Device\\VBoxDrvErrorInfo on Windows for obtaining detailed error … … 64 64 * 65 65 * The rest of VBox accesses the device interface thru the support library, 66 * SUPR3/ sup.h.66 * @ref grp_sup "SUPR3" / sup.h. 67 67 * 68 68 * The support driver also exposes a set of functions and data that other VBox 69 69 * ring-0 modules can import from. This includes much of the IPRT we need in 70 * the ring-0 part of the VMM and device emulations.71 * 72 * The ring-0 part of the VMM and device emulations are loaded via the73 * SUPR3LoadModule andSUPR3LoadServiceModule support library function, which70 * the ring-0 part of the %VMM and device emulations. 71 * 72 * The ring-0 part of the %VMM and device emulations are loaded via the 73 * #SUPR3LoadModule and #SUPR3LoadServiceModule support library function, which 74 74 * both translates to a sequence of I/O controls against /dev/vboxdrv. On 75 75 * Windows we use the native kernel loader to load the module, while on the … … 88 88 * checks that the effective user ID (EUID) is root when it is being opened. 89 89 * 90 * The VM processes temporarily assume root privileges using the set-uid-bit on90 * The %VM processes temporarily assume root privileges using the set-uid-bit on 91 91 * the executable with root as owner. In fact, all the files and directories we 92 92 * install are owned by root and the wheel (or equivalent gid = 0) group, … … 96 96 * unnecessary library dependencies (only libc, pthreads, dynamic linker) and 97 97 * simply calls #SUPR3HardenedMain. It does the following: 98 * 1. Validate the VirtualBox installation ( supR3HardenedVerifyAll):98 * 1. Validate the VirtualBox installation (#supR3HardenedVerifyAll): 99 99 * - Check that the executable file of the process is one of the known 100 100 * VirtualBox executables. … … 110 110 * 111 111 * 2. Open a file descriptor for the support device driver 112 * ( supR3HardenedMainOpenDevice).112 * (#supR3HardenedMainOpenDevice). 113 113 * 114 114 * 3. Grab ICMP capabilities for NAT ping support, if required by the OS 115 * (supR3HardenedMainGrabCapabilites). 116 * 117 * 4. Correctly drop the root privileges (supR3HardenedMainDropPrivileges). 115 * (#supR3HardenedMainGrabCapabilites). 116 * 117 * 4. Correctly drop the root privileges 118 * (#supR3HardenedMainDropPrivileges). 118 119 * 119 120 * 5. Load the VBoxRT dynamic link library and hand over the file 120 121 * descriptor to the support library code in it 121 * ( supR3HardenedMainInitRuntime).122 * 123 * 6. Load the dynamic library containing the actual VM front end code and124 * run it (tail of SUPR3HardenedMain).122 * (#supR3HardenedMainInitRuntime). 123 * 124 * 6. Load the dynamic library containing the actual %VM front end code and 125 * run it (tail of #SUPR3HardenedMain). 125 126 * 126 127 * The set-uid-to-root stub executable is paired with a dynamic link library 127 * which export one TrustedMain entry point (see FNSUPTRUSTEDMAIN) that we call.128 * In case of error reporting, the library may also export a TrustedError129 * function ( FNSUPTRUSTEDERROR).128 * which export one TrustedMain entry point (see #FNSUPTRUSTEDMAIN) that we 129 * call. In case of error reporting, the library may also export a TrustedError 130 * function (#FNSUPTRUSTEDERROR). 130 131 * 131 132 * That the set-uid-to-root-bit modifies the dynamic linker behavior on all … … 142 143 * In addition to what the dynamic linker does for us, the VirtualBox code will 143 144 * not directly be calling either RTLdrLoad or dlopen to load dynamic link 144 * libraries into the process. Instead it will call SUPR3HardenedLdrLoad,145 * SUPR3HardenedLdrLoadAppPriv and SUPR3HardenedLdrLoadPlugIn to do the loading.146 * These functions will perform the same validations on the file being loaded as147 * SUPR3HardenedMain did in its validation step. So, anything we load must be148 * installed with root/wheel as owner/group, the directory we load it from must149 * also be owned by root:wheel and now allow for renaming the file. Similar150 * ownership restrictions applies to all the parent directories (except on151 * darwin).145 * libraries into the process. Instead it will call #SUPR3HardenedLdrLoad, 146 * #SUPR3HardenedLdrLoadAppPriv and #SUPR3HardenedLdrLoadPlugIn to do the 147 * loading. These functions will perform the same validations on the file being 148 * loaded as #SUPR3HardenedMain did in its validation step. So, anything we 149 * load must be installed with root/wheel as owner/group, the directory we load 150 * it from must also be owned by root:wheel and now allow for renaming the file. 151 * Similar ownership restrictions applies to all the parent directories (except 152 * on darwin). 152 153 * 153 154 * So, we place the responsibility of not installing malicious software on the … … 170 171 * pointless, even if Windows had one. 171 172 * 172 * So, in order to protect access to the support driver and protect the 173 * VM process while it's running we have to do a lot more work. A keystone in174 * the defences is cryptographic code signing. Here's the short version of what175 * wedo:173 * So, in order to protect access to the support driver and protect the %VM 174 * process while it's running we have to do a lot more work. A keystone in the 175 * defences is cryptographic code signing. Here's the short version of what we 176 * do: 176 177 * - Minimal stub executable, signed with the same certificate as the 177 178 * kernel driver. … … 212 213 * 213 214 * We share the stub executable approach with the UNIX-like systems, so there's 214 * the SUPR3HardenedMain calling stub executable with it's parenter DLL215 * exporting TrustedMain and TrustedError. However, the stub executable does a216 * lot more,while doing it in a more bare metal fashion:215 * the #SUPR3HardenedMain calling stub executable with its partner DLL exporting 216 * TrustedMain and TrustedError. However, the stub executable does a lot more, 217 * while doing it in a more bare metal fashion: 217 218 * - It does not use the Microsoft CRT, what we need of CRT functions comes 218 219 * from IPRT. … … 227 228 * The initial stub process is not really to be trusted, though we try our best 228 229 * to limit potential harm (user mode debugger checks, disable thread creation). 229 * So, when it enters SUPR3HardenedMain we only callsupR3HardenedVerifyAll to230 * So, when it enters #SUPR3HardenedMain we only call #supR3HardenedVerifyAll to 230 231 * verify the installation (known executables and DLLs, checking their code 231 232 * signing signatures, keeping them all open to deny deletion and replacing) and 232 * does a respawn via supR3HardenedWinReSpawn.233 * does a respawn via #supR3HardenedWinReSpawn. 233 234 * 234 235 * … … 238 239 * thread is suspended before it executes a single instruction. It is also 239 240 * created with a less generous ACLs, though this doesn't protect us from admin 240 * users. In order for SUPR3TrustedMain to figure that it is the second stub241 * users. In order for #SUPR3HardenedMain to figure that it is the second stub 241 242 * process, the zeroth command line argument has been replaced by a known magic 242 243 * string (UUID). … … 244 245 * Now, before the process starts executing, the parent (initial stub) will 245 246 * patch the LdrInitializeThunk entry point in NTDLL to call 246 * supR3HardenedEarlyProcessInit viasupR3HardenedEarlyProcessInitThunk. The247 * parent will also plant some synchronization stuff via g_ProcParams (NTDLL247 * #supR3HardenedEarlyProcessInit via #supR3HardenedEarlyProcessInitThunk. The 248 * parent will also plant some synchronization stuff via #g_ProcParams (NTDLL 248 249 * location, inherited event handles and associated ping-pong equipment). 249 250 * … … 259 260 * the process is created or/and starts executing the first instruction. But we 260 261 * can easily counter these as we have a known process state we can restore. So, 261 * the first thing that supR3HardenedEarlyProcessInit does is to signal the262 * the first thing that #supR3HardenedEarlyProcessInit does is to signal the 262 263 * parent to perform a child purification, so the potentially evil influences 263 264 * can be exorcised. 264 265 * 265 266 * What the parent does during the purification is very similar to what the 266 * kernel driver will do later on when verifying the second stub and the VM267 * kernel driver will do later on when verifying the second stub and the %VM 267 268 * processes, except that instead of failing when encountering an shortcoming it 268 269 * will take corrective actions: … … 272 273 * stub executable and NTDLL) will be compared to the pristine fixed-up 273 274 * copy prepared by the IPRT PE loader code, restoring any bytes which 274 * appears differently in the child. ( g_ProcParams (SUPR3WINPROCPARAMS)275 * is exempted,LdrInitializeThunk is set to call NtTerminateThread.)275 * appears differently in the child. (#g_ProcParams is exempted, 276 * LdrInitializeThunk is set to call NtTerminateThread.) 276 277 * - Unwanted DLLs will be unloaded (we have a set of DLLs we like). 277 278 * … … 282 283 * usually receives handles with unrestricted access to the child process and 283 284 * its main thread. These could in theory be used with DuplicateHandle or 284 * WriteProcessMemory to get at the VM process if we're not careful.)285 * 286 * supR3HardenedEarlyProcessInit will continue with opening the log file285 * WriteProcessMemory to get at the %VM process if we're not careful.) 286 * 287 * #supR3HardenedEarlyProcessInit will continue with opening the log file 287 288 * (requires command line parsing). It will continue to initialize a bunch of 288 289 * global variables, system calls and trustworthy/harmless NTDLL imports. 289 * supR3HardenedWinInit is then called to setup image verification, that is:290 * #supR3HardenedWinInit is then called to setup image verification, that is: 290 291 * - Hook the NtCreateSection entry point in NTDLL so we can check all 291 292 * executable mappings before they're created and can be mapped. The 292 * NtCreateSection code jumps to supR3HardenedMonitor_NtCreateSection.293 * NtCreateSection code jumps to #supR3HardenedMonitor_NtCreateSection. 293 294 * - Hook (ditto) the LdrLoadDll entry point in NTDLL so we can 294 295 * pre-validate all images that gets loaded the normal way (partly … … 296 297 * loader lock is usually held, which prevents us from safely calling 297 298 * WinVerityTrust). The LdrLoadDll code jumps to 298 * supR3HardenedMonitor_LdrLoadDll.299 * #supR3HardenedMonitor_LdrLoadDll. 299 300 * 300 301 * The image/DLL verification hooks are at this point able to verify DLLs 301 302 * containing embedded code signing signatures, and will restrict the locations 302 * from which DLLs will be loaded. When SUPR3HardenedMain gets going later on,303 * from which DLLs will be loaded. When #SUPR3HardenedMain gets going later on, 303 304 * they will start insisting on everything having valid signatures, either 304 305 * embedded or in a signed installer catalog file. … … 330 331 * than our own two in NTDLL are allowed). 331 332 * 332 * Once granted access to the stub device, supR3HardenedEarlyProcessInit will333 * Once granted access to the stub device, #supR3HardenedEarlyProcessInit will 333 334 * restore the LdrInitializeThunk code and let the process perform normal 334 * initialization. Leading us to SUPR3HardenedMain where we detect that thisis335 * the 2nd stub process and does another respawn.336 * 337 * 338 * @subsection sec_hardening_win_3rd_stub The Final Stub / VM Process339 * 340 * The third stub process is what becomes the VM process. Because the parent335 * initialization. Leading us to #SUPR3HardenedMain where we detect that this 336 * is the 2nd stub process and does another respawn. 337 * 338 * 339 * @subsection sec_hardening_win_3rd_stub The Final Stub / %VM Process 340 * 341 * The third stub process is what becomes the %VM process. Because the parent 341 342 * has opened \\Device\\VBoxDrvSub, it is protected from malicious OpenProcess & 342 343 * OpenThread calls from the moment of inception, practically speaking. … … 344 345 * It goes thru the same suspended creation, patching, purification and such as 345 346 * its parent (the second stub process). However, instead of opening 346 * \\Device\\VBoxDrvStub from supR3HardenedEarlyProcessInit, it opens the347 * \\Device\\VBoxDrvStub from #supR3HardenedEarlyProcessInit, it opens the 347 348 * support driver for full unrestricted access, i.e. \\Device\\VBoxDrv. 348 349 * … … 370 371 * 371 372 * As in the second stub process, we'll now do normal process initialization and 372 * SUPR3HardenedMain will take control. It will detect that it is being called373 * #SUPR3HardenedMain will take control. It will detect that it is being called 373 374 * by the 3rd stub process because of a different magic string starting the 374 * command line, and not respawn itself any more. SUPRR3HardenedMain will375 * command line, and not respawn itself any more. #SUPR3HardenedMain will 375 376 * recheck the VirtualBox installation, keeping all known files open just like 376 377 * in two previous stub processes.
Note:
See TracChangeset
for help on using the changeset viewer.
