Intel turning to hardware for rootkit detection

[mshines at purdue.edu (Michael S Hines)]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20051214/fb91d21e/attachment.html