Hack Java

This illustrates the difference between a language with no dangerous
constructs, and one where you must trust the implementation.
>From some internal OSF email:
---------- Begin Forwarded Message ----------

class Data { // an object storing 16 bytes 
	byte word[16];
}


class Trick {
	Data data;
	long tricky_pointer;
	}


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.


Then if I have the code

	tricky_pointer = 10000;
	for (; tricky_pointer < 50000 ;) {
		dumptofile(trick.data)
		tricky_pointer += 16;
	}

what I am doing with this code is that I am actually setting the data
object reference to point to address 10000, then I am core dumping the
contents of memory upto address 50000, 16 bytes at a time! The byte
code is completely legal, I have cheated with the field offsets so
that I can access to the same memory as two different types.

In order to detect that the byte code verifier must verify that
all the fields of an object do not overlap in their memory
layout. That's what has to be checked.

----------- End Forwarded Message -----------

> 
> This illustrates the difference between a language with no dangerous
> constructs, and one where you must trust the implementation.
> >From some internal OSF email:
> ---------- Begin Forwarded Message ----------
> 
> class Data { // an object storing 16 bytes 
> 	byte word[16];
> }
> 
> 
> class Trick {
> 	Data data;
> 	long tricky_pointer;
> 	}
> 
> 
> 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.
> 

 What offset do you mean? The offset in the struct as in C++?
Java bytecode does not store such information. Fields are
accessed using putfield/getfield, which use an index to a
field reference in the constant pool. (pg. 66, lang spec)

Field references contain a name index (pg. 19) which points
to a name, i.e., a CONSTANT_Utf8 (pg. 18) field.

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'.

Could you describe in more detail the manipulation you are
proposing?

 - Godmar

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

On Tue, 23 Jan 1996, Rich Salz wrote:

Have you implemented this? If so, I'd be interested to hear how; It 
doesn't sound feasible.
> 
> 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.

Symbol tables in java class files don't have offsets - they consist of a 
list of class_ids, names, and types. Offsets into the class object are 
theoretically generated at run time, and are purely internal to the 
virtual machine. 

The only way to get at the offsets is through the _quick variants, which 
are not real java instructions, but placeholders inserted by the Sun 
classloader after offsets have been calculated. If the class verifier can be
made to allow _quick instructions through, security disappears - this is 
checked for- a hole in this code would be huge.

Simon

The shadowy figure took form and announced "I am Rich Salz and I say ...
> Then if I have the code
> 
> 	tricky_pointer = 10000;
> 	for (; tricky_pointer < 50000 ;) {
> 		dumptofile(trick.data)
> 		tricky_pointer += 16;
> 	}

Aside from memory management in java being internal to the virtual
machine as covered in other posts  Java is a strongly typed language.
There is no notion of void * (pointers that point to anything) and the
current implementation ensures the pointer is either null or valid.

Even if you could the current implementation disallows any pointer
arithmetic at all! i.e no pointer++;

Also if the object your pointing at is destroyed your pointer will be
updated to null or you will generate an exception when you next use it
as per the bargabe collection policy.

--Matt

On Jan 24,  5:33pm, Matthew Sheppard wrote:
> Aside from memory management in java being internal to the virtual
> machine as covered in other posts  Java is a strongly typed language.
> There is no notion of void * (pointers that point to anything) and the
> current implementation ensures the pointer is either null or valid.
>
> Even if you could the current implementation disallows any pointer
> arithmetic at all! i.e no pointer++;
>
>-- End of excerpt from Matthew Sheppard

I think the mentioned security hole is not a source level problem. The question
is how will the Java interpreter act, if there is a patched applet. Is there
any control of pointer assignments?


- Rainer

---

 RAINER HEESEN
 Adresse:    Zentrum fuer Paralleles Rechnen
             Universitaet zu Koeln
             50923 Koeln
 Telefon:    +49 221 470 6021
 Fax:        +49 221 470 5160
 eMail:      heesen@zpr.uni-koeln.de
 WWW:        http://www.zpr.uni-koeln.de/~heesen/