Re: Help on Untrusted Code?

SA043 (sa043@aol.com) wrote:
: I would be very grateful if someone could help me or point me into
: the right direction I've been told to do some research on Untrusted
: Code assuming that compilers from major vendors can be trusted and
: will not provide any security holes through which the unscrupulos can
: attack our system. I would be very gratful if any one could help
:
: [On most systems, the only trusted code is in the kernel and a few
: priviledged applications, with the rest kept at bay by hardware
: protection. As I recall, the Burroughs/Unisys stack machines depend
: on compilers to generate signed valid code. And I suppose Java compilers
: do the static analysis on bytecodes and then generate trustworthy native
: code. -John]


While I'm sure that our esteemed moderator is correct regarding
trusted code, it seems that the trust he's referring to is the trust
that code won't be looking at another process's address space and
attempting to bypass security in that way.


I think talking about trusted code requires a clear idea of what you
trust it to do. I trust a C compiler to not send mail to my enemies
each time I compile a C program. Trusting the generated code to not
overstep array bounds is a different issue.


One of the most common security loopholes, I have been told, is when a
buffer is allocated a limited number of bytes, but the code that is
storing into the buffer does not stop when that number of bytes is
input.


Many years ago, it was a common technique to use negative indices into
a common block to manipulate operating system tables that were stored
adjacent to the data for a program. In fact, some operating systems
manufacturers were known to 'leak' what the proper indices were to
perform certain functions.


Attacking a system can happen in multiple ways. I'm not sure to what
degree any compiler can protect the system from being attacked.


Dave (whitten@netcom.com) (713) 791-1414 ext 6116
[Good points. As I recall, the Burroughs code included array bounds
checks and the like to prevent the kind of subscript hacks you mention.
-John]

Return to the comp.compilers page.
Search the comp.compilers archives again.