Smashguard, if I recall correctly, offers approximately the protection
of existing compiler methods, but with the added fun of requiring
modified (non-existent) hardware.
The referenced hardware in the IEEE article and the intel.com pages
appears to be some descendant of Palladium; it is a hardwar
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
At 1:33 AM -0800 12/14/05, Crispin Cowan wrote:
> Smashguard, if I recall correctly, offers approximately the protection
> of existing compiler methods, but with the added fun of requiring
> modified (non-existent) hardware.
>
> The referenced hardware in the IEEE article and the intel.com pages
>
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
At 9:14 AM -0500 12/14/05, Gary McGraw wrote:
> 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.
But still better is using a pro
Ah yes. Type safety to all, and to all a good night.
gem
-Original Message-
From: ljknews [mailto:[EMAIL PROTECTED]
Sent: Wed Dec 14 11:36:20 2005
To: Secure Coding Mailing List
Subject:RE: [SC-L] Intel turning to hardware for rootkit detection
At 9:14 AM -0500 12/14/05
On Wed, 14 Dec 2005, ljknews wrote:
> At 9:14 AM -0500 12/14/05, Gary McGraw wrote:
> > 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
Everyone here should be familiar with Ken Thompson's famous
"Reflections on Trusting Trust." If not, see:
http://www.acm.org/classics/sep95/
The "trusting trust" attack subverts the compiler binary;
if the attacker succeeds, you're doomed. Well, til now.
I've written a paper on an approach to co
On Wednesday 14 December 2005 16:40, David A. Wheeler wrote:
> I've written a paper on an approach to counter this attack. See:
> "Countering Trusting Trust through Diverse Double-Compiling"
> http://www.acsa-admin.org/2005/abstracts/47.html
Thanks for sharing it here, David.
> Here's the abs
