Signed applets as dangerous as ActiveX?
Hi all,
I have some concerns about the default java.policy file that ships with j2se 1.4. Please keep in mind that I'm a bit of a noobie when it comes to Signed Applets. I created a simple applet that writes a line in a text file on the client's filesystem. Of course, when I run this as an unsigned applet, the Security Manager intervenes and stops the action. I then signed the applet using these steps:
keytool -keygen -alias mykey
keytool -selfcert
jarsigner Test.jar mykey
I then reloaded the applet. As expected, I got the warning message that the Applet had a signature from an untrusted source. As soon as I accepted the certificate, the Applet went on its merry way writing to the local fs.
Now, this goes against my limited understanding of the behavior of signed applets. I assumed that, by default, a signed applet would need permission (i.e. another dialog box) before doing something that would put it "out of the sandbox". This way, a user would know exactly what the applet was doing and could control which secure resources the applet could use. I thought the Signed Applet solution was supposed to be a middle-path between the Java 1.1 security model of "no access" and the ActiveX model of "all or nothing access". Apparently I was wrong.
Here is where I see a problem with this. For years, applets have been touted as a "more secure" option than ActiveX. However, signed applets default to behavior that is *exactly* the same as any arbitrary ActiveX control: the user clicks a single dialog box which grants full reign to the application. The recent epidemic of ActiveX distributed mal-/spy-/ad-ware points to the simple fact that this model doesn't work. Avarage users are inherently trusting of what they download.
When CERT and the Dept. of Homeland Security recommended last week that users switch off of IE and use a different browser, I was elated. Unfortunately, it appears that the only reason we haven't seen java Applet-based attacks is that Applets are not nearly as prevailant on the Web (google for "hostile java applet", the most dangerous thing you'll see are annoyances and bugs in browsers from the late 90's). Let's face it, Applets have a terrible reputation in the user community. Many users (and company managers) still have a bad tase in their mouths from 1997 applet technology. I had hoped that this would change with the new focus that is being placed on security. What happens when/if applets do become a common way of delivering web content and users learn that it is essentially as insecure as ActiveX? What benifit is the Sandbox when Joe User can disable it entirely with a single mouse click?
[2720 byte] By [
bckrispi] at [2007-9-30 12:32:55]
> However, signed applets default to behavior that is *exactly* the same as any arbitrary ActiveX control
Incorrect in our company the admin discides what zone is trusted and what is restricted (in IE) this way
the user is not allowed to descide for himselve if he/she wants to trust an active x.
The user is not even allowed to install active x controls (or any software) on the desktop. This is done with
remote installation tools.
Since the user is not allowed to install anything on our controlled environment the admin has to install the
sun jre as well and therefore is able to take away the "do you trust privilege" from the user. You can do this
in the following manner:
java.policy under grant {
permission java.lang.RuntimePermission "usePolicy";
Forces all applet code to use policy
In java.security
change
policy.url.2=file:${user.home}/.java.policy
to
# policy.url.2=file:${user.home}/.java.policy
Now the user cannot set up it's personal policy in the home directory
For java.policy and java.security set everyone read and only admin/software distributor write access.
Another option is to use a good proxy, some proxy's allowe for configuring java settings and will not allowe
signed applet to pass through from untrusted sites.
[quote]I assumed that, by default, a signed applet would need permission (i.e. another dialog box) before doing something that would put it "out of the sandbox". This way, a user would know exactly what the applet was doing and could control which secure resources the applet could use. I thought the Signed Applet solution was supposed to be a middle-path between the Java 1.1 security model of "no access" and the ActiveX model of "all or nothing access". Apparently I was wrong.
[/quote]
Here is some info that that I found about a non-signed applet, that uses a hole in MS Java. More reasons not to use MS.
http://forum.java.sun.com/thread.jsp?forum=421&thread=532218&start=0&range=15&hilite=false&q=
wew64 at 2007-7-4 16:15:45 >
> in the following manner:
> java.policy under grant {
> permission java.lang.RuntimePermission "usePolicy";
> <--snip-->
> Another option is to use a good proxy, some proxy's
> allowe for configuring java settings and will not
> allowe
> signed applet to pass through from untrusted sites.
This essentially demonstrates my point. In a corporate environment, you have much more control. If you're a user who knows what s/he's doing, you can make it more secure. But what about My Dear Aunt Millie who has no technical expertice and uses her PC for web surfing & email? In her world, signed applets pose just as large a threat as ActiveX - "out of the box". Clicking "yes" on one dialog opens her system up entirely. This is akin to Win XP shipping with the firewall turned off. MS is changing this in its next service pack. Wouldn't it be prudent for Sun to ship the JRE with a much more restrictive java.policy?Users who know what they're doing can open it up as needed, but by default, nothing gets through.
How many dialog boxes do you need to ok the applet? One should be enough, anymore and you got your end users's head spinning about what to do next!
If the user is going to a site to use a signed applet, chances are they should have some sort of idea about the trusthworthiness of the site they are going to and they're not just buzzing around on the Internet.
My complaint is how easy you got your applet signed and running. I used to meet the forumns with questions on how to sign an applet. My short questions are still out there hanging unanswered because for some reason the solution is never straightforward and no one seems to know. On top of that the examples on how to do it change from one version of SDK to the next.
What you have here just spits out Usage notes for java 1.4.2. Just like all the other instructions I've tried....THEY DONT WORK. I finally got the jar signed by mixing instructions in a common sense way ...but still no luck writing or reading with an applet, appletviewer or not.
If you can't sign the applet try the example in the following post (copy and paste it)
http://forum.java.sun.com/thread.jsp?forum=63&thread=524815
second post
If it doesn't work post the trace.
To turn the full trace on (windows) you can start the java console, to be found here:
C:\Program Files\Java\j2re1.4...\bin\jpicpl32.exe
In the advanced tab you can fill in something for runtime parameters fill in this:
-Djavaplugin.trace=true -Djavaplugin.trace.option=basic|net|security|ext|liveconnect
The trace is here:
C:\Documents and Settings\your user\Application Data\Sun\Java\Deployment\log\plugin...log
If the user is going to a site to use a signed applet, chances are they should have some sort of idea about the trusthworthiness of the site they are going to and they're not just buzzing around on the Internet.
At the risk of sounding offensive, that is a horribly naive statement. That's the entire reason that IE and active-x have such horrendous security records. Aunt Millie sees a dialog box on some random site that tells her to click "ok" to download some arbitrary control in order to view some "cool" website a "friend" told her about. Being the trusting soul she is, she clicks "ok". Ad/spy/mal-ware, virii and system messages of "HAHA eye pwn j00!!!" soon follow.
The sandbox/policy model is *far* superior to what active-x provides. But to provide a default policy that provides full access to all signed applets is terribly, terribly shortsighted. Java should ship like Apache does: All security settings maxed out.
I'm really surprised that we don't hear more about this. The "hostile java applet", for all intents and purposes does not exist. For all rights, it should. This possibly has lulled Sun into a false sense of security where they can rest on their "sandbox" laurels.
Let's face it, most of the IT public is still stuck in 1997 as far as "java on the desktop" goes, which is unfortunate, considering the advances in Swing & the JVM in the past seven years. Sun could easily tout Java's security record as a way of supplanting Active-X. But before they do this, they really need to get their ducks in a row and fix what's broken.
Well, thats what Autie Millie gets for being too trusting. All the security dialogs I've ever seen all have standard messages and simple Yes/No/View Certificate style buttons. Auntie needs her nephew to show her how to 'just say no if you don't know' before jumpin on the Web. After all she IS given the final option of allow or disallow."Hey sonny, I clicked No, but I couldn't get to the cool website" ...then she should work on it later with someone who can help her with it.
If one is worried about viruses and does not bother to learn a bit about security before surfing, maybe they don't belong on the Internet. I don't like to see rich client-side apps suffer security just because on occasion someone doesn't know what to do when a security box comes up and ends up getting a virus they can just clean with Norton anyways.
> If one is worried about viruses and does not bother
> to learn a bit about security before surfing, maybe
> they don't belong on the Internet.
That's the attitude that Virus authors have taken for the past 20 years: "If a user doesn't notice that their command.com is suddenly 2k larger than it should be, they have no business on a PC". Sorry, I hate to break your elitist bubble, but the *majority* of internet users today are the unwashed masses. You don't have to like it, but if you want Java on the Desktop, you *have* to respect this fact. It only takes 1% of the Internet population to open a viral email, or download a hostile control to make life miserable for millions of people. Any *educated* user knows not to open an attachment that ends in *.vbs with outlook. But when the next email virus hits, it's not the dumb users that take the blame, it's Microsoft. My point is that if Sun wants another chance with Applets, they can not afford to have the bad security press that MS gets. ActiveX can afford a horrendous security record - they have the market share. Applets don't have this luxery.
>I don't like to
> see rich client-side apps suffer...
How would they suffer? My argument is that the security policy file that ships with the JVM should be tightened down. Nothing gets through unless you *explicity allow it* by editing the policy. You, being the computer literate, can then choose which signed applets from which domains get which priviliges. If aunt Millie wants the rich content, she can have her nephew turn it on for her. Meanwhile, the dumb user is stuck in the sandbox where he belongs.
>... security just
> because on occasion someone doesn't know what to do
> when a security box comes up and ends up getting a
> virus they can just clean with Norton anyways.
By the time you get around to cleaning it, that one machine could have already done a tremendous amount of damage: acting as a spam relay, contributing to a ddos attack, spreading viral code to countless other machines, etc. Norton can clean the machine, but it can't undo the damage that's already been done.
I have to agree with bckrispi, not a good idea to have the standard installation settings ask the users about
all signed applets (CA cersts will be ok but anybody can sign an applet).
Without having a lengty discussion about it here is the poit why:
When you go out do you lock the door of your house?
I still think the default installation is fine. Having to adjust policy file would eventually make applets obsolete. Non-Internet-savvy users are not likely to figure out how to go play with their policy files in order to use some company's Java application, nor will they want to deal with it in the first place.
Yes viruses are a problem, but the only real solution is to yank the network cord out of your pc. What we need is smarter firewalls and anti-virus apps. Like one that could say let applets work for this domain only.
Otherwise we'll continue to restrict functionality to the point where we cannot do anything.
I know this is a little late to be joining this conversation, but I feel I must add my 2 cents' worth:
I agree that the current default security policy is fine.
We have a Java/Corba applet that ran just fine under jdk1.3.1, but would error out with an Access Violation exception under jdk1.4.2.
Two possible solutions:
(a) make every user update his/her policy file on their client machines, or
(b) create a signed applet.
Obviously, the second solution is by far the most practical and, thank goodness, works! I don't see the danger in signed applets - the user gets a warning that must be clicked on before the applet can run.
I'm not talking about corporate users. I'm talking about home users. Explain to me how shipping the JRE with a wide open policy to end users is a Good Thing? Even Microsoft has admitted this type of philosophy is bad. If you're in a corporate setting, there are a plethora of solutions out there to distribute required files to every workstation on the network.
Please re-read my premise for this thread. I know the user gets a warning that says nothing more than "do you trust this site". Which is precisly what Active-X does. How do you address my concern about the irrelevance of the sandbox model in situations like this? How do you address the fact that java applets have had an admirable internet security record for no reason other than noone has yet bothered to exploit this flaw? How can you be a proponent of making applets a successful and pervasive Internet technology without placing user security as a primary concern?
