On Thu, Mar 11, 2004 at 05:04:59PM +1300, Christopher Sawtell wrote:
> No software running on a current small computer is ever secure,
> because while they have the compute power many times that of the
> mainframe of yore, they do not have the security features which every
> big-iron machine had as a matter of course.
No software running on any computer is ever totally secure, nor has it
ever been. If you think the mainframe systems with heavily segmented
designs (e.g. were immune to all security flaws, you're dead wrong.
Yes, it did make exploitation of simple heap and stack smashing
vulnerabilities more difficult... and that is all.
You seem to be stuck in the mind set that security is provided by
"features", like providing "support" for security in an operating system
or processor. This is only a small part of the picture. Without a well
reasoned, continually reviewed process, and the appropriate training
backing it up, you have no security.
Also, let's not forget that much of the research into exploitation of
security vulnerabilities that has been performed in the last fifteen
years is predated mainframes by at least another fifteen years. It may
be easy for some to look years into the past and claim that the
solutions to our current security problems were already implemented in
the mainframe market, but I suggest you drag those same systems into the
harsh light of today and reevaluate the entire system's security before
making such claims.
> Neither your ubiquitous *86* machines nor, to my knowledge, any other
> computer chipset found in the current crop of personal machines is
> able to produce a hardware segfault on array bound errors or, stack
> protection errors, i.e. underflow, overflow or execution of code on
> the stack.
SPARC and Alpha, among others, have had this forever (i.e. since their
inception). On most modern processors, near-equivalent functionality
can be provided in software by the operating system.
> Until those problems are addressed by the chipset makers we will
> continue to have a continuum of crim-ware spewing over the 'Net. As
> far as computer security nothing of any substance will happen until
> the governments of the world force the issue with the chip makers. And
> they won't because those with any power in the world are all either
> corrupt or totally lacking in nous about science and technology.
Intel designed a very interesting CPU in the early 1980s that borrowed a
lot of ideas from the current mainframes. One of the key aims was
integrating these ideas on to a small set of chips suitable for
"personal computer" level machines. They named the concept the
micro-mainframe, and the result was named iAPX-432. It bombed. It
performed poorly, and was only sold in a product by one company other
than Intel.
More recently, AMD has included the ability to apply per-page RWX
permissions, in hardware, in their x86-64 offerings, and I believe
Intel's IA32e offerings will support the same functionality. Look at
the PaX, ExecGuard, and OpenBSD projects for implementations of hardware
and software per-page RWX permissions. Even Windows XP (in Service Pack
2) will have support for hardware per-page RWX permissions.
Why do we need government intervention again?
Once you have a system where the stack and heap are not writable you've
raised the bar for being exploited for a single class of security
exploitation--you're not totally immune. You're not protected from
other classes of exploits, nor are you protected from poor design or
implementation decisions that result in security exposures.
> Just accept and get used to it.
That's a sure-fire way to solve the problem.
-mjg
--
Matthew Gregan |/
/| [EMAIL PROTECTED]