exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

w6gei.htm

w6gei.htm
Posted Oct 1, 1999

Software Assurance for Security.

tags | paper, java
SHA-256 | 18b4b113c89cd59d18b65aac8b61c2b0b3c42ad43fabb3e932d965a233986eae

w6gei.htm

Change Mirror Download

<HTML>
<HEAD>
<TITLE>IC Online: Mobile Code and Security</TITLE>
<META NAME="GENERATOR" CONTENT="HAHTsite 3.1">
</HEAD>
<BODY BACKGROUND="../back.gif">
<TABLE CELLPADDING=0>
<TR>
<TD VALIGN=top WIDTH=60></TD>
<TD WIDTH=540><DIV ALIGN=CENTER><A HREF="../arch.htm"><IMG SRC="../art/s-arch.gif" WIDTH=70 HEIGHT=15 BORDER=0></A>
<IMG SRC="../redball.gif" WIDTH=16 HEIGHT=18 BORDER=0><A HREF="../links.htm"><IMG SRC="../art/s-links.gif" WIDTH=84 HEIGHT=15 BORDER=0></A>
<IMG SRC="../redball.gif" WIDTH=16 HEIGHT=18 BORDER=0><A HREF="../forums.htm"><IMG SRC="../art/s-forum.gif" WIDTH=70 HEIGHT=15 BORDER=0></A>
<IMG SRC="../redball.gif" WIDTH=16 HEIGHT=18 BORDER=0><A HREF="../events.htm"><IMG SRC="../art/s-event.gif" WIDTH=65 HEIGHT=15 BORDER=0></A>
&nbsp; <BR>
&nbsp;<A HREF=".././"><IMG SRC="../art/s-ichome.gif" WIDTH=80 HEIGHT=15 BORDER=0></A>
&nbsp;<IMG SRC="../redball.gif" WIDTH=16 HEIGHT=18 BORDER=0><A HREF="http://computer.org"><IMG SRC="../art/s-cshome.gif" WIDTH=80 HEIGHT=15 BORDER=0></A>
<P ALIGN=CENTER><IMG SRC="../linered.gif" WIDTH=400 HEIGHT=4></P></DIV><P><IMG SRC="../art/w6gei.jpg" WIDTH=70 HEIGHT=81 BORDER=0 ALIGN=LEFT HSPACE=8><FONT FACE="Arial, Helvetica, Geneva"><FONT SIZE="+3" COLOR="#1709CE"><B>Mobile
Code and Security</B></FONT></FONT> <BR>
<FONT FACE="Arial, Helvetica, Geneva" SIZE=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<B>Gary
McGraw</B> <IMG SRC="../art/bullet2.gif" WIDTH=6 HEIGHT=15 BORDER=0><I>Reliable
Software Technologies</I><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<B>Edward W. Felten</B> <IMG SRC="../art/bullet2.gif" WIDTH=6 HEIGHT=15 BORDER=0><I>Princeton
University</I></FONT> </P><BLOCKQUOTE><FONT COLOR="#072F67"><I><FONT SIZE="+2"><B>M</B></FONT>obile code
is code that traverses a network during its lifetime and executes at the
destination machine. In its most powerful guise, the same piece of mobile code
is able to run on multiple platforms (both Unix boxes and Win32 machines, for
example). This powerful idea opens up many new possibilities on the World Wide
Web, a heterogeneous collection of machines. For the first time it is possible
to have Web-based programs whose behavior is coded in some common programming
language. This code need not be compiled to tens of platforms and distributed
only after determining the target platform. Instead, mobile code is written
once and then runs wherever it ends up. There are many well-known systems for
creating and using mobile code, including Java, JavaScript, VBScript, ActiveX,
Postscript, and Word macros. </I></FONT><P><FONT COLOR="#072F67"><I> The <A HREF="../ic1998/w6toc.htm">November/December</A> issue of </I>IEEE Internet Computing<I> is concerned with the security
implications of mobile code. The problem is simply this: Running somebody
else's code on your computer is a risky activity. It is not a new problem, of
course. It's an old problem with a new twist. </I></FONT></P></BLOCKQUOTE><DIV ALIGN=center><P ALIGN=CENTER><HR NOSHADE="" WIDTH="65%" ALIGN=CENTER></P><B>See
also the sidebar<BR>
<A HREF="w6geibar.htm">Where to learn more about mobile code security</A></B> <P ALIGN=CENTER><IMG SRC="../linered.gif" HEIGHT=4 WIDTH=400></P><P ALIGN=CENTER><B><A HREF="http://computer.org/subscribe/">Become
a subscriber</A>, and you'll get access<BR>
to the full content of this great issue of <I>IEEE Internet Computing</I>.</B> </P><P ALIGN=CENTER><IMG SRC="../linered.gif" HEIGHT=4 WIDTH=400></P></DIV><P><FONT COLOR="#1709CE" SIZE="+2"><B>A
Brief History of<BR>
Security Concerns for Mobile Code</B></FONT> </P><P>In the early days of the Internet,
everyone agreed that downloading arbitrary binaries and executing them on your
machine was a Bad Idea. Of course, most people did it anyway, and some people
suffered as a result. By the mid 1980s, there was a lot of freeware and
shareware available to download. To find it, you could use Archie, which
provided a way to search a large index of anonymous FTP content. Once you found
some leads (often several ASCII pages worth), you chose your target and FTP'd
what you needed. Then you installed and ran it. </P><P>The risks of downloading and
running a random person's code on your machine are clear. If the code has a
virus attached, it can infect your machine. If the program is a Trojan Horse,
it can take over your machine for its own purposes while appearing to do
something useful. How can we be sure that a program someone says is useful
hasn't been hijacked to do something nasty? </P><P>By the late 1980s, checksumming
provided part of the answer. A checksum is a simple computation performed on a
piece of code to provide a digest or a "thumbprint" of the code using
a one-way hash function. At least a few anonymously downloadable programs
included checksum data that could be used for rudimentary data integrity
purposes, helping to ensure that the code downloaded at the end of the
communication pipe was the same as the original code distributed by its author. Of
course, who was to say that a program's checksum hadn't been tampered with or
that an author did not include Trojan Horse functionality? </P><DIV ALIGN=center><P ALIGN=CENTER><HR NOSHADE="" WIDTH="45%" ALIGN=CENTER></P><FONT FACE="Arial, Helvetica, Geneva" SIZE="+1"><B>You
can make gaffes<BR>
developing security-critical code<BR>
in any language.</B></FONT> <P ALIGN=CENTER><HR NOSHADE="" WIDTH="45%" ALIGN=CENTER></P></DIV>The
Web got its start in 1992. At first the HTML-based Web was static. Mobile code
systems like Java and JavaScript changed all that, making it possible for a Web
server to provide programs as content. The dangers of mobile code and systems
for addressing these dangers are the focus of this issue. The problem is that
systems like Java and JavaScript are so unobtrusive that a Web user may not
even notice that they are requesting and running mobile code on their computer.
What once required a conscious decision and several steps in a technological
process now requires a simple click of the mouse on a Web link. <P>This extra
risk is not very alarming if we operate under the assumption that the code
we're running is trusted. But why should a Web user trust a random piece of
code encountered on the Web? Clearly they should not. As a reaction to this
concern, many popular forms of mobile code (including Java) were designed to
run untrusted code (and, more recently, partially trusted code) in a secure
manner. This issue discusses how mobile code systems attempt to do this and to
what extent they succeed. </P><P><FONT COLOR="#1709CE" SIZE="+2"><B>Developer
Concerns</B></FONT> </P><P>From a technology perspective, a complete security solution for
mobile code will always involve two distinct parts. First, the mobile code
platform itself must be secure. For example, unless the Java Virtual Machine is
doing its job perfectly, Java's language-based approach to security will not
work.<A HREF="#1"><sup>1</sup></A> Second, any code developed for use on the mobile code
platform must be designed and implemented with security in mind. In other
words, simply writing code in Java is no guarantee of secure behavior. </P><P>Obviously,
developers play a critical role in both parts of the solution. Creating a
mobile code system is a complex undertaking that pushes the limits of available
technology and research. </P><P>Consider Java. Sun Microsystems and the Java
licensees have worked hard to evolve a system that supports secure creation and
use of mobile code. But Java is not immune to security risks.<A HREF="#1"><sup>1</sup></A><sup>,</sup><A HREF="#2"><sup>2</sup></A> Implementing a language-based security model is not easy,
and there are bound to be mistakes. </P><P>A prime example of the ways in which
Java is pushing the envelope is its combination of type safety and dynamic
loading. Java bases its security approach on type safety. Programs must be
prevented from accessing memory and other security-critical resources in
inappropriate ways. Every piece of memory is part of some Java object,
including the classes that make up the security model itself. Java is also
designed so that classes can be dynamically added and removed from the runtime
environment. Dynamic loading is handled by Java's class loading mechanisms. The
question is how to sustain type safety and allow dynamic loading at the same
time. This complex question has been addressed in a recent dissertation.<A HREF="#3"><sup>3</sup></A> Many open research issues remain. </P><P>Programming language researchers have
also done some work trying to prove the soundness of the Java language and VM
definition.<A HREF="#4"><sup>4,</sup></A><A HREF="#5"><sup>5</sup></A> Although this work is still
in preliminary stages, some interesting and suggestive results are available.
The bottom line is that the definition of Java will probably turn out to be
sound, once many more details have been filled in. </P><P>Developers are charged
with creating secure implementations of both the mobile code platform and the
code that eventually runs on the platform. Both of these tasks require a
developer to navigate the often uncharted waters of language-based security. A
necessary side effect of implementing mobile code (which can in some ways be
considered a very large security-related experiment) is making mistakes and
learning from them. </P><DIV ALIGN=center><P ALIGN=CENTER><HR NOSHADE="" WIDTH="45%" ALIGN=CENTER></P><FONT FACE="Arial, Helvetica, Geneva" SIZE="+1"><B>What
once required<BR>
a conscious decision and a process<BR>
now requires only a mouse click.</B></FONT> <P ALIGN=CENTER><HR NOSHADE="" WIDTH="45%" ALIGN=CENTER></P></DIV>What
we have learned is that it is important to develop mobile code and mobile code
platforms with a defensive stance so that neither is susceptible to attack.
Unfortunately, doing so requires extensive knowledge both of particular mobile
code systems and of computer security issues. In our book, Securing Java, we
list 12 rules Java developers should follow so that their code is harder to
attack.<A HREF="#1"><sup>1</sup></A> Similar rules can be developed for other mobile code
systems. <P>Developing secure programs in any language is neither trivial nor
automatic. Anybody who reads the newspapers or the trade press can see how
often skilled programmers write code with security bugs. You can make gaffes
developing security-critical code in any language. Know your enemy. Think about
what might confront your code in terms of malicious attacks. Mitigate risks by
designing, coding, and testing carefully. </P><P></P><DIV ALIGN=CENTER><IMG SRC="../linered.gif" WIDTH=400 HEIGHT=4></DIV><P><FONT COLOR="#1709CE" SIZE="+2"><B>The
Articles</B></FONT> </P><P>Through a peer-review process, we selected four articles that touch
on the central issues of mobile code security. </P><P>Two of them provide broad
views of this domain. </P><UL>
<LI>"<A HREF="../ic1998/w6030abs.htm">Mobile Code Security</A>," by Avi
Rubin and Dan Geer, introduces the fundamental issues and outlines five
different approaches to securing mobile code: the Java sandbox as implemented
in the Java Developers Kit 1.0 and 1.1, code signing as found in Authenticode
and the diverse Java code signing systems of JDK 1.1, the combination of
sandboxes and signatures as found in JDK 1.2, firewalling, and proof-carrying
code. The authors give excellent citations to more in-depth discussions of each
approach. <P></P></LI>
<LI>"<A HREF="../ic1998/w6035abs.htm">Securing Systems Against External
Programs</A>," by Brant Hashii, Manoj Lal, Steven Samorodin, and Raju Pandey,
describes and categorizes security risks associated with mobile code. The
security models introduced by Rubin and Geer are discussed in light of these
risk categories. Solutions are classified according to a simple framework of
phases encountered during the lifetime of mobile code: development, migration,
and execution. Diverse approaches for securing mobile code are compared and
contrasted.</LI>
</UL><P>The third and fourth articles describe models related to securing Java code
and code written in Web scripting languages. </P><P></P><UL>
<LI>"<A HREF="../ic1998/w6046abs.htm">Secure Web Scripting</A>," by Vinod
Anupam and Alain Mayer, begins with a short description of the security risks
associated with simple languages for embedding scripts in the HTML of a Web
page for interpretation by a browser. A security design is proposed that can
prevent some of the attacks commonly encountered on the Web. Many of the
fundamental characteristics of the proposed design are borrowed directly from
secure operating systems research. <P></P></LI>
<LI>"<A HREF="../ic1998/w6056abs.htm">Secure Java Class Loading</A>," by
Li Gong, describes Java's class loading mechanism, an essential piece of the
Java security model. Java's language-based approach to security is an
enforcement model based on four pieces: the verifier, which provides some type
safety analysis; class loaders, which add and remove classes dynamically from
the Java runtime environment, a security manager that enforces restrictions on
untrusted code and is the most apparent piece of the security model, and (new
to JDK 1.2) an access controller, which uses stack inspection and codified
security enforcement rules (specified by the user) to make access control
decisions. Java's dynamic class loading capability is hard to reconcile with
the security requirement for type safety. After all, if code has not yet
arrived, how can we know that it is being used in a type-safe manner? Java's
sophisticated class loading approach helps address this complex issue. Gong's
article discusses the new JDK 1.2 design with an emphasis on the internals of
class loaders.</LI>
</UL><P></P><DIV ALIGN=CENTER><IMG SRC="../linered.gif" WIDTH=400 HEIGHT=4></DIV><P><FONT COLOR="#1709CE" SIZE="+2"><B>Can
Mobile Code be Secure?</B></FONT> </P><P>Today's diverse approaches to securing mobile code
are all works in progress. Each different implementation of mobile code,
including Java, ActiveX, and JavaScript, faces similar security risks; but each
system presents a different way of dealing with the risks. In our opinion,
Java's security design stands head and shoulders above the competition. But
Java is a complex system that is evolving at a serious clip. Securing Java and
other forms of mobile code is still as much an art as it is a science. </P><P>There
is no such thing as absolute security, whether the code is mobile or stays put
right where it is developed. Creating and maintaining secure systems requires
rigorous software assurance and the ability to manage risks wisely. Mobile code
makes securing a system more complicated, but the benefits of mobile code are
often worth a bit of added risk. As the world becomes increasingly networked
and interdevice communication becomes essential, mobile code is likely to play
an increasingly important role. </P><P></P><DIV ALIGN=CENTER><IMG SRC="../linered.gif" WIDTH=400 HEIGHT=4><P ALIGN=CENTER><FONT SIZE="+1"><B>REFERENCES</B></FONT></P></DIV><BLOCKQUOTE><DL>
<DD><A NAME="1"></A>1. G. McGraw and E. Felten, <I>Securing Java: Getting Down to
Business with Mobile Code</I>, John Wiley and Sons, New York, N.Y, 1998. <P></P></DD>
<DD><A NAME="2"></A>2. D. Dean, E. Felten, and D. Wallach, "Java Security:
From Hotjava to Netscape and Beyond," <I>Proc. 1996 IEEE Symp. on Security
and Privacy</I>, IEEE Computer Society, Los Alamitos, Calif., 1996. <P></P></DD>
<DD><A NAME="3"></A>3. D. Dean, "Formal Aspects of Mobile Code Security,"
doctoral dissertation, Princeton Univ., Dept. of Computer Science, 1998. <P></P></DD>
<DD><A NAME="4"></A>4. S. Drossopoulou and S. Eisenbach, "Towards an
Operations Semantics and Proof of Type Soundness for Java," tech. report,
1998; available at <A HREF="http://outoften.doc.ic.ac.uk/projects/slurp/papers.html">outoften.doc.ic.ac.uk/projects/slurp/papers.html</A>. <P></P></DD>
<DD><A NAME="5"></A>5. R. Stata and M. Abadi, "A Type System for Java Bytecode
Subroutine," <I>Proc. 25th ACM Symp. on Principles of Programming Languages</I>,
ACM Press, New York, 1998, pp. 149-160.</DD>
</DL></BLOCKQUOTE><DIV ALIGN=CENTER><IMG SRC="../linered.gif" WIDTH=400 HEIGHT=4></DIV><BLOCKQUOTE><B>Gary
McGraw</B> <I>is vice president of business development at Reliable Software
Technologies. He holds a dual PhD in cognitive science and computer science
from Indiana University and a BA in philosophy from the University of Virginia.
McGraw coauthored both </I>Java Security: Hostile Applets, Holes, and Antidotes<I>
(John Wiley & Sons, New York, 1996) and </I>Securing Java: Getting down to
Business with Mobile Code<I> (Wiley, 1998) with Ed Felten. He has published
over 50 peer-reviewed technical papers and is principal investigator on grants
from Air Force Research labs, DARPA, and NIST's Advanced Technology Program.
McGraw is a member of the IEEE, AAAI, and Cognitive Science Society. </I> <P><HR NOSHADE="" WIDTH="55%"></P><B>Edward
W. Felten</B> <I>is assistant professor of computer science at Princeton
University. His research specialties include operating systems, Internet
software, and Internet security. He received his BS with honors in physics from
the California Institute of Technology in 1985 and his PhD in computer science
and engineering from the University of Washington in 1993. He has published
more than 40 research papers and won both a National Science Foundation Young
Investigator award and an Alfred P. Sloan fellowship for his work. </I> </BLOCKQUOTE><P><HR NOSHADE="" WIDTH="55%"></P><DIV ALIGN=CENTER>Readers
may contact <A HREF="mailto:gem@rstcorp.com">McGraw</A> and <A HREF="mailto:felten@cs.princeton.com">Felten</A> via email. <P ALIGN=CENTER><IMG SRC="../linered.gif" HEIGHT=4 WIDTH=400></P><P ALIGN=CENTER><A HREF="../"><IMG SRC="../icon1.gif" WIDTH=220 HEIGHT=50 BORDER=0 ALT="IEEE Internet Computing Online"></A>
</P><P ALIGN=CENTER><FONT FACE="arial,helvetica,geneva" SIZE=-2>Send general
comments and questions about the <I>IEEE Internet Computing Online</I> website to <BR>
<A HREF="mailto:internet-computing@computer.org">internet-computing@computer.org</A></FONT></P><P ALIGN=CENTER><FONT FACE="arial,helvetica,geneva" SIZE=-2><B><A HREF="http://www.computer.org/copyright.htm">Copyright</A> (c) 1998 Institute of Electrical and Electronics Engineers, Inc. <BR>
All rights reserved.</B> </FONT></P><P><FONT FACE="arial,helvetica,geneva" SIZE=-2> <HR NOSHADE="" WIDTH="20%" ALIGN=CENTER>
<FONT FACE="arial,helvetica,geneva" SIZE=-2 COLOR=red><I>IConline</I> designed and
maintained by <A HREF="mailto:swoods@computer.org">Steve Woods</A></FONT></FONT></P></DIV></TD>
</TR>
</TABLE>
</BODY>
</HTML>
Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close