On Tue, Dec 22, 2015 at 11:19:01AM +0000, Read, James C wrote:
I guess in the absence of a seriously thought out wish list such a project
could be open ended. >The more care spent in hardware design choices I guess
the more likely we could avoid the mess >that various legacies have caused.
Here's a suggestion for a community that is base around the claim of a
'secure' OS.
I don't think many people on this mailing list appreciate random 'suggestions',
because we already have enough ideas of our own to keep us busy.
Isn't an OS resident in RAM unsecure by default? The very fact that it is
physically possible for an OS to be modified merely by software it runs or
interacts with makes any claims of being 'secure' more than a little shaky.
I guess we could start with a design choice that our 'secure' OS is resident
in ROM only and cannot easily be modified by a user with a few software
commands.
I think you have a massive lack of knowledge of very basic computing principles.
Putting the OS in ROM would only defend against a specific class of
vulnerabilities, specifically the OS itself being overwritten. Modern hardware
has MMUs and other ways to control read/write/execute permissions on sections
of RAM. This is one reason why the Amiga was a vulnerable platform in it's
day, because the hardware lacked decent memory protection.
In any case, as long as there is any writable memory in the system, there exists
the possibility of somehow making the processor jump to it and execute code.
You can, for example, fill the memory of a smartcard with a nop slide, and place
executable code at the end. Hold the reading device over a source of heat until
it flips enough bits and it begins executing somewhere in your RAM, and
eventually gets to your exploit code.
Besides, you don't even need writable memory to explot a system. With a large
enough OS in ROM, somewhere there is bound to be a sequence of bytes that you
can use as an exploit. That may well be a byte sequence which isn't even
intended
to be executable code, or even jumping into the middle of a multi-byte
instruction, hoping that the rest that follow it would be interpreted as
something
exploitable.
For example, on a Z80, the following sequence of bytes, starting at address 0:
11 CD 00 01 00 00
Would disassemble as:
LD DE, &CD00
LD BC, &0000
I.E. you are storing one value in the DE register pair and then another value in
the BC register pair.
However, since LD DE is a multi-byte instruction, if you disassemble from
address 1, it becomes:
CALL &0001
NOP
NOP
Which would make the processor spin an endless loop, which depending on the
hardware would cause a denial of service, (lock-up, crash), and in the case of
marginal hardware, possibly cause the thing to draw more power, and overheat,
eventually jumping to another random address.
So it's quite possible to mess around and find exploits, even with software in
ROM.
0x00
Is this the first part of your new BIOS project, or something???
--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com
