Being safe on the internet (was Re: Here we go again - ISP DPI, but is it interception?)

[David Biggins]

> Would it not be possible to have an enhanced operation which you send,
> by way of a parameter, the maximum number of characters you are
> prepared
> to allow it to copy/concatenate. Cunningly, that might usefully be the
> remaining size of buffer that you've allocated.

Oh certainly - and the enhanced operation has existed for some time, and
modern languages don't just use zero-terminated strings and so on.

Back in 'C', using the strncpy() function to copy with a size limit,
there are a few minor problems - with not-so-minor impact.  You have to
set the parameter to the buffer size explicitly, everywhere it is used.


One problem is that while you can work out how long a string is by
counting the characters before the zero, you can't work out how long the
buffer it's stored in, is - so you have to store it yourself, and pass
it round as a parameter everywhere you pass the buffer to...  Which was
always good practice, but sadly ignored by many programmers when it was
thought that it was only a crash risk, not a point of attack.

Trivial to sort out when writing new code (and if you're writing new
code, you'd use an intelligent class or a structure that avoided the
problem),  but a nightmare if it becomes necessary to refactor existing
software.

And that still doesn't solve the real problem, which remains in the
millions of lines of code out there, in standard libraries and in the
operating system, using the original version, and imposing the
vulnerability on you, every time you call them...

> >The second was adoption by Intel of the "top down" hardware stack
> >
> Another naive question: Why not position the stack at the lower end of
> the memory map, so that nothing can rise up and bite it?

Ah - I see I haven't explained myself clearly enough.  

The problem is not something below the stack rising to bite it.  It's
from something "newer" on the stack (i.e. low in memory) overflowing its
reserved space on the stack to rise up and bite something "older" on the
stack (i.e. higher in memory).

I agree with you that none of these issues are inherently that hard to
solve.  In an object-based language, you build a standard string object
that wraps a string with its actual length and buffer length, and pass
that, and so on.

Even then, the problem comes when your shiny new "secured" string object
has to be passed to an operating system function or third-party library,
that is just expecting the null-terminated string, so you pass it the
address of the string part of your object...  


D.