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
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
Return to January 1996
Return to “Simon Spero <ses@tipper.oit.unc.edu>”