RE: We have met the enemy, and the enemy is ... you.

[pageexec () freemail hu]

On 11 Apr 2006 at 18:28, jnf wrote:
> What I've never understood is why functionality available on the platform
> itself is not used as a means of preventing common vulnerabilities?

by 'not used' i guess you meant 'not used in widely available
systems', as otherwise it's not true, there's quite some research
that does use (or invent and implement/simulate) platform specific
features.

> 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.

'bound' has the problem of being very slow. a few years ago i did
some micro benchmarking on bounds checking primitives, 'bound' turned
out to be four times slower than a 'cmp/jb forward/cmp/jae forward'
sequence (that's on a P3, on a P4 it was even worse).

besides this low-level detail, the real problem with any bounds
checking is the storage (ABI compatibility with uninstrumented
code) and lookup (performance impact) of bounds metadata.

there're many solutions but none of them are efficient enough to
be widely deployable (google up the Jones and Kelly bounds checking
gcc extension, CRED, mudflap, etc).

> 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.

they're detectable at the source level as well, else all those
explicit overflow/wraparound checks would be in vain and we'd be
in big trouble ;-).

the real issue is that these checks must be explicitly added to the
code, which is prone to error (by being omitted altogether or badly
constructed), so automation would surely help... were it not for
constructs where overflow happens normally and causes no problems
and then you're back to manual markup.