This page should possibly be titled R''''''ootkittingIsVirtualization, but due to W''''''ikiLanguageCannotExpressReflexiveRelations, a choice had to be made, which has an unwanted effect on the provocation potential of this page.

''Eh? You should use '''V''''''irtualizationIsTheNewRootkitting'''. ^_^''

The discussion about the possibility of virtualization rootkits has brought the idea to security researcher mainstream, but from the pattern point of view, it extends a lot farther. When analyzing the pattern, it must be realized that virtualization and rootkitting technically describe the same thing: creating a layer between execution environment and applications that ideally doesn't make any difference to the applications when compared to operating without the layer. This situation poses additional questions about ethical considerations on developing those technologies and technical considerations on sharing knowledge between both areas.

* Your definition of a rootkit is markedly different from every interpretation I've seen in security circles. A rootkit is a piece of software which wedges some other software on the system you wish to attack. The code is implemented in such a manner that it may spawn a shell interface (with the same user privileges as the software under attack), and with that, the attacker is free to access any resources accessible by the software. Hence the name: target a server known to be running as ''root user,'' and get a root shell - a ''kit'' with which you can acquire root - ''root kit.'' Nowhere does this imply virtualization at all. In fact, it ''devirtualizes'' if anything, since you're ''peeling away'' a layer of software to get at the underlying system.
** I think the referred to aspect of a rootkit is the ability to stay as invisible as possible to the subverted system. Maybe the poster should have made this clearer. Obviously, the first step is to gain the necessary privileges (usually by exploiting some security hole). But the second is to stay undetected as long as possible. And the ultimate way to do so is to provide a virtualization layer which simulates an environment where the kit is not present.

----

Virtualization is not the brightest idea anyway. It ends up with a poor version of one OS handling many applications, which is exactly what it was created to avoid. Said another way, it is like a MicroKernel, but with a worse performance hit. I would much rather have the kernel provide separate process spaces in some way (bsd jail is very good in that respect) or even not mess with separating the applications at all.

''Applications hove to be designed to run in a separate process space as soon as this situation is visible by the applications. Virtualization was invented to allow stock software to be ran in a similar manner.''

''The performance issue is a topic of its own. These days, there is some effort to create hardware which nearly eliminates the performance impact of virtualization.''

I just '''love''' when people write slanders about MicroKernel''''''s, when they themselves use an operating system which implements a wide variety of services in a typical client/server model. OK, maybe disk, video, and networking is kept resident in kernel space, but as a general rule, even on Windows, most software to get things done exists as user-level processes which expose a very microkernel-y interface. X11, anything at all COM, DCOM, or CORBA based, etc. Someone really needs to tell the pot to stop harassing the kettle. -- SamuelFalvo
----

See:MetaSignal