Fri, 13 May 2011 10:21:20 GMT
The rising of virtualization technology really had a boost recently, especially as a way of securing software. Put your browser into a virtual machine to secure it. Put your PDF reader into a sandbox to secure it.
This architecture is comparably inefficient, due to the virtualized kernels. As we are using virtual machines, we can make the virtual hardware homogeneous, thus we can put the device management into the processes themselves directly, gaining a smaller memory footprint:
The problem is that also virtualizers sometimes have security holes, too. This problem can be adressed by stacking various kinds of them, so a hacker must find out the kind of virtual machine and then use the right exploit to break out.
To gain a little more security, though not much, we can shuffle the kinds of VMs, so the hacker must determine the kind and choose the right exploits.
Of course, this is still not satisfactory, it is plausible to assume that all sorts of virtualizers have exploits and hackers will actively use them. Using multiple exploits to punch multiple VM layers may be harder than just one sandbox, but not that much.
Usually, we assume that distinct virtual machines have distinct bugs - this is of course only plausible when they do not use the same backend. Now, during exploits, mostly some unusual things are done, and mostly the aftermath is completely different from what one would expect in a system without the exploited bug. So one approach of increasing the security is just running the same application in two virtual machines with the same input, and compare the output and the memory pages. As long as no exploit is used, they should remain equal, and as soon as they are not equal, something has gone wrong and we can freeze the machines immediately to prevent them from doing bad stuff.
Of course, to put an additional difficulty onto it, we try to make the VM graph look "random".
This way is already very secure, as you need to have a lot of knowledge to actually find your way to the kernel. However, we rather expect to be a few mostly equal virtualizers than many completely different ones. Which means that even this concept can be broken easily with a sufficient knowledge of the internals of all VMs.
The spawn nodes all use the innovative RPM™ (Reasoning Processing Module) technology. The crucial innovation of MazeVM™ is the Circular™ RPM™ introduced to it. It allows circular connections between virtual machines and even with the kernel itself.:
The kernel itself can easily be tarned as an own virtual machine, and thus, we can build a complicated graph of virtual machines monitoring each other, a "maze", hence the name. In such a maze, it can be extremely hard to find a way to the actual kernel of the computer, especially if you do not see which of the many machines is not virtual - thus, in a sufficiently large MazeVM™ graph, an attacker has no chance to ever come to your actual machine and do any harm to you.
MazeVM™ is compatible with most of the modern virtualizers, including but not limited to JPC, NestedVM and JSx86. The preferred virtualizer is Parrot under Linux, and CygwinVZ under Windows.
Notice that CygwinVZ is, however, still under heavy development, and the upstream releases may not be ready for production use. MazeVM™'s version for windows therefore contains a patched, well-tested, own version of CygwinVZ.
+-- VM 1 -- virtual kernel 1 -- PDF reader
|
kernel --+-- VM 2 -- virtual kernel 2 -- web browser
|
+-- VM 3 -- virtual kernel 3 -- online banking
This architecture is comparably inefficient, due to the virtualized kernels. As we are using virtual machines, we can make the virtual hardware homogeneous, thus we can put the device management into the processes themselves directly, gaining a smaller memory footprint:
+-- VM 1 -- PDF reader
|
kernel --+-- VM 2 -- web browser
|
+-- VM 3 -- online bankingThe problem is that also virtualizers sometimes have security holes, too. This problem can be adressed by stacking various kinds of them, so a hacker must find out the kind of virtual machine and then use the right exploit to break out.
+-- VMa 1 -- VMb 1 -- VMc 1 -- PDF reader
|
kernel --+-- VMa 2 -- VMb 2 -- VMc 2 -- web browser
|
+-- VMa 3 -- VMb 3 -- VMc 3 -- online bankingTo gain a little more security, though not much, we can shuffle the kinds of VMs, so the hacker must determine the kind and choose the right exploits.
+-- VMa 1 -- VMc 1 -- VMb 1 -- PDF reader
|
kernel --+-- VMb 2 -- VMa 2 -- VMc 2 -- web browser
|
+-- VMc 3 -- VMb 3 -- VMa 3 -- online bankingOf course, this is still not satisfactory, it is plausible to assume that all sorts of virtualizers have exploits and hackers will actively use them. Using multiple exploits to punch multiple VM layers may be harder than just one sandbox, but not that much.
Usually, we assume that distinct virtual machines have distinct bugs - this is of course only plausible when they do not use the same backend. Now, during exploits, mostly some unusual things are done, and mostly the aftermath is completely different from what one would expect in a system without the exploited bug. So one approach of increasing the security is just running the same application in two virtual machines with the same input, and compare the output and the memory pages. As long as no exploit is used, they should remain equal, and as soon as they are not equal, something has gone wrong and we can freeze the machines immediately to prevent them from doing bad stuff.
Of course, to put an additional difficulty onto it, we try to make the VM graph look "random".
+-- VMa 1 -- spawn -- VMb 1 -- PDF reader
| | |
| + ---- VMc 1 -----+
|
| +--------- VMb 2 ---------+
| | |
kernel --+-- spawn -- VMa 2 -- VMc 2 -- web browser
|
+-- spawn --VMa 3 -- online banking
| | |
+-- spawn -- VMb 3 --+ |
| |
+----- VMc 3 -----+
This way is already very secure, as you need to have a lot of knowledge to actually find your way to the kernel. However, we rather expect to be a few mostly equal virtualizers than many completely different ones. Which means that even this concept can be broken easily with a sufficient knowledge of the internals of all VMs.
The spawn nodes all use the innovative RPM™ (Reasoning Processing Module) technology. The crucial innovation of MazeVM™ is the Circular™ RPM™ introduced to it. It allows circular connections between virtual machines and even with the kernel itself.:
+-- VMa 1 -- VMc 1 -- VMb 1 -- spawn -- PDF reader
| | |
| +------CRPM-------+
|
kernel --+-- VMb 2 -- VMa 2 -- VMc 2 -- web browser
| |
| +-- spawn -- VMb 3 -- VMa 3 -- online banking
| |
+--CRPM----VMc 3
The kernel itself can easily be tarned as an own virtual machine, and thus, we can build a complicated graph of virtual machines monitoring each other, a "maze", hence the name. In such a maze, it can be extremely hard to find a way to the actual kernel of the computer, especially if you do not see which of the many machines is not virtual - thus, in a sufficiently large MazeVM™ graph, an attacker has no chance to ever come to your actual machine and do any harm to you.
MazeVM™ is compatible with most of the modern virtualizers, including but not limited to JPC, NestedVM and JSx86. The preferred virtualizer is Parrot under Linux, and CygwinVZ under Windows.
Notice that CygwinVZ is, however, still under heavy development, and the upstream releases may not be ready for production use. MazeVM™'s version for windows therefore contains a patched, well-tested, own version of CygwinVZ.