Download Security and Java

Security and Object-Orientation
CSE301
Harry R. Erwin, PhD
University of Sunderland
School of Computing and Technology
1
Roadmap to the Briefing
•
•
•
•
•
Resources
Security Requirements
Object-Orientation and Security
Java Support for Security
Conclusions
2
Resources
• http://java.sun.com/security/index.html
• http://java.sun.com/j2se/1.4.1/docs/guide/security/
• B. Schneier, 2000, Secrets and Lies, Wiley, ISBN: 0-471-25311-1. A good
survey of the current threat environment.
• P. Neumann, 1995, Computer-Related Risks, Addison-Wesley, ISBN: 0201-55805-X. A survey of risks encountered by computing professionals.
• R. Anderson, 2001, Security Engineering, Wiley, ISBN: 0-471-38922-6. An
excellent UK textbook.
• Garfinkel and Spafford, Practical Unix and Internet Security, O'Reilly,
ISBN: 1-56592-148-8. The classic book on computer security.
• Norberg, 2001, Securing Windows NT/2000 Servers, O'Reilly, ISBN: 156592-768-0. A detailed Windows checklist. A UNIX checklist is provided
at www.cert.org.
• Zwicky, Cooper, and Chapman, 2000, Building Internet Firewalls, second
edition, O'Reilly, ISBN: 1-56592-871-7. Another classic.
3
Sources
• Karger and Schell, 2002, “Thirty Years Later: Lessons
from the Multics Security Evaluation,” IBM Technical
Report RC22534
• Bell and La Padula, 1976,
http://csrc.nist.gov/publications/history/bell76.pdf,
Contains significant history as well, 134 pages!
• DoD Std 5200.28 (TCSEC), “The Orange Book”,
http://csrc.nist.gov/publications/history/dod85.pdf
• Trusted Network Interpretation, “The Red Book”,
http://www.radium.ncsc.mil/tpep/library/rainbow/NCSCTG-011.html
• ISO/IEC 15408:1999, the Common Criteria.
4
Security Defined
• “Freedom from undesirable events”. (Neumann)
• There are usually three elements to security
(Qinetiq):
– Confidentiality—protection of data from unauthorized
access.
– Integrity—protection of data from unauthorized
modification. More generally, certain desirable
conditions are maintained over time
– Availability—making sure the system is usable by
authorized users.
5
Early Work
• The key paper is Bell and La Padula, 1976, which set out the
requirements for a secure Honeywell Multics OS.
• The major concern at the time was provable security—the
systems being analyzed would be managing classified
information. A lock and key approach was taken.
• These systems would used by cooperative users in isolated
mainframes. Usability and performance not major concerns.
• It was shown that a security kernel satisfying a small number
of axioms could be proven secure.
• Led to the ‘Orange Book’ with Secure Multics the model.
• Ancestor of the ‘Common Criteria’ (ISO/IEC 15408:1999).
6
Some (but not all) Recommended
Mechanisms and Procedures
• The TCSEC and the Common Criteria
recommend the following:
–
–
–
–
–
–
Access Control
Object Reuse/Media Sanitizing
Identification and Authentication
Audit
Virus Protection
Configuration Management
7
Access Control
• Based on what the user is authorized to do.
• Discretionary access control is where the
document owner controls who has access to it.
This is designed for benign environments.
• Mandatory access control defines a security level
for documents and resources. A potential user or
process has to have that level.
• Commercial organizations may go further—time
of day, location, task being performed.
• Should be enforced by operating system kernel.
8
Object Reuse/Media Sanitizing
• The random bits in memory or on the disk
contain information. Most operating
systems do not zero these bits when they
reallocate resources.
• A secure operating system zeros memory
and other resources before allocating them
(and often when the resources are released).
9
Identification and Authentication
• Identifies someone to the system.
• At least one of the following must be supplied:
– Something known (user name and password)
– Something owned (password token)
– Some physical characteristic (fingerprint, retinal scan,
voice scan)
• Authentication is weak if only one is supplied.
• Two are required for strong authentication.
10
Audit
• Tracks who did what and when.
• Done right, can stand up in court as
evidence.
• Usually must be turned on (selectively).
• May result in large audit files.
• Audit trails are extremely interesting to
hackers—show what can and cannot be
seen.
11
Virus Protection
• Viruses (and other malware) are the most serious
vulnerability of modern computer systems.
Already identified in the Multics Security
Evaluation (1974). They are usually malicious.
• Many websites now upload commercial ‘malware’
when you visit them.
• Virus protection depends on:
– Careful procedures for dealing with untrusted programs
and data.
– Programs to detect the ‘signatures’ of viruses that
manage to penetrate the installation procedures.
12
Configuration Management (CM)
It is difficult to secure a system whose
configuration is not defined and managed.
–
–
–
–
User software and hardware modifications to
workstations may occur.
Security may not be enabled.
Security may not be managed and configured.
Threats may not be addressed in a timely
fashion.
13
Internet Insecurity
• These mechanisms were suitable for isolated, unnetworked computers running in a benign
environment. The internet is another story.
• For distributed environments, the Bell-LaPadula
model of security fails. “We can tell when a security
violation occurs, but we cannot prevent it from
occurring” (Marshall Abrams).
• This resulted in the withdrawal of the Red Book.
• Neither Windows nor UNIX were originally designed
for secure operation. Upgraded to C2/TCSEC. Both
are currently CM nightmares, especially Windows. 14
Current Top 20 Vulnerabilities – Windows
(www.sans.org)
21 Oct 2002
• Internet Information Services
• MDAC—remote data services
• MS SQL
• NETBIOS
• Anonymous logon
• Weak LAN manager
authentication
• Weak passwords
• Internet explorer (many)
• Remote registry access
• Windows scripting host
21 Oct 2004
• W1 Web Servers & Services
• W2 Workstation Service
• W3 Windows Remote Access
Services
• W4 Microsoft SQL Server (MSSQL)
• W5 Windows Authentication
• W6 Web Browsers
• W7 File-Sharing Applications
• W8 LSAS Exposures
• W9 Mail Client
• W10 Instant Messaging
15
Current Top 20 Vulnerabilities – UNIX
(www.sans.org)
21 Oct 2002
• RPC
• Apache
• SSH (use SSH2)
• SNMP
• FTP
• R-services
• LPD
• Sendmail
• Bind
• Weak passwords
21 Oct 2004
• U1 BIND Domain Name System
• U2 Web Server
• U3 Authentication
• U4 Version Control Systems
• U5 Mail Transport Service
• U6 Simple Network Management Protocol
(SNMP)
• U7 Open Secure Sockets Layer (SSL)
• U8 Misconfiguration of Enterprise Services
NIS/NFS
• U9 Databases
• U10 Kernel
16
Network Security Strategies
(Zwicky, 2000)
• Least privilege—processes and users should have only the
privileges they need for their job
• Defense in depth—multiple security layers
• Choke point—limit access to your system
• Weakest link—attacks will seek vulnerabilities
• Fail-safe stance—deny access if the system fails
• Universal participation—everybody buys in
• Diversity of defense—multiple mechanisms
• Simplicity—only the simple can be made secure
• Security through obscurity—is valid (but weak)
17
Network Security Mechanisms
• Firewalls
• Intrusion Detection Systems
• Encryption
18
Firewalls
• Control access to protected assets.
• Workstation firewalls are the minimum.
• Bridge/router/switch firewalls should:
– Control access to TCP/IP ports selectively.
– Track outgoing as well as incoming packets.
– Monitor packet contents if possible.
• SOAP “bypasses corporate firewalls.”
(Microsoft)
19
Intrusion Detection
• Must be based on documented policies for use of the
system. Uses expertise.
• Can detect evidence of
– Break-ins
– Remote exploitation
– Application-level exploitation
• Generates log files of great interest to hackers.
• Does not detect one-time events
• Active research area—anyone for a PhD? See me
and Malcolm Farrow.
20
Cryptography
• Can support virtual private networks (VPNs) and
closed user groups (CUGs) where information is sent
using encrypted tunneling. Usually peer-to-peer.
• May support strong authentication.
• ssh, sftp, ssl, Kerberos, PGP, etc.
• Functional infrastructure required may be extensive.
Distribution of keys is extremely manpower-intensive
and expensive. PKI allows the distribution of keys ‘inband’ (over the network). YMMV.
21
Security Today: Lessons Learned
• Security has to be monolithic; distributed security
is demonstrably insecure.
• Security has to be designed in by experts from the
beginning; security can’t be imposed after the fact.
• Security has to be simple and easy to use
correctly.
• Security should not be bypassable.
• Multiple mechanisms are good.
• Defense in depth is good.
22
Object Orientation and Security
• Security must be designed into the infrastructure:
it should not be variably implemented or bypassed
by individual programmers.
• Security should be ‘final’; i.e., non-polymorphic.
In C++, this can be done (carefully) using
template policies.
• In a networked environment, security depends on
careful configuration management.
• Enforcement of least privilege should be built into
the system.
23
Java Approach to Security
• These considerations led the developers of Java to
embrace a ‘sandbox’ model—distrust all input
data and code, particularly code.
• This ensures that malware cannot gain access to
system resources. Similar to a chroot jail.
• Also applies to the file system in the form of a
Java Protected Domain (JPD).
• Tools:
– Class loader
– Byte-code verifier
– Security Manager
24
Java Security Goals
These revolve around access control:
– Only correct classes are loaded
– Classes are correctly formatted
– Untrusted classes are restricted from executing
dangerous instructions
– Untrusted classes cannot access protected
system resources
(Other security goals are not precluded.)
25
A Few Comments
• The JPD and the restrictions on untrusted classes can
be used to enforce least privilege, especially with
Java 1.2.
• Input data must still be validated.
• Java applet and program access is only to a JVM,
serving as a choke point. But Java security is only an
element of a defense in depth. If running under
Windows or UNIX, the usual vulnerabilities exist.
• Java provides multiple security mechanisms. One
problem with using them is US export restrictions.
• Configuration management is still necessary.
26
The Sandbox
• Untrusted applications are restricted to a sandbox.
• Damage can be done in the sandbox, but will not
affect other applications, system resources, and
files.
• Restrictions can be placed—note the can—to limit
what untrusted applications are allowed to do.
• Java security functionality is designed to form a
kernel that the application cannot break into.
27
The Class Loader
• Applets (and other classes) are invoked by
loading them with the Class Loader.
• This fetches the code and enforces the
namespace it runs in.
• Applets cannot replace system-level
components of the JVM.
• Applets are restricted in the methods they
can call.
28
The Byte-Code Verifier
• Treats the code of untrusted applications as
malware.
• Verifies the language specification.
• Detects and blocks bypassing of Java security.
• Protects against stack overflow and underflow.
• Protects against illegal data conversions and
attempts to access private data.
• This is all done prior to the code being allowed to
execute.
29
The Security Manager
• Performs run-time verification of methods that do
file I/O, network accesses, or attempt to create a
new Class Loader.
• Maintains the borders of the sandbox.
• Maintains thread integrity.
• Controls access to Java packages.
• With Java 1.2, you no longer need to subclass the
SecurityManager to enforce specialized policies.
30
JavaSecurity API
• Supports:
–
–
–
–
Digital signatures
Message digests
Key management
Access control lists
• In Java 1.2, policies and permissions have
been introduced to allow more fine-grain
control.
31
Applications and Applets
• Java applications with Java 1.2 are no longer fully trusted.
The SecurityManager can be invoked at JVM start using
the system’s default security policy, and the default policy
can also be augmented.
• Applets remain untrusted. By default,
– Cannot access files
– Stand-alone applet windows are labeled
– Cannot access the network.
• “Signed applets” can be trusted. These are delivered in
JAR format and are digitally signed.
32
Cryptography
• Subject to US export controls
• The Java Cryptography Extension (JCE)
gives you advanced cryptography.
33
End-User Security in Java
• Personal policy files can be written using
policytool and executed using the -D option. The
user has to install a SecurityManager, also using
the -D option.
• Default security policies are satisfactory. These are
available in .java.policy in the user’s home
directory.
• Multiple permissions are available.
• This is a good deal stronger than Windows or
UNIX.
34
Conclusions
• You should now have a better understanding of
security.
• You should understand why security is too
important to leave to the individual programmer.
• You should understand why security should be
part of the environment that object-oriented
programs run in.
• You should understand what general tools Java
gives you to deal with security.
35