eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
When a term like “rootkit” gets enough buzz that the local Sunday paper mentions it you just have to expect vendors to blurt out that they have a solution for it, whether they do or not.
I think this is what happened with Intels recent announcement that they are working on anti-rootkit hardware, a magical rootkit-busting chip.
The technology they describe is certainly interesting and useful, but its not about fighting rootkits.
Intel has two papers I found on their site about the technology, Runtime Integrity and Presence Verification for Software Agents and OS Independent Run-time System Integrity Services. The latter paper is longer and more detailed.
SIS (System Integrity Services), as the name implies, is about protecting the integrity of the system. Thus the purpose of the hardware is to monitor specific code and data areas in the system for activities deemed to be suspicious.
While there are some references in the longer paper to rootkits, its clear that the technique was designed not so much to protect operating systems as security programs.
Its common for malware to attempt to terminate or otherwise interfere with security programs, and Intels SIS would detect this. SIS would also detect buffer overflows in monitored programs attempting to cause arbitrary code execution.
SIS uses the Intel IA-32 System Management Mode (SMM) that was designed for the SL processors almost 15 years ago for reasons, if I remember correctly, to do with power management.
In a sense it acts something like a hardware ICE (In-Circuit Emulator), the gold standard in hardware debugging, to gain absolute control over the use of hardware in the PC.
In this way it can block many software attacks in a clean and tamper-proof way. And because of SMM, it can also monitor for certain hardware-based attacks, such as a malicious device that attempted to inject attack code in the system through DMA (Direct Memory Access), which bypasses the CPU and would therefore bypass any software-based protections.
Next page: Rootkits versus SIS: And the winner Is…
Rootkits vs
. SIS: And the Winner Is…”>
So would it work? It would and it wouldnt. Clearly SIS can monitor and flag what it claims it can, but I am more concerned with false positives and the credibility of the system.
A system like SIS cannot work as hardware alone; the protections it needs to employ require a deep understanding of the operating system and certain external, trusted programs one would choose to protect.
The SIS monitoring needs to be activated on those areas of memory, and the areas will differ with different operating systems (the SIS papers make clear that the technique is not platform-specific and should work as well with Linux as with Windows).
Even different versions of Windows, perhaps even different patch levels, will require updates to the use of SIS. In fact, use of SIS probably needs to be embedded in the OS itself.
And yet, sometimes the techniques used by rootkits, or something close enough to those techniques that SIS couldnt tell the difference, are employed by legitimate add-on programs, for example, unsurprisingly, security programs themselves.
Such programs, and not to mention Windows, update themselves periodically.
So how is the SIS system to know what is a legitimate, trustworthy operating system or 3rd party component, and what is an attacker? Perhaps when requesting protection through SIS a challenge could be issued to the user, and here we enter the familiar realm of social engineering:
User pops in new music CD from our pals at Sony BMG; Software Autoplays and installs; since its smart, modern software, it registers itself with the SIS system; User is asked “do you actually trust this thing and want to let it install? User does want to let the program install, and so says yes.
Its a cynical example, but I think it raises the realistic point that Intels proposal, at least with respect to rootkits, doesnt get you around the issue of trust.
Certain programs have to be trusted generally in the system. Most users want to be able to install new programs (were talking consumers here, not businesses where IT should control what gets installed), and most users are not qualified to judge what is a trustworthy program. So what have we accomplished?
Ill go one step further and say, once again with respect to rootkits, that this sort of protection doesnt eliminate the need to do other checking of the sort performed by tools from F-Secure and Sysinternals.
People argue over what the best way is to detect rootkits. Right now I suspect it is tools like the ones I just mentioned.
Of course, a rootkit might try to interfere with tools like these too, so perhaps SIS could be helpful in protecting them, and that would be valuable. But dont count on SIS to stop a rootkits in and of itself.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
More from Larry Seltzer