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

Roland Perry lists at
Mon Aug 9 19:41:08 BST 2010

In article <C6F343320DAC194BA010FD66AD49362339249F at home.usermgmt.local>, 
David Biggins <David_Biggins at> 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

More information about the ukcrypto mailing list