Slashdot Mirror
Intel to Develop Hardware Rootkit Detection
Jack writes "ITO is running a story on Intel's latest initiative - a hardware rootkit detector: 'Intel is trying to eliminate the human factor when dealing with root-kits detection by developing a new hardware-based technique to discover and notify users when they are downloading unintentionally a root-kit to their computer.'"
Seriously, why don't they work with Microsoft to do some kind of checksum and bonk the load when it fails? This 'small chip' smells like something which would persistently degrade memory performance. Why would that be more acceptable than an operating system or BIOS which would block root-kits, i.e. you can only touch this file, this partition, etc, as logged in as root. Oh, right, on Windows processes may run under root authority and be co-opted.
Gee, seems like it's been 20 years since DEC fixed those bugs in RSTS/E
A feeling of having made the same mistake before: Deja Foobar
This is simply a marketing tactic to attempt to gain acceptance for a technology designed to get humans out of the loop whether they like it or not. There is no useful purpose for a technology designed to "protect" a machine from its owner. This marketing tactic simply tries to propose the "but what if we're trying to protect the owner from their own stupidity" angle; however, that kind of thing could be done in software as well.
The only way i can see such a device operating successfully is if the system has a read ahead feature on the currently running Code Segment, which may spark inefficencies in the system. Or perhaps when the system is loading the binary in memory do the checks then, again inefficencies would crop up.
Then there are going to be applications which will need to utilise the same patterns of operation that malicious programs use, E.G Uninstallers which wipe considerable amount of data off block devices for instance.
Perhaps such a system could be implemented on a software level on the OS's buffer cache, sort of like the way the Linux Secure Journalling system was going to operate, but this was thrown out the window because of inefficencies.
Maybe i should RTFA
Oh, that is definitly wrong. I have yet to encounter a rootkit on a Windows machine but the linux machines I administer, I have seen a few.
Infact, if you do a search for root kits on google, I am willing to bet that 90% of what google returns will be about linux/unix based rootkits. Why? Because they make it easier to over-take a server and we all know that most -big servers- are linux machines. Those are the ones that the little script kiddies want so they can take advantage of big pipes and try to DDoS their schools or something -- whatever the hell these 12 year olds are doing these days.
So yes, in this case, "Windows is the problem" doesn't really fly. Any OS is technically open to an attack from a rootkit. It all depends on the author of said rootkit to be persistant.
Don't get me wrong - I'm a linux lover and don't really like Windows that much (even though I use it) but the whole Linux Vs Windows argument isn't going to fly very far in this case. Infact, if I'm correct in thinking (Think I am, correct me if I'm not) the first rootkit was on AT&T unix (?) and did much of the same things todays rootkits do; replace core commands such as ls, ps, top, etc. They're just now morphing over to Windows.
Any bets on which OS it'll support, or rather, which it won't work with?
I thought not.
H.
When VCR's are outlawed, only outlaws will have VCR's.
So, while I'm not entirely qualified to implement this, I have thought about something in the wake of the 'sony evil'. Basically, I've often wondered if it would be possible to physically separate all core OS files in a separate storage medium. This separate space would be, on the hardware level, read only most of the time. In order to install/update/patch the core OS portions, one would have to exit the running of the OS, and 'boot' into a specific mode that has permission(again on the hardware level) to write to the OS data space.
Using a physical switch or key on the machine to set this mode would work, and wouldn't be possible to boot the OS if write mode was enabled. A form of automation would also work, in that you could have it unset this switch upon exiting the update mode of the system. Something along these lines, neh? Then you would be limited to user space corruption/exploitation/etc. True, this is a fine line to care much about, but at least you couldn't exploit a buffer overflow or some such to modify system files.
Just my 2 coppers.