On Thu, May 11, 2000 at 12:30:11PM +0200, Biscondi, Philippe wrote:
> WHY DO MOST (ALL?) SYSTEM ARCHITECTURES ALLOW PROCESSES OVERWRITE
> INSTRUCTIONS ?
> The problem, also known as buffer overflows/overruns, have been responsible
> for hundreds of security holes in software yielding local/remote root
There are two different approaches, hardware and software.
If you ask for hardware, I am only able to say something about i386 because
I don't know other architectures good enough.
On Intel some the problem of data overwriting the stack can be solved easily:
It should be possible to use separate memory segments for code, data and
stack. That was how 16-bit systems like DOS worked (although without write
protection), but all 32bit operating systems which I know of map the
different segments to the same address space because that's less compilicated.
There is also a software approach: Use programming languages from the Pascal
family which have strong type checking, require using dangerous pointer
operations very seldom and offer Range Checking (for strings and arrays),
Overflow Checking (e.g. for arithmetical calculations) and so on.
There are theoretical reasons why programs in "hacker" languages like C/C++
simply cannot be 100% reliable. But I cannot explain it here, whole books
could be written about it. E. g. Ada is a lange monster like C++, but the
language definition and compiler behaviour is defined much more preceisely and
noone would dare calling a compiler an ADA compiler before it fulfills tests
that it conforms to the language. That's a base for construction solid
software. As far as I know, still no C++ compiler exists that fulfills the
standard, so that's nothing you can depend on. Maybe it's even impossible to
write a 100% standard-conformant C++ compiler because the language is so
complicated and probably ambiguous.
Matthias Heidbrink E-Mail:
Bundesratufer 12 Matthias_Heidbrink@b.maus.de
10555 Berlin, Germany email@example.com
Tel. +49-30-8536361 firstname.lastname@example.org (at work; http://www.carano.com)