[702] in linux-security and linux-alert archive
[linux-security] [linux-alert] Yet Another Java Hole.
daemon@ATHENA.MIT.EDU (Miller, Raul D.)
Sat May 4 12:31:03 1996
From: "Miller, Raul D." <RDMiller@legislate.com>
To: linux-alert@tarsier.cv.nrao.edu, linux-security@tarsier.cv.nrao.edu,
owner-linux-alert@tarsier.cv.nrao.edu
Date: Fri, 03 May 96 09:54:00 PDT
[This is certainly not Linux-specific, but since Java has the potential
to be a real nuisance to security-minded people everywhere I feel it's
worth a bit of discussion here (just as long as it doesn't start A
Thread That Will Not Die). --Jeff.]
David Hopwood:
Once an applet is able to run native code, it can read, write, and execute
any local file, with the permissions of the browser. These attacks do not
require any additional preconditions, other than viewing the attacker's web
page with Java enabled. They can be done without the user's knowledge.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This should be considered a Java security bug.
A Java capable browser should be capable of
(a) displaying/logging each new type of access to a new object (file, host,
...) so the user has a chance of understanding what's being looked at or
modified.
(b) requiring the user to give access permission before allowing access
[obviously there could be several variants of this].
These capabilities should go into the implementation of the java language,
and should not be implemented using a security monitor class (or whatever).
The point is that if the user doesn't have control of the interpreter, and
can't even figure out what it's touching, there will always be security
problems.
If this were done right the host access restrictions of Java would be a lot
less meaningful.
--
Raul
