When java was one: Threats from hostile byte code
Saved in:
| Title: | When java was one: Threats from hostile byte code |
|---|---|
| Authors: | Mark D. Ladue |
| Contributors: | The Pennsylvania State University CiteSeerX Archives |
| Source: | http://csrc.nist.gov/nissc/1997/proceedings/104.pdf. |
| Publication Year: | 1997 |
| Collection: | CiteSeerX |
| Subject Terms: | WHEN JAVA WAS ONE, THREATS FROM HOSTILE BYTE CODE can produce, and yet, which pass |
| Description: | In Java’s first year it has become clear that many of the problems posed by executable content have not been solved. The almost exclusive focus of the Java community on executable content has left numerous avenues unexplored for threats. It has been observed that there is no one-to-one correspondence between Java source code (programs) and Java byte code (class files). While every program written in Java can be compiled to byte code by a Java compiler, it is possible to create class files which no Java compiler can produce, and yet, which pass the Java Verifier with flying colors. This fact has one very serious implication-No matter what claims are made, and even formally demonstrated, for the security of the Java language, all bets are off when it comes to byte code running in the Java Virtual Machine. This paper will explore some of the implications of this curious lack of coherence between Java source code and byte code. It will also illustrate how easy it is to alter Java class files for malicious purposes. 1. THE STATE OF JAVA SECURITY The Java programming language has recently turned one year old. In its first year, Java has had a number of spectacular holes punched in its security model by Ed Felten and the Safe Internet Programming Team at |
| Document Type: | text |
| File Description: | application/pdf |
| Language: | English |
| Relation: | http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.631.311; http://csrc.nist.gov/nissc/1997/proceedings/104.pdf |
| Availability: | http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.631.311 http://csrc.nist.gov/nissc/1997/proceedings/104.pdf |
| Rights: | Metadata may be used without restrictions as long as the oai identifier remains attached to it. |
| Accession Number: | edsbas.F5E70B15 |
| Database: | BASE |
Nájsť tento článok vo Web of Science | Abstract: | In Java’s first year it has become clear that many of the problems posed by executable content have not been solved. The almost exclusive focus of the Java community on executable content has left numerous avenues unexplored for threats. It has been observed that there is no one-to-one correspondence between Java source code (programs) and Java byte code (class files). While every program written in Java can be compiled to byte code by a Java compiler, it is possible to create class files which no Java compiler can produce, and yet, which pass the Java Verifier with flying colors. This fact has one very serious implication-No matter what claims are made, and even formally demonstrated, for the security of the Java language, all bets are off when it comes to byte code running in the Java Virtual Machine. This paper will explore some of the implications of this curious lack of coherence between Java source code and byte code. It will also illustrate how easy it is to alter Java class files for malicious purposes. 1. THE STATE OF JAVA SECURITY The Java programming language has recently turned one year old. In its first year, Java has had a number of spectacular holes punched in its security model by Ed Felten and the Safe Internet Programming Team at |
|---|