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 -----------
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
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
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/
participants (6)
-
gback＠facility.cs.utah.edu -
heesen＠zpr.uni-koeln.de -
Matt Miszewski -
Matthew Sheppard -
Rich Salz -
Simon Spero