Re: Ada's Slide To Oblivion ...

["Ian S. Nelson" <nelsonis@earthlink.net>]

Nick Roberts wrote:

> "Ole-Hjalmar Kristensen" <oleh@vlinux.voxelvision.no> wrote in message
> news:7v8za79id0.fsf@vlinux.voxelvision.no...
> 
> 
>>>Both C and C++ are fundamentally insecure languages, because they
>>>
> require a
> 
>>>'flat' address space, with no differentiation between the executable
>>>(read-only) and variable (read-write) parts. This completely subverts
>>>
> the
> 
>>Where do you get this wild idea from? There is nothing in the language
>>definition which demands this. At least on UN*X, the executable part
>>is normally put in a read-only segment. But this is not an attribute
>>of the language, but of the  hardware, OS, and the linker/loader.
>>
> 
> Perhaps I did not express myself clearly enough. If you were to re-read what
> I said, carefully, I think you will see that what I wrote does not deny that
> the executable part is put into read-only memory; on the contrary, I
> actually imply it.
> 
> Allow me to try to clarify. The C language requires (in practice if not
> strictly in theory) that all pointers fit into one machine word. On 32-bit
> architectures, this almost invariably forces the use of a 'flat' address
> space (just an offset, with no segment number or equivalent). Which means
> that, for many architectures, the operating system cannot use segmentation
> (or other memory divisions) to detect a call or jump into read-write memory.
> If it were able to do this, it could prevent the execution of code which has
> been (maliciously caused to be) written into memory (by the program itself,
> due to a bug being exploited).

  

Are we talking about processors with an MMU?  When you create a 
pagetable on most modern processors (I'm think pentiums, alpha, sparc, 
powerpc all with an MMU) you can supply permissions to the pages. 
Readable, writable, execuatable.

So when I load an app I can take the pages the the code sits in and make 
them readable and executable.  Then I can make the heap writable but not 
executable, I can make the stack read-write but not executable.  This is 
done in the kernel and they are page attributes, not address attributes. 
  Then when the mmu does the address translation it can detect page 
faults if you try to do an instruction fetch from a non-executable page 
or try to write to a read-only page which are trapped by the OS.  You 
don't need  segments to do this, and it's already done on several OSes 
one several chips with C and C++ code.

The application cannot take an address and determine the permissions for 
a given address but it shouldn't need to.  The OS will get the trap from 
the processor on a page-fault, it may or may not be able to determine 
the type of page-fault by some flags and then it can kill the process, 
or send a signal to it or whatever.

Now that I think about it, I shouldn't have snapped back so quick. 
There probably are architectures without hardware support for memory 
protection and what have you where you still might want to try to do it 
with things like segments.  I couldn't imagine them performing well 
though, but that's never stopped people.   I don't see that as C's fault 
though.


Ian


> On many architectures, then, C prevents the OS from using available memory
> protection mechanisms to prevent buffer overrun exploitation, whereas most
> other programming languages do not. In this way, C is a security liability.
> C++ generally has the same fault.
> 
> 
> "Ian S. Nelson" <nelsonis@earthlink.net> wrote in message
> news:3C6144E7.4010801@earthlink.net...
> 
> 
>>This is flat out wrong.
>>
> 
> I refer the honourable member to my previous answer.
> 
> 
> --
> Nick Roberts
> 
> 
> 
>