The root kit blahs, another fact of users not paying attention to what they are opening or installing whether it be the home user or the corporate IT. So the Intel program alerts you, well any good firewall should also alert you of outgoing or programs communicating not authorized by you. I feel the major problem is not detecting them, it is the removal of Root Kits which can cause other programs to malfunction or the OS to crash. I did not see any explanation from Intel of how to get rid of them if you happen to be one of the unfortunate. Maybe I read the article wrong but is it not a little to late to be alerted after the fact. They need to develop a program that will detect a root kit before it gets to the registry like AV's do if it detects a virus. Major AV vendors are working on this now and from what I had read and seen they are really having a problem with root kits.
There are some registry programs that do not allow anything in until the user authorizes it so would not this defeat a root kit. I know this as I have one and even though it is a pain when I install trusted software or hardware nothing gets changed or entered into the registry unless I authorize it. Even if it does not require a registry entry my other program does not allow any new processes unless I authorize them. I know they work as I have bench tested numerous changes even using honey pot viruses which did not get by my programs. The Sony Cd I used was not allowed since it was trying to install in the registry which my registry program alerted me to. Which means the root kit never made it to my registry. Happy Holidays to all. Regards, George Greenarrow1 InNetInvestigations-Forensics ----- Original Message ----- From: "Ron Forrester" <[EMAIL PROTECTED]> To: "Kenneth R. van Wyk" <[EMAIL PROTECTED]> Cc: "Secure Coding Mailing List" <SC-L@securecoding.org> Sent: Tuesday, December 13, 2005 9:28 AM Subject: Re: [SC-L] Intel turning to hardware for rootkit detection > On 12/13/05, Kenneth R. van Wyk <[EMAIL PROTECTED]> wrote: > > The detection mechanism seems to primarily be looking primarily for > > non-OS > > software modifying OS inhabited memory blocks. Wonder how they're > > definining > > (and maintaining the definition) of each... I also wonder how it'll > > impact > > near-OS software installations like, say, device drivers, authentication > > plug-ins, and other things that need to poke pretty deeply into the OS > > in > > order to install. > > I have to admit, when I initially read about this I immediately > dismissed it as nothing but marketing hype -- what little details they > gave for the solution seemed to me to be less than practical and > certainly would have issues adapting to targeted attempts to deceive > the mechanism. > > I'd love to hear other peoples thoughts on the matter. > > -- > rjf& > > _______________________________________________ > Secure Coding mailing list (SC-L) > SC-L@securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
