[1647] in java-interest
Re: security
daemon@ATHENA.MIT.EDU (Jonathan Payne)
Tue Sep 12 16:06:20 1995
Date: Tue, 12 Sep 1995 09:44:16 -0700
From: jpayne@starwave.com (Jonathan Payne)
To: erich@loc100.tandem.com, java-interest@java.Eng.Sun.COM
From: erich@loc100.tandem.com (halpern_eric)
Date: Mon, 11 Sep 1995 13:55:01 -0700
Subject: Security
After reading "HotJava: The Security Story", I have couple of questions.
If anyone can answer them, I'd greatly appreciate it.
According to the paper, one property ensured by the bytecode verifier is that
"when there are two execution paths into the same point, they must arrive
there with exactly the same type state". This is to protect against, for
example, a loop copying an array onto the stack.
1. How can Java protect against this and still allow for recursive function
calls? On first thought it seems that this could only be accomplished
if the "type state" of the stack only includes the current call frame.
But an array can easily be copied onto the stack using a recursive
function call, so disallowing one without disallowing the other doesn't
really solve the problem. What's going on here?
I think this is referring to the operand stack, not the call stack.
2. How could a malicious program take advantage of copying an array to the
stack? Are there any concrete examples of hacks that do such a thing?
A malicious program, generated by a malicious compiler or just a
broken compiler, could write code to push a ton of arguments onto the
operand stack, overflowing the stack. This makes sure that doesn't
happen, AND, it also make sure that when there are two paths through
the code building the operand stack, that they produce the same type.
I am just making this up, but I think it's basically what the paper is
talking about.
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
