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
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
definition of "rootkit" but it's worth reading, IMHO.
The detection
17 matches
Mail list logo
