No, that's a copy of stackguard. The real problem with all of these approaches is that they don't fix the root problem. Finding and removing buffer overflow conditions with a static analysis tool is far superior.
gem -----Original Message----- From: Michael S Hines [mailto:[EMAIL PROTECTED] Sent: Wed Dec 14 09:03:55 2005 To: 'Secure Coding Mailing List' Subject: RE: [SC-L] Intel turning to hardware for rootkit detection Isn't Smashguard the same technology (in software) added to the latest Microsoft .NET compiler and run time? While protecting against one method of hijacking a system (altering the function return address) - it really doesn't protect from inserting your own code into a stream and then using an existing jump to jump to your code - does it? Nor does it protect from altering the system managed data blocks? That is to say - it only protects one form of a hijack attack. Or am I missing something? Mike Hines Smashguard most recent CACM publication (Nov 05) is at - https://engineering.purdue.edu/ResearchGroups/SmashGuard/cacm.pdf if you are interested. The Smashguard Group web site is at - https://engineering.purdue.edu/ResearchGroups/SmashGuard/BoF.html I'm not affiliated with that group at Purdue - being on the Admin side. ----------------------------------- Michael S Hines [EMAIL PROTECTED] _____ From: mudge [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 13, 2005 6:01 PM To: Hines, Michael S. Cc: 'Secure Coding Mailing List' Subject: Re: [SC-L] Intel turning to hardware for rootkit detection There was a lady who went to Purdue, I believe her name was Carla Brodley. She is a professor at Tufts currently. One of her projects, I'm not sure whether it is ongoing or historic, was surrounding hardware based stack protection. There wasn't any protection against heap / pointer overflows and I don't know how it fares when stack trampoline activities (which can be valid, but are rare outside of older objective-c code). www.smashguard.org and https://engineering.purdue.edu/ ResearchGroups/SmashGuard/smash.html have more data. I'm not sure if this is a similar solution to what Intel might be pursuing. I believe the original "smashguard" work was based entirely on Alpha chips. cheers, .mudge On Dec 13, 2005, at 15:19, Michael S Hines wrote: Doesn't a hardware 'feature' such as this lock software into a two-state model (user/priv)? Who's to say that model is the best? Will that be the model of the future? Wouldn't a two-state software model that works be more effective? It's easier to change (patch) software than to rewire hardware (figuratively speaking). Just wondering... Mike Hines ----------------------------------- Michael S Hines [EMAIL PROTECTED] _______________________________________________ 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 ---------------------------------------------------------------------------- This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ---------------------------------------------------------------------------- _______________________________________________ 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
