Intel turning to hardware for rootkit detection

[gem at cigital.com (Gary McGraw)]

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:mshines at purdue.edu]
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
mshines at purdue.edu 
 


  _____  

From: mudge [mailto:mudge at uidzero.org] 
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
mshines at purdue.edu 

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at 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.
----------------------------------------------------------------------------