[Fwd: FW: We have met the enemy, and the enemy is ... you.]

[Dave Aitel <dave () immunityinc com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mailman decided to drop this one for some reason.
- -dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEPl6HB8JNm+PA+iURAgkTAKC5w7fFW/TAxGz+LuaxiTidl5lelwCdFnuZ
rcyfxfkAqhyL1zkqoOyASUc=
=ZDyX
-----END PGP SIGNATURE-----

> --- Begin Message ---
>
>
> From: "Murat Korkmaz" <m.korkmaz () determina com>
>
> Date: Wed, 12 Apr 2006 12:42:34 -0700
>
>
> FYI ..
> -----Original Message-----
> From: Murat Korkmaz 
> Sent: Wednesday, April 12, 2006 11:42 AM
> To: 'jnf'; pageexec () freemail hu
> Cc: dailydave
> Subject: RE: [Dailydave] We have met the enemy, and the enemy is ...
> you.
>
> Well, if you look closer into the details of our technology, you will
> see that we are performing run-time instrumentation and this allows us
> to monitor and control all the "control transfer" operation.
>
> That being said, even during the integer overflows or underflows,
> eventually the malicious code tries takes over the "instruction pointer"
> by subverting the execution path. That is where Memory Firewall
> technology comes into play and stops this operation even before no
> single line of malicious code run. At the end of the day, we are not
> trying to detect "exploit shellcode" whether through Ret-to-libC, or
> function pointer overwrites or any other means of existing code reuse. 
>
> Surely, compile time instrumentation can introduce other effective
> checks but nothing can beat "secure coding" practices.
>
> Murat 
>
>
> -----Original Message-----
> From: jnf [mailto:jnf () nosec net] 
> Sent: Tuesday, April 11, 2006 6:29 PM
> To: pageexec () freemail hu
> Cc: dailydave
> Subject: RE: [Dailydave] We have met the enemy, and the enemy is ...
> you.
>
> What I've never understood is why functionality available on the
> platform
> itself is not used as a means of preventing common vulnerabilities?
>
> For instance on the x86 platform you have the bound and into
> instructions
> that determine if a pointer is still within bounds and if an int
> overflow
> has occured respectively.
>
> A while back Theo made a big deal about int overflows and how they were
> undetectable to the program, however thats only at the level of the
> source, at the assembly level they are detectable and preventable.
>
> Surely it would impact performance to some degree, but at least in some
> arena's high security is valued over high performance.
>
> Whats interesting about this approach is that it could be accomplished
> at
> the layer of abstraction where the problem itself exists and be
> transparent to the user of the api. (for instance when a new variable is
> allocated we would allocate the bounds data structure and then wrap
> every
> write to the region with the bounds instruction)
>
> This could be implemented at a compiler level and significantly affect
> the
> overall security. Thoughts?
>
> --
>
> There are only two choices in life. You either conform the truth to your
> desire,
> or you conform your desire to the truth. Which choice are you making?
>
>
> On Tue, 11 Apr 2006 pageexec () freemail hu wrote:
>
> > Date: Tue, 11 Apr 2006 17:43:58 +0200
> > From: pageexec () freemail hu
> > To: dailydave <dailydave () lists immunitysec com>,
> >     "Knape, Joe" <joe.knape () cingular com>
> > Subject: RE: [Dailydave] We have met the enemy, and the enemy is ...
> you.
> > On 10 Apr 2006 at 16:13, Knape, Joe wrote:
> > > My "group" has also been looking at a "suite" of products that
> includes
> > > a "Memory Firewall" and "LiveShield" from a company called
> Determina.
> > > They make some bold claims and I've been testing it in a lab setup
> but
> > > I'd like to hear if anyone has been using it in a real-world
> > > environment?
> >
> > Determina's product is based on the research done at MIT under
> > the DynamoRIO project. google for "program shepherding" (and
> > the mispelled "sheperding" version) to find all you wanted to
> > know. in my opinion, program shepherding is the only other
> > technology that measures up to PaX, and for now it does even
> > more in fact (deterministic ret2libc attack prevention).
> >
> > unfortunately source code has never been published, so some
> > claims of security cannot be verified (e.g., their research
> > paper mentions then unresolved issues with multithreaded apps).
>
> --- End Message ---