Transcript Mobile Code

Mobile Code
Java, JavaScript, ActiveX
Prepared By : Radwan Abu Jassar
Supervised By : Dr. Lo’ai Tawalbeh
New York Institute of Technology (winter 2007)
Introduction
• Mobile code: A term that describes any
software that is mobile, being passed from
one system to another. In particular, it is
used to describe applets within web
browsers based upon Microsoft's ActiveX,
Sun's Java, or Netscape's JavaScript
technologies.
Mobile Code Examples
• Web Applets
Mini-programs written in Java, which are
automatically loaded and run on being
named in an HTML document. A document
can include a number of applets. These
may be sourced from a number of
different servers and run without the user
being aware of them.
Mobile Code Examples (Continued)
• Dynamic Email
One proposal for the provision of dynamic
email suggested incorporating Safe-TCL
scripts as components of MIME email.
These scripts could be run either on mail
delivery, or when the mail is read by the
recipient.
Low-level Security Issues
• The use of 'mobile code' raises a number of
•
•
•
•
•
•
obvious security issues:
access control - is the use of this code permitted?
user authentication - to identify valid users
data integrity - to ensure the code is delivered
intact
non-repudiation of use of the code - for both the
sender and the receiver especially if its use is
being charged
data confidentiality - to protect sensitive code
auditing - to trace uses of mobile code
Mobile Code Safety
• The prime focus of this paper is on the
techniques which can be used to provide for the
safe execution of imported code on the local
system. This has to address threats due to
rogue code being loaded and run. Of course in
many ways, these problems are not new: they
have been a key component of operating
systems design on multi-user systems for many
years. The traditional approach to addressing
these problems has been to use heavy address
space protection mechanisms, along with user
access rights to the file system and other
resources. The difference between the
traditional problems and those posed by mobile
code is one of volume and responsiveness.
Mobile Code Safety (Continued)
• Mobile code is intended for quick, lightweight
execution, which conflicts with the cost of heavy
address space mechanisms in most current
operating systems. In additon, each mobile code
unit can, in one sense, be thought of as running
as its own unique user, to provide protection
between the various mobile code units and the
system. Traditional methods of adding new users
cannot cope with this demand.
Mobile Code Safety
(Continued)
The types of attacks which need to be
guarded against include:
• denial of service
• disclosure of confidential information
• damage or modification of data
• annoyance attacks
Resource Access & Safety
• , the issue of safe execution of code comes
down to a concern with access to system
resources. Any running program has to access
system resources in order to perform its task.
Traditionally, that access has been to all normal
user resources. 'Mobile Code' must have
restricted access to resources for safety.
However, it must be allowed some access in
order to perform its required functions. Just
which types of access and how these are to be
controlled is a key research issue.
Resource Access & Safety
The types of resources to which access is required include:
•
•
•
•
•
•
•
•
file system
network
random memory
output devices (entire display, various windows, speaker)
input devices (keyboard)
process control (access to CPU cycles)
user environment
system calls
Granting Access to Resources
• One of the key issues in providing for safe
execution of 'mobile code' is determining
exactly which resources a particular code
unit is to be granted access to. That is,
there is a need for a security policy which
determines the type of access of any
'mobile code' unit. This policy may be:
Granting Access to Resources (Continued)
• fixed for all 'mobile code' units
•
•
– very restrictive but easy, and is the approach
currently used to handle applet security in web
browsers such as Netscape
that the user verifies each security-related access
request
– relatively easy, but rapidly gets annoying, and
eventually is self-defeating when users stop taking
notice of the details of the requests (whilst there is a
place for querying the user, it should be used
exceedingly sparingly)
to negotiate for each 'mobile code' unit
– much harder as some basis is needed for negotiation,
perhaps based on various profiles, but ultimately this
is likely to be the best approach
Granting Access to Resources (Continued)
• In the longer term, some mechanisms are
needed to permit negotiation of appropriate
accesses. How this is expressed is, I believe, one
of the key research issues. Initially this is likely
to be based on a simple tabular approach based
on the various categories mentioned above.
While adequate for the simplistic applets seen to
date, this is unlikely to be sufficient for more
complex 'mobile code' applications.
Granting Access to Resources (Continued)
• For these, some fairly powerful language is going to
be needed to express the required types of accesses,
along with a means of reasoning about those
requests. For example, consider a simple 'mobile code'
text-editor: it should be able to change any textual file
specified by the user, have access perhaps to a
preferences file, but otherwise be denied access to all
other files. How can this be expressed and reasoned
with? This is an area that needs considerable
additional work, but will be a key to the successful use
of 'mobile code'.
Mobile Code Technologies
Embedded Script (JScript /VBScript):
Internet Explorer includes a built-in interpreter to parse
Jscript or Visual Basic scripts (VBScript) embedded
within web pages. These scripting engines provide the
"glue" to manipulate other objects on the web page.
Both scripting engines offer common programming
constructs to control program flow (e.g. If, Then, Else,
For, Do, etc), perform simple mathematical functions,
evaluate conditions, and manipulate data types. In
addition, these languages offer the ability to load
objects, such as ActiveX controls and Java applets, call
methods on them, or set and get their properties. On the
Microsoft Windows family of operating systems both
scripting engines also include at least one "built-in"
object, the FileSystemObject, which can be called to
manipulate files or directories on the local file system as
long as those scripts aren't being run from a web page.
Mobile Code Technologies (Continued)
ActiveX Controls:
The Component Object Model (COM) is Microsoft's
architecture for creating programming objects that can
be reused and provide services to other programs. Most
of Microsoft's productivity applications are composed of
many COM objects, such as Microsoft Word, Excel,
PowerPoint presentation graphics program, and Visio
drawing and diagramming software. An ActiveX control is
simply a COM object that is designed to be downloaded
and used within web pages. Once an ActiveX control is
installed on the system it runs directly on the
workstation in the security context of the web browser
(normally the logged on user).
Mobile Code Technologies (Continued)
These objects can be scripted to perform operations by
calling their properties and methods from embedded
script within the web page. An ActiveX control can
perform any operation the user can. This makes ActiveX
controls tremendously powerful for developing browserbased applications, but also makes them very dangerous
if normal safeguards are not employed. When
developing ActiveX controls, the developer must
implement sufficient security measures to prevent their
malicious use. If the control is not safe for use by any
web page, its use from within Internet Explorer can be
disabled or the tools described below can be used to
allow the control to run only when appropriate.
Mobile Code Technologies (Continued)
Java Applets:
Like ActiveX controls, Java applets are reusable code
modules that can be downloaded and installed on the
client machine. They are created using the Java
programming language and compiled into platformneutral byte-code. Once downloaded to the client
machine the applet is loaded into a Java Virtual Machine
(VM) that interprets the byte-codes and runs the applet.
The VM normally restricts what the applet can do,
thereby limiting the functionality of the applet, but also
limiting the amount of damage a potential attacker could
do.
Conclusions
• 'Mobile code' is here with increasing demands for its use.
•
•
Safe execution of 'mobile code' implies a need for
controlled access to resources, access which ideally
should be negotiated for each 'mobile code' unit. The
means for achieving this is a subject for considerable
additional research.
Approaches taken so far to providing 'mobile code'
include the distribution of source, intermediate code, or
binary code, and the use of Just-In-Time compilers.
Experience with these systems has shown that safe and
secure systems need both correct specification and
implementation. There is still considerable research and
development needed in these systems. However, I
believe the goal of safe and secure 'mobile code'
execution is reasonable and achievable.
References
• http://www2.sims.berkeley.edu/
• University of California, School of Management &
•
•
•
•
•
•
Systems.
http://www.microsoft.com/
Microsoft Co.
http://www.sun.com/
Sun Systems
http://www.pcworld.com/
PC World Magazine