[3534] in java-interest
Re: How java apps get krb tickets?
daemon@ATHENA.MIT.EDU (David R Richardson)
Wed Nov 15 19:38:46 1995
From: David R Richardson <normanb@citi.umich.edu>
To: "Larry S. Bartz" <lsbart35@emmo.indy.cr.irs.gov>
Cc: Adam Cain <acain@snapple.ncsa.uiuc.edu>, java-kerberos@lists.Stanford.EDU,
www-kerberos@lists.Stanford.EDU, java-interest@java.sun.com,
mrm@puffin.eng.sun.com
Date: Wed, 15 Nov 1995 14:36:51 -0500
In-reply-to: Your message of Tue, 14 Nov 95 11:27:42 -0500.
<Pine.SUN.3.91.951114065338.13734B-100000@emmo.indy.cr.irs.gov>
This is a multipart MIME message.
--===_0_Wed_Nov_15_14:34:50_EST_1995
Content-Type: text/plain; charset=us-ascii
A few more comments about kerberos access through java applets.
I think we still have some confusion about which resources applets will be
able to access; I've included a security summary by Marianne Mueller
of Sun and added her to this message in hope that she might be able
to clarify a few things.
> Date: Sat, 11 Nov 1995 13:52:55 -0600
> From: Adam Cain <acain@snapple.ncsa.uiuc.edu>
> To: java-kerberos@lists.Stanford.EDU
> Subject: How java apps get krb tickets?
>
[information about Kerberized Mosaic and importance of single login/
ease of use elided]
>
> But back to the orginal question of how the kerberized java app gets
> its tickets. Let me summarize my understanding of the last couple notes
> from Mark and Roland, with respect to this question (and again, please
> forgive my relative unfamliarity with the details of java's security
> mechanisms). It seems there are two basic approaches for this:
>
> 1. The java applet could get the user's kerberos password and then
> get a TGT. From that point on, it gets its own tickets from the KDC,
> as needed.
>
> 2. The java applet could get tickets using the user's ticket cache.
> Assuming the cache has a TGT, the applet can also get tickets from
> the KDC.
>
> As Mark mentioned, #1 makes security people nervous, as it is quite risky
> and somewhat contrary to the intent of kerberos.
>
> As for #2, Roland points out that the applet probably can't (and should
> not be able to) access the user's ticket cache.
Ken Arnold (addressing an unrelated issue for the
java-interest@java.sun.com
list members) also drives Roland's point home. This point was
also described by David R Richardson <normanb@citi.umich.edu> for the
java-kerberos list last week. Because the applets are not allowed to load
native methods, #1 will be the only way to go.
While I think Adam has a good summary and the issue is probably still true,
access to local files is different from using native methods. The choice
of whether or not an applet can use the file system is somewhat browser
dependent, but access to native methods seems much less likely. In addition
to file access though, we also have to worry about socket connections to
hosts other than the orriginating web server (contacting the kdc and
potentially a third server if the endpoint is different from the web
server). These connections are almost as problematic as the file access.
But in short, I think we're more likely to be able to do file and
socket access than native method access.
It seems to me that we are either going to have to implement the whole
thing in java, plus the sort of certified class loader described by Marianne,
or hope that it is included in the browser or standard java distribution.
As a side note, while I've seen descriptions like the following of the
sorts of things java can and can't do, I haven't seen any descriptions
of how java applets can take advantage of browser security features.
For example, is it possible for java applets to utilize the
RSA certificates that a netscape user might have?
David Richardson
University of Michigan
--===_0_Wed_Nov_15_14:34:50_EST_1995
Content-Type: message/rfc822
Content-Description: java security
From: mrm@puffin.Eng.Sun.COM (Marianne Mueller)
Newsgroups: comp.lang.java
Subject: Re: PRINCETON STUDENTS FIND HOLE IN INTERNET SECURITY SOFTWARE
Date: 9 Nov 1995 00:50:27 GMT
Organization: Sun Microsystems, Inc. Mt. View, Ca.
Lines: 180
Distribution: world
Message-ID: <47rj8k$6fd@handler.Eng.Sun.COM>
Reply-To: mrm@puffin.Eng.Sun.COM (Marianne Mueller)
NNTP-Posting-Host: puffin.eng.sun.com
Keywords: alpha3 hotjava security
Originator: mrm@puffin
The paper written by the two students at Princeton describes possible
attacks on the alpha3 HotJava browser, which have all been fixed in
JDK beta. Granted, until this week, the source code for JDK beta
wasn't available, so it's understandable that they analyzed the alpha3
source base.
We understand people need more information on the security model, and
we're taking time right now to document the security story more
rigorously. A security FAQ, an updated whitepaper, detailed user
documentation and detailed implementor's documentation are all being
worked on.
The Java security mechanisms include:
Java langugage mechanisms
* no pointers
* private interfaces, classes and methods
* class loader that enforces namespace divisions
* runtime byte code verifier that enforces language
type rules and name space divisions
Browser mechanisms, used by JDK beta appletviewer and by
Netscape Navigator 2.0beta
* AppletSecurity: extends java.lang.SecurityManager; strict
applet checks
* AppletClassLoader: extends java.lang.ClassLoader; strict
class loading
The goal for JDK beta is to enable browsers to run untrusted applets
in a trusted environment. The approach is to be conservative at
first, and to add functionality when it can be added securely.
So, JDK beta applets (and Netscape 2.0beta applets) may not do the
following.
1. Files:
Access Control Lists are greatly restricted in beta,
as compared to the situation in the alpha3 HotJava browser.
ACLs are initialized - only once - by the applet security
manager, and are not user configurable.
For a file not on the access control list, an applet cannot
- check for the existence of the file
- read the file
- write the file
- check the file type
- check if the file is a directory
- check the timestamp when the file was last modified
- check the file's size
- create a directory
- rename the file
- list the files in this file (as if it were a directory)
Applets cannot
- create a FileInputStream
- create a RandomAccessFile, either for reading or writing
- Open file descriptors
2. Sockets:
Applets cannot
- Create socket connections other than to its own host
- Create a socket factory
3. Loading/linking:
Applets cannot
- Create class loaders
- Access a package in the sun.* hierarchy
- Define a new class in the java.* hierarchy
- Link dynamic libraries using System.loadLibrary()
- Disable or override the AppletSecurityManager
4. Process control:
Applets cannot
- Define native methods
- Fork processes
- Manipulate threads or thread groups outside of the
applet's thread group
- Exit the virtual machine (eg the browser or the
appletviewer)
5. awt:
Applets cannot
- Create toplevel windows that don't have a warning banner
Applets can use network connections only to connect to the host they
originate from, to download files that are part of the applet's
implementation. Those files might be java bytecode class files, or
they might be input files used by the applet (GIF, JPEG, audio, other
data files.)
Taking a look at the specific attacks mentioned in the paper -
alpha3 HotJava JDK
---------------------- ---
1. socket accept() and applets cannot use
listen() aren't protected accept() and listen()
adequately, allowing a
browser to eavesdrop
2. applets can connect to applets cannot connect
the SMTP (mail) port on to the SMTP port on
some web server and use the computer the applet
that as a covert channel is visiting
3. InetAddress.getByName() applets cannot use
is public and does not InetAddress to inquire
check the security mode about hosts they are
before making DNS request not already allowed to
connect to
4. applets can use DNS to applets may not get the
create a covert channel internet address of any
host
5. Access Control Lists (ACLs) ACLs are greatly restricted
for reading and writing in JDK beta.
files are not strict enough Reading/writing files is
disabled for web browsers,
such as Netscape Navigator 2.0.
6. applets can use the System.getenv() is obsolete
System.getenv() method and is not part of the JDK
to gather information about API
the computer that it is
running on
7. applets can change the applets cannot read or alter
property manager database client properties
8. applets can change the The fields that hold the
HTTP and FTP proxy server HTTP and FTP proxy names are
private. The values are stored
in a property manager database
that an applet cannot read or
write.
It's very difficult, if not impossible, for a web browser to
completely prevent denial of service attacks. The JDK applet API
doesn't claim to prevent denial of service attacks. A "denial of
service" attack is where someone writes an applet whose goal is to
consume all available resources on your computer, forcing you to kill
the browser you're running. For example, someone could write an
applet that creates a million popup windows. The windows don't do
anything, but creating a million of them might use up all the virtual
memory on your computer and you'd have to kill the web browser to
reclaim the virtual memory.
Before people engage in too much wailing and gnashing of teeth about
how applets have been too severely restricted -
We want to enable applets to do interesting things, including making
socket connections, and reading and writing to the file system. One
way to enable that is to used a signed class loader. When a trusted
applet is loaded, then the applet could be granted permission to do
some of the things they are prevented from doing by default.
The goal is to ensure that untrusted applets can't steal or damage
information on a computer running a Java-enabled browser. Later, we
can allow trusted applets to do things that untrusted applets are not
allowed to do. Since an implementation bug in a trusted applet could
open a loophole that could be exploited by an untrusted applet, design
matters.
Marianne
Java Products Group
http://java.sun.com/people/mrm/
--===_0_Wed_Nov_15_14:34:50_EST_1995--
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
