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

[Roland Perry]

In article <C6F343320DAC194BA010FD66AD49362339249F at home.usermgmt.local>, 
David Biggins <David_Biggins at usermgmt.com> writes
>Three such factors in particular formed an interesting collision of 
>decisions by three separate groups, that combined to form a serious 
>security problem.
>
>The first is the classic 'C' "null terminated string" in which there is 
>no standard (or efficient) tracking in the language of either the 
>current length of a string or the space allocated to it.
>
>For non-programmers here, that means that the standard library 
>operations to copy or concatenate a string have no intrinsic way of 
>knowing whether or not the space that a string is being copied to, is 
>actually big enough to hold it.  They just copy bytes until one of the 
>bytes is a zero.  So if you have a kilobyte of string before that zero, 
>and there's only 256 bytes of space reserved where you're copying to, 
>then tough.  768 bytes of whatever follows, are going to get trampled.
>
>It is perhaps a pity that a "strcpy() considered harmful" didn't appear 
>before billions of lines of code were written using it.

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.

Obviously(?) there must be a simple reason why not.

>The second was adoption by Intel of the "top down" hardware stack
>
>In this, the "base" of the stack is high in memory and the stack grows 
>downwards as you push values, rather than starting at the bottom of 
>memory and growing upwards.
>
>The nasty effect of this was that if you overflow the target buffer in 
>a string copy as above, when the destination is a local variable on the 
>stack, you don't just overwrite a few values then unused stack space - 
>which would have been far harder to exploit.

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?
-- 
Roland Perry