Lab rats at Microsoft Research and the University of Michigan have teamed up to create prototypes for virtual machine-based rootkits that significantly push the envelope for hiding malware and that can maintain control of a target operating system. The proof-of-concept rootkit, called SubVirt, exploits known security flaws and drops a VMM (virtual machine monitor) underneath a Windows or Linux installation. Once the target operating system is hoisted into a virtual machine, the rootkit becomes impossible to detect because its state cannot be accessed by security software running in the target system.
I bet Sony would love to get their hands on this…
So the next big thing for MS will be professional rootkit development :]
We’re not insecure, look at all the exploits we developed for platform ____!
Oh, yea, we’ll get those security fixes out when we figure them out. The boys are busy with a new buffer overflow they found in the linux kernel.
Yea, I don’t think I can quite see that one
.
The security world is starting to look an awful lot like the fashion world. Everybody likes to talk about some common form of exploit. Then something small brings another form into vogue and for a while everybody’s talking about it.
For a bit rootkits on windows (what a misnomer) were all the rage. Right now everybody is obsessed with os x security. Now the next big thing might be vmm rootkits.
Think of the (15 minutes of) fame you’ll acheive if you can come up with the next exploit that everyone wants to talk about!
Is the new thing making stupid choices?
I understand the article like this:
Because of some hypothetical thread we nedd to verify the bootprocess, best with TPM. Great! Ill take 10!
(while we are at it – why not forbid Linux to boot on dualboot PC…)
AZ
Edited 2006-03-11 23:27
I would think that at least on windows NT/2000/Xp, if you were to suddenly move an exisitng install to a VM, the OS would BSOD due to the radically changed hardware, or you would have to activate it again at least. With linux, the OS may continue to function, but would it be working right? I may have to try it at home and see
not realy, you just have to copy over the hardware id items so that windows still thinks it can use the same old drivers. if that happens, it will boot just fine (why on earth it cant just drop back down to the generic drivers that it comes shipped with i dont understand tho).
I don’t really know about the hypervisor type of VM, but I know that the vmware/VPC type of VM emulate a particular type of chipset/cpu/hardware mix, so it would be a major chore to get Windows to run properly in that type of VM without a repair install, I would think, now with a hypervisor, it may work differently, as they may be just transparently dividing up the resources, but as I have no machines capable of running vmware’s hypervisor (needs smp) and Xen will not run Windows unaltered, I really have no idea
thing is to basicly make windows think its still running directly on the hardware, while in reality its talking thru the “VM”.
this way i think the label VM is a bit misleading. more correctly we are talking about a kind of software keylogger thats monitoring all the hardware access that your software is doing. its there, only that your not emulating a specific set of hardware, your just passing the signals on (after logging them and potentialy sending them on to whoever made the logger) to the existing hardware wholesale.
atleast thats my theory about how to pull it off…
Actually, Xen can run Windows unaltered if you have proper hardware support available (i.e. Intel Vanderpool or AMD Pacifica). The functionality needs further development, but it’s there for initial testing.
This is Microsoft’s little push toward Palladium being built into the hardware. Instead of focusing on the idea of how to keep the rootkit from a position of getting this kind of access, they gloss over that point and go straight to the conclusion that hardware is needed to protect us.
I think this is also a push for Palladium from Microsoft.
The question I have is that, does each OS run on a separate container in the VM environment?
Why can’t the VM be locked down such that the container can be checksum’ed (so no RK’s can run underneath the OS environment).
I can see this becoming a problem with Xen, VirutalPC or VMWare with people who don’t know what they’re doing.
The group said the SubVirt project implemented VM-based rootkits on two platforms–Linux/VMWare and Windows/VirtualPC–and was able to write malicious services without detection.
I can understand Microsoft developing malicious software to see how secure Windows is and to let developers know what areas need to be strengthened. But why is Microsoft developing malicious software that attacks Linux?
They openly announced what they did, and teaming with a university gives it the aura of research nobility. But the article doesn’t say how they are benefited by developing technology that attacks a competing product.
Because if they didn’t, a certain group of people would be jumping up and down going “omg insecure”, etc, etc. The usual hyperbole. So, instead, they decided to let the conspiracy theorists have a field day instead.
Excuse me but, ins’t the solution hear to move to READ ONLY Boot ROMs?
And maybe require a password or something to be able to modify any of the bios settings?
The only way these would work is if people could write to change the boot sequence to make their stuff be the first boot loader and insert themselves at that layer before the rest of the system boots up.
Personally, I think the fear of this is way over blown.
thing is that at some point you have to hand the boot over from the hardware to the software.
and at that point you intercept and install.
its a bit like those bios overrides that allowes you to install a hardrive that the bios could not address the full size of.
what you can do is have the boot rom do a fingerprint of the boot each time its done. if it changes, alert the user. problem is that there is no way to tell if the boot changes because of something the user did, or because of something else. even more so given that you have to reboot windows each time you do a bit of updating.
still, i agree that the fear (as of now) is overblown. but its theoreticaly possible. and there is no way to make the boot system bulletproof unless you totaly stop storing software thats supposed to interact with the user or the handware on rewritable media.
that way you cant insert a binary as its fushed the next time you reboot the system. thing is tho that this flys in the face of user friendlyness (alltho im starting to think that the tech world is trying to be to friendly at times)…
OK, this sounds like a bug deal, but think about this. The rootkit is going to have to have drivers for all the target hardware. Otherwise something isnt going to work right and then you are going to figure out that you have a rootkit. The whole point of a rootkit is to be stealthy, but who here wouldnt notice pretty quick if your sound started acting funny or you didnt have 3d acceleration anymore? Not to mention firewire and usb2 support. I mean, these things dont quite work perfectly in VMware, and you pay for that. Chances of a rootkit getting everything to work without the user noticing: zero.
(nb. haven’t read the article / paper yet).
Well, a “virtual machine” doesn’t necessarily have to emulate all the hardware for your system. To hide itself, all a rootkit needs to do is to stash itself in memory somewhere that the CPU can’t get too…
If the rootkit can “lift” the OS onto a “fake” memory system, so that it can’t access all of memory, then it’s impossible for the OS to see the rootkit’s code. The OS could still access all it’s devices *directly*, so it wouldn’t notice any difference from its normal hardware.
Remember that the Sony rootkit didn’t have drivers for every piece of hardware it could conceivably run on. That would be insane for anyone but a dominant OS vendor. Instead, the Sony RK merely embedded itself into the Windows kernel in a way, so that it wouldn’t be easily detectable. A RK doesn’t need to take over all the hooks into the OS, it merely needs to be able to intercept certain communications to the kernel, and be hidden.
Virtualization 101 for the sane people.
VMWare and VirtualPC are pieces of software that should be run as common limited user and installed as privileged where user is limited to RO for everything except his VM image.
In translation, rootkit would first have to break trough original virtualization (and breaking trough one does not equals breaking trough second), then break trought the security of actual underlaying OS to get needed privileges, and then after all that it could get in charge of either OS or Virtual Machines.
Now, all that MS has to do is show a proof of concept how to do this if software is used properly.
Second thing is that Virtualization machines like VMWare and VirtualPC are way of the real serious virtualization, they are just most common ways of virtualization. And the fact that for example VMWare and VirtualPC are just two pieces of software in a large collection.
Where this research would really fit, but MS is not happy to show this fact
Most common VMM in future will be .Net or Java. In practice, .Net and Java are hosting a lot of applications and having serious bug in framework means that every software endangers it. It resides on master OS, which simplifies the fact over breaking trough common virtualization a lot. But method it would need to handle is just the same as they described in their research about problems with VMWare and VirtualPC.
The more that this VM is privileged and integrated in OS the more doomsday_like results you get. And I think it is much easier to secure VMWare or VirtualPC than securing .Net on Windows. Mono on the other handdoes not suffer from this problem, you can simply limit it how high can it go and where does it run. I won’t speak about Java, because I don’t like to bluff, maybe someone can put out how to secure Java on some OS, I can’t.
Paladium???
Yes, paladium would probably solve MS problems with .Net. And yes, they are probably just trying to put out the needs for it without specifying where the need for it really is. Saying “.Net sucks and we need paladium for .Net to rock” would not be a good marketing and this is why they point out VMWare and VirtualPC as their excuse.
> In translation, rootkit would first have to break
> trough original virtualization (and breaking trough one
> does not equals breaking trough second), then break
> trought the security of actual underlaying OS to get
> needed privileges, and then after all that it could get
> in charge of either OS or Virtual Machines.
However, VM-based rootkits don’t have to run on a VMM system. They can be a significant threat to an OS running on the bare hardware without a VMM. Consider the following scenario:
* User clicks on an attachment that for some reason is able to run on their machine.
* Attachment installs a rootkit
* Rootkit inserts itself into the kernel and then “hoists” the kernel onto the rootkit’s hypervisor
* The OS is no longer running directly on the hardware, but is actually under control of the hypervisor
* To perform it’s malicious function the hypervisor doesn’t have to emulate an entire machine, it just needs to restrict access to part of it. For instance, it can partition off some memory for itself that the OS will not be able to see. Rootkit code can reside in there, undetectably, and be run alongside the OS by the hypervisor. The OS will continue running as normal in all other ways, including being able to access all its devices, etc.
* It’s now impossible for a scanner / cleaner running -within- the OS to access the memory the real rootkit is running in. It can clean the executable off the hard-drive, but it can’t detect or eliminate the presence of the hypervisor.
There would be ways to combat this, but current tools would not be able to detect a hypervisor-based rootkit.
* User clicks on an attachment that for some reason is able to run on their machine.
Ok. Still on client VM
* Attachment installs a rootkit
Ok. Still on client VM
* Rootkit inserts itself into the kernel and then “hoists” the kernel onto the rootkit’s hypervisor
Now, how does it do that? It has to know both VMM flaws and underlaying Hypervisor flaws. It can be only VMM specific, hypervisor specific and even that version related.
* The OS is no longer running directly on the hardware, but is actually under control of the hypervisor
In a fairy tale, yes it is possible. But if system is set up correctly? Not really. There’s just too many variables.
* To perform it’s malicious function the hypervisor doesn’t have to emulate an entire machine, it just needs to restrict access to part of it. For instance, it can partition off some memory for itself that the OS will not be able to see. Rootkit code can reside in there, undetectably, and be run alongside the OS by the hypervisor. The OS will continue running as normal in all other ways, including being able to access all its devices, etc.
Now how does he get that? I won’t be saying about VMWare, since I don’t realy care about childish solutions like that. Xen for example bounds domain to specifics. And VM in domain sees for example 256MB RAM and not even a byte more.
* It’s now impossible for a scanner / cleaner running -within- the OS to access the memory the real rootkit is running in. It can clean the executable off the hard-drive, but it can’t detect or eliminate the presence of the hypervisor.
Unless scanner resides on the machine containing hypervisor:) Where’s the catch that you don’t understand?
Now you’re searching rootkits on computer.
In this scenario you just search rootkits on computer containing hypervisor for that specific domain.
There would be ways to combat this, but current tools would not be able to detect a hypervisor-based rootkit.
Nope, problems are completely different here:) MS just needs Paladium for securing .Net VMM, but wants to avoid bad publicity about .Net. This is why they are seeking excuses in similiar positions, but not .Net related.
Edited 2006-03-12 20:54
I think I didn’t get my original point across clearly: that this is a threat to systems *not* running a VMM / hypervisor. There would need to be no hypervisor in the system *until* the rootkit is installed. I was suggesting the hypervisor as a means of *hiding* the rootkit’s malicious code.
I’m using the terms “VMM” and “hypervisor” fairly interchangeably here. VMM is a little bit overloaded, so I like hypervisor as being more specific. I’m 99% sure MS are talking about virtual machines as operating system containers, and not in the sense of executing the bytecode of some programming language. I don’t think MS are addressing language virtual machines in this paper.
>> * Rootkit inserts itself into the kernel and then “hoists” the
>>kernel onto the rootkit’s hypervisor
> Now, how does it do that? It has to know both VMM flaws and
> uerlaying Hypervisor flaws. It can be only VMM specific,
> hypervisor specific and even that version related.
No, if the OS is originally running on the bare hardware (e.g. on a consumer desktop) this is not the case. All the rootkit needs to be able to do is insert code into the OS kernel, which is quite feasible if the user is running with administrator privileges.
Once there, it can still be seen. To behave as a hypervisor, it might (for instance) hijack control of the interrupt handlers, so that all interrupts are taken by the rootkit code, and not by the main kernel – now the OS scheduler cannot pre-empt the hypervisor. The hypervisor can, however, choose to deliver interrupts to the kernel by emulating an interrupt stack frame and jumping explicitly to the kernel’s interrupt handler.
So this gives us a rootkit that can control the OS’s execution. But it’s still detectable by scanning the memory of the machine – it’s just in the normal kernel address space. So what now?
We need to virtualise the memory of the system. We can scan the pagetables in use by the OS we’re subverting and create a new set of pagetables that allow the OS to see all the same memory, *except* for our rootkit/hypervisor code.
Now the OS can’t see the memory used by our hypervisor. There’s no way it can, because we have the hypervisor trap all attempts by the OS to update its pagetables. Each time it tries to map some memory, we can check whether we’ll allow it. On x86 there’s no way of directly addressing physical memory, you have to use virtual addresses – so if we control the pagetables we control what the OS can see.
> Unless scanner resides on the machine containing
> hypervisor:) Where’s the catch that you don’t understand?
You’re assuming it’s a hypervisor the user has control over. If the hypervisor is *introduced* as part of the rootkit’s stealth mechanism then they don’t get to run scanners on top of it. The user doesn’t know that it’s there. They can clean up the original attachment that ran in “normal” OS space if they want, but the hypervisor is still running hidden on the system, preventing their OS from being able to detect the rootkit.
> I’m using the terms “VMM” and “hypervisor” fairly interchangeably here.
“VMM” is something on which a virtual machine runs; “hypervisor” is something which runs underneath an OS and performs functions that the OS is not sufficiently privilaged to execute. The two are independent, though quite often occur at the same time. (Xen likes to confuse the two terms, I believe for marketing reasons.) The research paper is about turning a VMM into a hypervisor.
Agreed that once running on a VMM, it’s impossible to hijack again using this mechanism (at least, with current VMMs – VMware, Xen, VirtualPC, etc.). Why? Because it’s easy to find out if you are running in a VMM.
How to virtualize a computer:
Step 1: Virtualize instructions. This means virtualizing interrupts, faults, exceptions, and all privilaged instructions. As you point out, the memory is still present, so…
Step 2: Virtualize memory. Works fine within the CPU, but non-CPU hardware breaks. (e.g. DMA, if you say “transfer memory to location X”, the location written to registers differs from the virtualized location… btw, this is what VT-d and Pacifica correct for, finally).
Step 3: Virtualize all I/O, perform the I/O under controlled conditions where memory accesses are translated. Requires knowledge of actual hardware (i.e. device driver per device), cripplingly slow hardware (no AGP, no DMA), or use virtualized device (i.e. hardware change).
— state of the art stops here —
Step 4: Virtualize time. Best way to detect if you are running on a VMM is a timing attack. VMM cannot hide all sources of time from you (think network traffic); at this point, a VMM can only hide itself from a totally useless computer.
In short, this paper makes a great deal of noise about VMM-based rootkits, but it’s all FUD. You cannot hide a VMM – not with any modern technology. And the authors expend a great number of words starting from this flawed premise. Their VMM rootkit is not undetectable, and in fact a real rootkit on a real OS is far less detectable than a VMM rootkit.
> “VMM” is something on which a virtual machine runs;
> “hypervisor” is something which runs underneath an OS
> and performs functions that the OS is not sufficiently
> privilaged to execute. The two are independent, though
> quite often occur at the same time. (Xen likes to
> confuse the two terms, I believe for marketing
> reasons.) The research paper is about turning a VMM
> into a hypervisor
I wouldn’t say they were independent, I’d say “hypervisor” is a subset of “VMM”. All environments that enable an OS to run within a container are VMMs, not all of them are hypervisors. But hypervisors by definition allow an OSS to run within a container, and hence are VMMs.
I’m leaving language virtual machines out of the picture, since I’ve always seen them described as “the virtual machine”, not a VMM: AFAICT they are fairly separate uses of the term that happen to include some common characteristics.
I seem to recall there’s some hack to find out if you’re running in a VMM on x86 hardware anyhow… It exploits the existing difficulties in virtualising x86. With hardware support (VT / SVM), this kind of test can be fooled, since it enables proper full virtualisation of x86. But this can be disabled (at least at BIOS level, I think) in order to prevent it being a problem.
I’ve just read through the research paper myself and I was slightly surprised at the approach they took. I’d have expected something more like the approach I proposed would be a lot more practical, and could be activated at runtime, rather than having to subvert the reboot path… Also, it could be used to support more conventional malware running within the OS itself. I’m not sure that’ll represent the most expedient (and therefore likely) direction for malware authors (vs more conventional attacks on anti-malware) but it seems like it’s a more likely direction than a heavyweight virtual machine technology as discussed in the paper.
I have something of an inclination to try to implement a proof of concept of what I proposed, except that I don’t think I have time left from the work I’m meant to be doing! I’ll have to list it on my homepage, maybe someone else will want a little research project.
> I wouldn’t say they were independent, I’d say “hypervisor” is a subset of “VMM”.
> All environments that enable an OS to run within a container are VMMs, not all of them are hypervisors.
> But hypervisors by definition allow an OSS to run within a container, and hence are VMMs.
IBM and Sun have had non-VMM hypervisors for quite a while on big iron. Used for partitioning (e.g. 4 CPUs to partition 1, 8 CPUs to partition 2, etc.), but they aren’t VMMs because they perform no virtualization – there is no abstraction involved, just partitioning and administration of the machine (e.g. turn off machine).
The VMM detection hack is, if I recall correctly, the load global IDT instruction (I forget the mnemonic); it must always point to a physical address so it escapes the virtualization of memory. VT avoids this particular flaw (at least, in VT mode). Ring-3 has no practical reason to need that instruction, but it IS in the architecture, so no CPU will trap it (except VT).
But that’s only the easiest hack. The timing ones are most effective: measure time. Perform a bunch of ring-0 operations (randomly generated, if possible, to defeat optimizations – from a user program, this means force the OS to perform ring-0 operations). Measure time again. If it was fast, real hardware; if slow, virtualized. Make the time measurement against a remote host over a secret protocol, and it’s impossible to defeat.
Anyway, I believe the paper is fundamentally flawed because the authors think a lightweight VMM hypervisor is easy. It isn’t, not on generic hardware (that is, not on hardware most of us have. It is only possible on hardware that you know about ahead of time, or when the VMM trusts the virtualized OS to use unknown hardware safely, like Xen’s dom0). Which tells me they don’t really understand virtualization.
> IBM and Sun have had non-VMM hypervisors for quite a
> while on big iron. Used for partitioning (e.g. 4 CPUs
> to partition 1, 8 CPUs to partition 2, etc.), but they
> aren’t VMMs because they perform no virtualization –
> there is no abstraction involved, just partitioning and
> administration of the machine (e.g. turn off machine).
Hmmmm, I hadn’t thought of that. I guess so, although I’ve never actually seen simple partition management software referred to as a “hypervisor” (I’m not sure I’ve ever seen it named as anything, since all hypervisor products now seem to support both). Does the term actually predate fully virtualising systems, then?
> Anyway, I believe the paper is fundamentally flawed
> because the authors think a lightweight VMM
> hypervisor is easy. It isn’t, not on generic hardware
> (that is, not on hardware most of us have. It is only
> possible on hardware that you know about ahead of
> time, or when the VMM trusts the virtualized OS to
> use unknown hardware safely, like Xen’s dom0). Which
> tells me they don’t really understand virtualization.
I’d suggest that in practice you *can* allow the guest direct access to the hardware. This is going to make the rootkit code smaller, improve performance and reduce what the authors call the “perturbation” relative to the original system.
This does make it easier to detect the rootkit: you can scan memory by DMA-ing it onto disk, and then back into a filesystem IO buffer (for instance). However, this is not something that I imagine current rootkit detectors do, so using virtualisation as a cloaking technology is still a threat.
I agree with your arguments on timing, though again this is still something that current rootkit detectors won’t do, so virtualisation still represents a new part of the threat model.
I must admit I was slightly disappointed with the content of the paper – it wasn’t as technically advanced or as “realistic” in terms of deployability as I’d expected. However, it did show one point in the complexity / protection spectrum and it is an interesting “proof of concept” for quite a neat idea. It will be very very interesting to see if vm rootkits appear in the wild at any stage.
Whilst it’s true that an OS usually notices that you’re suddenly running it in a virtual machine because the virtual devices are different to the devices in your real computer, this doesn’t have to be a problem in this instance.
If you’re only trying to run one “full-featured” OS on your computer then device security is not important. In this scenario it’s perfectly feasible to omit the device emulation portion of a VMM. Instead of intercepting and emulating attempts to access devices, such a minimalistic VMM might just allow the OS it hosts to drive devices directly. Your OS would see the CPU, motherboard, and other hardware that it’s accustomed to seeing. Doing this both cuts down (substantially) the code that would be required in the VMM, and makes the system look “normal” to the user and their OS.
What a rootkit VMM might want to do, is just hide itself in memory. All it really needs to do is be able to control the OS pagetables. This is possible to do right now – VMware does it, for instance, although there is quite a high degree of cunning in their code. The VMM traps the OS’s attempts to update the pagetables and instead installs its own. This may be used to transparently force the virtualised OS to use different memory to that which it requested – allowing the VMM itself and any malicious code to be completely hidden from the OS. The OS has no direct way to break out of this “memory sandbox”.
The features of current and future CPUs from AMD / Intel are helpful to authors of hypervisors and may therefore aid this type of software. Not to say that such extensions are a bad thing, just that they do have security implications. There should be straightfoward ways for OS software to prevent the abuse of these hardware features, however.
This is Microsoft Research. Though MSR is owned by MS, their methodologies are different. MS is concerned with MS products, and using/testing internally and pushing externally those products over competititor offerings.
In performing research, MSR regularly works with universities and other research firms, uses both MS and non-MS tools in carrying out such research, and regularly publishes their findings. This has little/nothing to do with .Net and everything to do with not only VPC/VMWare, but also hypervisors that will soon have almost universal support.
The research document is:
King, S., Chen, P., Wang, Y., Verbowski, C., Wang, H., and Lorch, J. SubVirt: implementing malware with virtual machines. Proceedings of the IEEE Symposium on Security and Privacy, Oakland, CA, to appear May 2006.
A copy of it is already available online at:
Cached HTML version of the below PDF:
http://cc.msnscache.com/cache.aspx?q=2957824104763&lang=en-US&mkt=e…
PDF:
http://www.astalavista.com/index.php?section=directory&linkid=6365
This talk of virtual machines… It’s been a while since I checked an Intel datasheet, but all I remember was a feature where you could run a 16-bit application on a 32-bit CPU. Does that work for 32-bit as well? Since the Window’s kernel must run in protected mode, where would this beast dwell? Windows sets-up the global descriptor table and thing thing vanishes. Are you suggesting some kind of hardware emulation or something? It would be way slow and I can’t imagine you could get-away with timing too slow for I/O and stuff.
Call me crazy, but before my website was discovered, I posted a poorly formated CD-ROM image by accident which nobody downloaded. I was trying to implement a compatible ISO9660 format on my operating system (LoseThos). Anyway, the thing made Windows act really freaky and confused–it was pretty funny, really. Nothing is called a bug any more, just a virus. About the time I did this, a story of a “root kit” and some kind of Sony hack appeared. I’m paranoid all this is an effort to make Windows the only allowed operating system at a BIOS or hardware level. This security paranoia has me terrified that hardware is going to require insider information only given to Microsoft and big companies– like hard drives that have encryption with only Microsoft granted a key. Too me, all this security paranouia seems like Microsoft trying to put a nail in the coffin forever sealing their monopoly. Did you know they keep secret the ATAPI codes for writing to a CD-ROM?
I don’t understand the mentality of hackers. Why would anybody waste their life reverse engineering other people’s crap when they could write their own. Do people find reverse engineering fun? Once you hypothesis altering the OS code, the sky’s the limit. How about simple checksums on your kernel code, like my operating system has–it’s a simple concept that’s been around for years on embedded systems? The funny thing is I did it because of paranoia over driving hardware without documentation and experiencing malfunctions. It’s nice to know when you screw-up your hard-drive right away.
Here’s something incomprehensible–a couple years ago I tried transferring a large file over a network here at home and the thing had errors in it. How is that possible? Are they so idiotic as not to include packet xsums?
Just for laughs, here’s a thought:
The paper proposes a rather heavyweight approach – run the entire OS in a virtual machine monitor. I’m not sure it’s a particularly feasible approach to implementing a rootkit in general. This seems liable to be rather obvious to the user as the OS detects a load of new / different devices on boot. In fact, with Windows XP, it’s likely to want re-activation if that much hardware changes as part of the real-to-virtual transition.
Imagine, if you will, a platform with a very restricted hardware set. Where there’s a lot of homogeneity in the systems, so it’s possible to emulate a limited set of devices and have that correspond closely to those in the real machine. But that nevertheless ships in significant volumes.
Sounds to me like the Mac would be a good target 😉 Not that that really makes Mac’s less secure in practice, but it made me smile that simple hardware homogeneity could have any security implications!
Ok, suppose there IS a way to get out of the VM.
Next you’ve got the operating system’s security. A well designed OS should not let you mess with the booting process just like so.. or at least, that’s what I think…
Linux/GNU and BSD definitely don’t let you mess with stuff…
And the vm would slow things down, so some people I think would notice..
Now let’s talk about something more interesting, the ultimate r00tkit… someone comes into your house and plugs your monitor into a malware-infested cpu of theirs… the average user shouldn’t be able to tell the difference, right?
I’m suprised the Microsoft folk aren’t studying the possibility of someone hijacking their window’s update feature. I’m mean if we’re into extreme hypothetical threats. Gee, do you suppose we’d hear about that?
I’ve never had maleware, but I’ve had to reinstall windows twice when an update got screwed-up.
Only bad people who visit disreputable sites have to worry about malware.
If you steal in any shape or form, it comes back to haunt you. Stores or Software companies who practice deception get stolen from. We can actually measure how much guilt Microsoft has by how much piracy takes place.
I fully expect this to be “modded” whatever that means–moderated? Remaindered;-)
Anyway, my sins are obvious–I don’t document as much as I should! God mentioned bugs being hell, one time and bad engineers must suffer their own hell. I use Microsoft for stuff besides programming and am happy… and honestly, my OS isn’t ready for prime time, unless you enjoy working on operating systems. Anyway, I used to have FAT support but saw an article on a patent on this site, so I made my own FS and took it out. I’m kinda hoping Microsoft will have the tables turned as a result… not likely.
It’s almost merciful of Microsoft not to put checksums in network protocols–makes it easier to establish compatibility, but I don’t have much interest in networking. If they won’t allow me to be a supplimental operating system by being pricks on FAT, they might face a full operating system. (In my dreams.)