OSNews

did you mix up the ferengi with a sun tzu translation? because that doesn't sound very ferengi to me

Yeah. This doesn't seem like anything particularly new or really even that interesting. I refuse to have anything by McAfee or Nortons on my machines much less under the OS like that.

Soulbender,

"Only if you never have heard about virtualization and hypervisors before."

Of course virtualization is not new, but I wonder if it's using virtualization at all. It could be implemented using SMM (system management mode), which was available since the pentium era. SMM is not typically available to normal operating systems, only the bios.

Examples of it's use is putting the system to sleep and handling some special laptop buttons. SMM enables the bios to handle these without any consideration of OS compatibility.

As I have no idea what McAfee Deepsafe actually does this is pure speculation. My first thought was virtualization also.

Edited 2011-09-15 03:26 UTC

Hi,

Virtualization isn't new, but normally when virtualization is used for security it's used as a sandbox (e.g. to protect the host from the guest). What is new is using virtualization to protect a guest from itself.

Brendan,

"I can almost guarantee 'DeepSAFE' isn't using SMM."

You are probably right, but I thought it worth mentioning. The SMM is the right place to put things with oversight over the running OS, however it's not practical from a generic solution standpoint.

Assuming DeepSAFE does run the OS under a virtual machine, does that prevent the real OS from running virtual machines recursively (last I read this was not possible)? Does DeepSAFE actually emulate hardware, or do the real OS drivers have direct access to the hardware?

If DeepSAFE virtualizes hardware, this means all your hardware will need to be compatible with DeepSAFE, and there will be a performance penalty.

If DeepSAFE passes through OS control to hardware unchanged, then it implies that a rootkit might escalate it's control through hardware. For example, it might disable DeepSAFE by accessing the hard disk directly. Or it might use a video bitblt operation to r/w ram in the host.

SMM would be much more secure in this regard since it is inaccessible even to OS developers.

pgeorgi,


I've always had an itch to toy with the bios code, but never had the courage to do it and risk my motherboard. Writing bootloaders is in my expertise, and I know the bios is within reach, but as I don't have source code for my bios I have no starting point. I've researched the OSS bios projects, but I never knew if they'd be compatible.

My interest wouldn't lie in initializing the hardware myself, but rather continuing where the bios leaves off (and before the bios chains off to the bootloader). I already have a small static distro which helps remotely manage the primary OS on the PC. This way, if the primary OS gets corrupted, I need only reboot the PC and the minidistro can automatically redeploy the main OS.

This works, however I've always wished that this remote access distro existed in the bios instead of being a circumventable bootloader.

Phucked,

"'Rootkits are a result of a flaw in the person, not a flaw in the OS.'


FTFY"



The original quote was not broken.
If a non-trusted application is able to escalate it's privilege to root without user authorization, then it is a flaw in the OS. No matter what secure suite may be installed, an attack is only possible in the first place because of a flaw in the OS. A security suite may help prevent attacks and clean up after them, but it's not an excuse to leave holes in the OS.

Of course there are trojan horse attacks which coerce the user into giving them root privileges, but then that is clearly not what this article is about.

Can't wait for my bios (or EFI) to be replaced by a crapware UI from McAfee with a really nice graphical theme, but 0 useful functionnalities and some random hangs at startup.

I spent more time fixing antivirus problems (antivirus slowing everything on friend's computer) than rootkit and crapware themselves.