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
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
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
lto:[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 protect
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
>
the
Admin side.
---Michael S
Hines[EMAIL PROTECTED]
From: mudge [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 13, 2005 6:01 PMTo: Hines,
Michael S.Cc: 'Secure Coding Mailing List'Subject: Re:
[SC-L] Intel turning to hardware for rootkit detection
There was a lady
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
AIL PROTECTED]>
To: "Kenneth R. van Wyk" <[EMAIL PROTECTED]>
Cc: "Secure Coding Mailing List"
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]>
http://www.eweek.com/article2/0,1895,1900533,00.asp
Gee this sounds just like virus wars, using add-on products to make
up for weakness in the operating system.
A reliable operating system would not permit such modifications in
the first place
Whatever happened with Intel NX technology?
Any
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
Ron Forrester wrote:
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 h
At 9:28 AM -0800 12/13/05, Ron Forrester wrote:
> 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 definit
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 hardw
At 10:54 AM -0500 12/13/05, Kenneth R. van Wyk wrote:
> FYI, eWeek has an interesting article on Intel's "System Integrity Services,"
> which aims to add hardware level protection against rootkits. Now, it seems
> to me that they're bundling all sorts of nasty critters in with their
> definitio
In message <[EMAIL PROTECTED]>, "Kenneth R. van Wyk" writes:
>FYI, eWeek has an interesting article on Intel's "System Integrity Services,"
>which aims to add hardware level protection against rootkits. Now, it seems
>to me that they're bundling all sorts of nasty critters in with their
>defini
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
> nea
16 matches
Mail list logo
