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 difference between a desired rootkit (encrypted magic folders, which hides and password-protects certain files, for example) and an intruding one? How would it respond? If it can't tell the difference then I hope the response wouldn't be to shut it down or stop it from working but some sort of warning. This seems a little weird though - stopping a software issue with hardware. Does that even make sense?
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.
Who will watch Intel then?
Why... Sony, of course.
While being funny, I think it underscorses a unique point about this proprosal that deserves some thought. It's all fine and dandy to check for rootkits and be big on security. If it was fair and labelled a rootkit as a rootkit, I wouldn't see too much problem with it. In a world of viruses, trojans, spyware/adware, etc... it would be nice to have one less thing to guard against.
But I see this as yet another way to bully the small guy who might be eroding a big corps market share ("Your software hurts us financially, shareholders blah blah blah, we'll throw a bunch of money at Intel and threaten them with out patent portfolio unless they mark it as a rootkit so it won't install."). Then at the same time allowing Sony to pull their rootkit crap and call it a "feature" and since it passed the "Intel Test" you could be sued for defamation of character or some such thing for daring to call a spade a spade.
Pete...
Is it OpenBSD that is keeping you safe, or is it that you have the wisdom to avoid running sketchy programs on your computer combined with the fact that there isn't much malware for OpenBSD out there waiting for you to run?
If we entered the twilight zone and imagine that OpenBSD was the dominent player in the consumer OS market we would still have tons of zombies doing bad things. Sure, thanks to ProPolice, W^X, and Guard Pages bugs in MSN and Outlook Express for OpenBSD would be less exploitable than is the case in Windows right now. None of these things help when users run programs sent by their worm infected friends. Nothing in OpenBSD prevents programs from debugging other processes running as the same user and modifying them on the fly either.
And even in an alternate universe it's questionable if making the legacy-binary-breaking changes required by these features would have allowed it to remain the dominant OS.
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.