1996-01-23 - Re: Hack Java

Header Data

From: Matt Miszewski <crypto@midex.com>
To: gback@facility.cs.utah.edu
Message Hash: 6bde177186ed2e45fc10cdeebe29c65f9d6abccb304b4abd6dda581af02ebe8e
Message ID: <Pine.3.89.9601232225.B4292-0100000@shaq.midex.com>
Reply To: <199601231756.KAA03101@sal.cs.utah.edu>
UTC Datetime: 1996-01-23 23:41:38 UTC
Raw Date: Wed, 24 Jan 1996 07:41:38 +0800

Raw message

From: Matt Miszewski <crypto@midex.com>
Date: Wed, 24 Jan 1996 07:41:38 +0800
To: gback@facility.cs.utah.edu
Subject: Re: Hack Java
In-Reply-To: <199601231756.KAA03101@sal.cs.utah.edu>
Message-ID: <Pine.3.89.9601232225.B4292-0100000@shaq.midex.com>
MIME-Version: 1.0
Content-Type: text/plain


On Tue, 23 Jan 1996 gback@facility.cs.utah.edu wrote:

[much elided stuff]

> > Now suppose, I fake a compiler (or I have a malicious compiler)
> > and I generate by hand malicious byte code such that
> > in the symbol tables, tricky_pointer and data have the same
> > offset.
> > 
> 

[more stuff taken out]

Godmar Said:

> 
> To my knowledge, the Java, and Java bytecode does not imply
> any memory layout. I doubt it makes sense to demand to check
> that 'offset do not overlap in memory'.
> 

Both of you are correct if you look carefully at the assumptions.  Rich 
assumes that you have a 'malicious compiler'.  Godmar is right that Java 
does not utilize pointers in the byte code.  What would make the entire 
scenario work is a malicious interpreter or a 'NotJava Browser'(TM) that 
allowed malicious code to be executed.  Couple a bad compiler and a bad 
interpreter and you are in buisness (nasty business that is).

Matt





Thread