Checking integrity of signed applets in JRE cache

Hello,
I noticed that my JRE (Version 6 Update 24) does not check, if a signed applet, that is cached locally, has been modified before loading it. It seems to me like this is a security problem that could easily be prevented. Does anyone know if this is a desired behavior and if there is a way to tell the JRE to check the integrity of cached applets?
Best regards!

If any malicious code has sufficient privileges to manipulate the cache of signed applets, then it can easily do much worse things than elevate the privileges of some unsigned Java code.

Similar Messages

Java.util.ConcurrentModificationException when launching aa signed applet .

I am getting the following error while trying to launch a signed applet with JRE 1.6.0_01. It works fine on most of the machines.
Any help, advise is appreciated.
Thanks

Did not include the full stack trace, here it is:
ava.util.ConcurrentModificationException
     at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
     at java.util.AbstractList$Itr.next(Unknown Source)
     at com.sun.deploy.security.WIExplorerCertStore.getCertificates(Unknown Source)
     at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
     at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
     at sun.plugin.security.PluginClassLoader.getPermissions(Unknown Source)
     at java.security.SecureClassLoader.getProtectionDomain(Unknown Source)
     at java.security.SecureClassLoader.defineClass(Unknown Source)
     at java.net.URLClassLoader.defineClass(Unknown Source)
     at java.net.URLClassLoader.access$000(Unknown Source)
     at java.net.URLClassLoader$1.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.net.URLClassLoader.findClass(Unknown Source)
     at sun.applet.AppletClassLoader.findClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at sun.applet.AppletClassLoader.loadClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at sun.applet.AppletClassLoader.loadCode(Unknown Source)
     at sun.applet.AppletPanel.createApplet(Unknown Source)
     at sun.plugin.AppletViewer.createApplet(Unknown Source)
     at sun.applet.AppletPanel.runLoader(Unknown Source)
     at sun.applet.AppletPanel.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)

Classloader caching in signed applet is very slow and weird

I have a signed applet running in the 1.4.1_01 plugin environment, and
I'm getting the following kinds of messages when I use debug mode 5 in the console:
Connecting http:[myserver]/someclass.class with no proxy
Connecting http:[myserver]/someclass.class with cookie "JSESSIONID=..."
Sometimes, the classloader will say:
WARNING: Unable to cache someclass.class
Moreover, some classes will be repeated two or three times, as if the classloader is trying to get the same class two or three times.
Some of these classes are even in the java.lang package!!
The thing is, I'm actually trying to get the applet to use webservices, so I've signed the Apache Axis jar files (about 8 or so) and included them in the "cache_archive" parameter. The classes giving problems are from these archives, not from my main applet jar.
The applet will eventually work, but the first time takes a LONG time to initialize because the classloader is trying to verify all the classes (i think). Subsequent runnings of the applet within the same browser will be much faster, but the same thing will happen if I start a new browser instance.
My questions are:
1) Why is the classloader trying to load from my http server rather than from the local jars? (they seem to be statically cached, I checked the plugin control panel)
2) Why is the classloader reloading the same classes multiple times?
3) Is the classloader verifying the signatures for each class, because it's taking a long time due to very many classes (100's).
I can't seem to find ANY documentation for this at Sun or Google.
Please help if you can!
Andrew

I've got the same problem with applet using SOAP based on jwsdp.
But classloader only try to get classes from server that are used in SOAP calls.
The only workaround I found is to move this classes to root package, but still there are problems with
Connecting http://<host>/int.class with no proxy
Connecting http://<host>/int.class with no proxy
WARNING: Unable to cache http://<host>/int.class
requests.
Maybe this is a bug of Sun SOAP implementation?

JRE 1.4.x Plugin - Signed Applets and Weird Behaviour (Policy)

Hello.
I have recently experienced some strange behaviour related to signed applets and policy files in JRE 1.4.2-b28 ( a friend got the same behaviour in a flavour of 1.4.1-xx as well ). Both tests were on Windows 2000 Professional platforms.
Initially my unsigned applet, which attempts socket connections to a server different from the download location, fails with security exceptions ( as expected ). Then I did the following to sign the applet jar and configure my environment
Steps: 1) Import "trusted CA" certificate into ${java.home}/lib/security/cacerts. (JRE home outside the JDK)
2) Signed the jar using jarsigner and a certificate generated from the "trusted CA" (Entrust CA and certificate).
3) Imported the signing certificate into the Java plugin using import in the plugin control panel.
4) Created a new keystore (keytool,jks) and imported the signing certificate into the keystore with alias "developer". The keystore is stored in the user home as .keystore.
5) Created a .java.policy for the user and attaching the keystore in 4) to it. ( also stored in user home ).
6) Used the policy tool to grant socketpermissions to the specific codebase ( testing with file:/C:/test/* initially ) signed by "developer"
After this, when I ran the test page under IE 5.5SP2 and Netscape 7.1 it worked without any security exception. Ditto for using the appletviewer and the policy file I created for the user.
The weird part occurred when I removed the policy entry from the user policy file. After doing this, Netscape and IE still allow the applet to execute - somehow remembering that it was granted permissions at some point. The appletviewer does not allow it to execute, generating security exceptions.
It appears the old policy is being cached somewhere, but I cannot find where. If I replace the applet jar with an unsigned version it does fail in IE and Netscape. I tried cleaning the plugin cache and removing the "deployment.certs" files related to the users but still get the same behaviour.
Does anyone know where the old policy information is being stored ? Does anyone know how to revoke the permissions so that I am restored to my original base environment ( no permissions for "designer" signed applets ) ? Would attempting to utilize the AccessController.doPriveleged( xxxx ) operations in JDK 1.4 avoid all of this confusion with policy files, keystores and certificate storage ? After all the messing about I would like a zero-footprint alternative ( or minimzed footprint anyway ).
Any ideas would be most welcome.
Regards,
James.

Hello Again.
I am either enlightened or confused at this point. I found that as long as all of my related Jars are signed ( even by self-signed certificates ) I am granted SocketPermissions for calls outside of the originating server. Unsigned code is refused, but even when the Jars were signed using a self-signed certificate the Socket calls were allowed.
Am I experiencing the appropriate behaviour in this case ( which would mean not having to utilize policy files to distribute an applet that uses calls to arbitrary servers - e.g. JavaMail ) or am I suffering from something damaged in my environment ?
It has been a long time since I played with signed applets and I am having difficulty determining what operations require policy file entries/AccessController.doPrivileged() calls and which are granted when a user elects to trust a signed applet without policy.
Any assistance in clearing up my confusion would be appreciated.
Regards,
James.

Problems with signed Applet for File Download under JRE 1.4 (works with 1.3

Dear all,
i encountered a very strange behaviour with JRE 1.4x. A signed applet used for file download worked on all platforms (Windows NT, 2000 and XP wth/wthout SP...) until I installed JRE 1.4.x (1.4.1 or 1.4.2)
I get an EOFException when downloading binary files (for ASCII it works fine) when trying to readByte() from a DataInputStream. But not immideately, but after x bytes in the while-loop. Security is fine (I know there have been changes to that in jre 1.4, the applet itself can be started an runs with ASCII files for transfer)
Does anyone know, what has changed in jre1.4.
As I said, it works fine under jre 1.3.x
The relevant code is below: byte bt = dis.readByte(); causes the error
try{
// Get URL from Server
URL uFile = new URL(sFilename);
sThisURLFile = uFile.getFile();
Integer inte = new Integer(i);
//open input stream for the file on server
DataInputStream dis = new DataInputStream(new BufferedInputStream
(uFile.openConnection().getInputStream()));
//open output stream for the file on local drive
String sFilenameOnly = sThisURLFile.substring(sThisURLFile.lastIndexOf('/')+1);
int iDotPos = sFilenameOnly.lastIndexOf(".");
String sExt;
if (iDotPos > 0) {
sExt= sFilenameOnly.substring(iDotPos);
} else {
sExt = "";
File fileOut = new File(sDownloadDir + sThisURLFile.substring(sThisURLFile.lastIndexOf('/')+1) );
DataOutputStream dos = new DataOutputStream(new
BufferedOutputStream(new FileOutputStream(fileOut)));
//read one byte from input stream, and write that byte to output stream
long nByte = 0;
int iCnt = 0;
iFilesizeDone ++;
while (nByte < iFilesize){
String sErrPs = new String();
try{
sErrPs = "00";
byte bt = dis.readByte();
sErrPs = "01";
dos.writeByte(bt);
} catch (EOFException ee)
System.err.println("internal EOFException: " + ee.getMessage());
System.out.println("Error Filesize is " nByte " of " iFilesize "---" + sErrPs);
break;
nByte++;
iFilesizeDone ++;
iCnt ++;
if(iCnt >= 10240) {
ShowProgress(nByte, iFilesize, iFilesizeDone, iFilesizeTotal); // repaint does not work during init-procedure
iCnt = 0;
line = "Progress: Total: " + ((iFilesizeDone*100)/iFilesizeTotal) + " perc, " + iFilesizeTotal/1024 +" kbytes" ;
labLine.setText(line);
//dos.flush(); // improves Client performance (Agent-Call!)
dis.close();
dos.close();
}// End try
catch (EOFException ee)
System.err.println("EOFException: " + ee.getMessage()e);
catch (SecurityException se)
System.err.println("SecurityException: " + se.getMessage());
catch (IOException ioe)
System.err.println("IOException: " + ioe.getMessage());

perhaps they've changed something with the file blocking.
btw, you should try to use something like this
DataInputStream dis = new DataInputStream(is);
byte[] buffer=new byte[8192];
int numBytesRead;
while ( dis.available()>0 ) {
numBytesRead = dis.read(buffer);
}

Signing and checking signature of the applet

hello everybody;
i want to download a signed applet on the smart card, and check its signature;
shall i check the signature off the card before the download or its to the card manager to do it
thanks for help

Signature generation and verification can be done on-card.

OS X 10.5.6, Safari 3.2.1 hangs when second applet loaded is signed applet

Dear Forum,
I've been investigating a customer's problem. She is trying to use our
VoIP applet, but it continuously freezes Safari when the Trust dialog shows.
A "Force Quit" is necessary.
I managed to reproduce the problem consistently on
- PowerMac7 OS X 10.5.6 (Build 9G55)
- Architecture: ppc
- Safari 3.2.1 (5525.27.1)
- JVM 1.5.0_16 from Apple
The problem is persistent when:
- the signed applet is loaded as second applet in the browser
- the signed applet is cached by the JVM
Our customer uses:
- Mac Book ProOS X 10.5.6
- Safari 3.2.1
- JVM 1.5.0_16 from Apple
This problem does not occur on:
- Mac OS X 10.4.11 (Mac Powerbook G4)
- Safari 3.2.1 (4525.27.1)
- JVM 1.5.0_16 from Apple
and not on:
- MacBook Air, OS X 10.5.6, 1.6 Ghz Intel core 2 duo
- Safari Version 3.2.1 (5525.27.1)
- JVM 1.5.0_16 from Apple
Steps to reproduce the problem:
Launch Safari.
In (first) page/tab go to
http://www.javatester.org/version.html
(this uses a non signed applet)
Open a second tab. Here go to:
http://ukapi.phonefromhere.com/talk/vtop2.xsql?key=01612884242
This is a signed applet that will ring our office over VoIP.
Click the "Trust" button (signed by PhoneFromHere).
As long as this applet isn't cached by the JVM this will work, so
the first time you will succeed.
Now Quit Safari (not "just" close all Safari windows, but a "real" quit) and repeat the exercise.
The second (and next) time this will fail (only if the signed applet is loaded as second, so the order is important)! This keeps failing until I go (back) to the Java Preference window (via Finder) and explicitly delete the cached files.
The URL will work when loaded first (cached or not).
Some diagnostics, that might help:
I configured the Java Preference window to "enable Logging, Tracing and Show applet livecycle exceptions".
When the applet fails to load (and Safari freezes/hangs), the last few records of the plugin150.log are:
<message>basic: Loading http://ukapi.phonefromhere.com/talk/lib/pfh.jar from cache
<message>basic: Reading cached JAR file from JRE 1.5 release
<message>basic: Certificates for http://ukapi.phonefromhere.com/talk/lib/pfh.jar is read from JAR cache
<message>security: Loading certificates from Deployment session certificate store
<message>security: Loaded certificates from Deployment session certificate store
<message>security: Checking if certificate is in Deployment session certificate store
(and then nothing)
whereas when it succeeds to load, as soon as I click the "Trust" button, it's say:
<message>security: User has granted the priviledges to the code for this session only
The Report is a bit too long to port, I'll include the same text above when sending it.
Model: PowerMac7,2, BootROM 5.1.3f0, 2 processors, PowerPC 970 (2.2), 1.8 GHz, 2 GB
To cut a long story short? Is this a know bug (I couldn't find anything, but you never know)? Does anyone have any ideas how to fix this?
Thanks, Birgit

I have the same issue now after downgrading my Flash plugin. I downgraded from 10 to 9 latest because I like using Camino and for some reason Flash 10 doesn't play nice with Camino. But all of a sudden as I use Camino 2b2 for everyday and Safari 3.2 for banking and such, the browser hangs requiring a forced quit when I close it. I've re-installed the browser twice now with all the previous folders, and preferences erased and caches emptied. I even when to re-installing 10.5.6 and it still crashes, it's odd. Maybe 10.5.7 will address this.

Signed applet don't work on XP

Hi,
I'am currently working on a point-of-sale (POS) using windows XP/Firefox and a linux apache/jboss server.
I have developed a dynamic windows library in order to use an industrial printer connected to the POS to perform some printing without confirmation of the customer.
The POS is under Windows XP SP2 and use Firefox 2.0.0.11/JRE 1.5.0.14.
This dll is used by a signed applet located on the apache/jboss server.
The applet is correctly downloaded by the client, but normally i have to wait for the certicat authentification windows appearing and for confirming that i want execute the applet. And instead i have a java exception :
security: La v�rification du certificat � l'aide des certificats AC racine a �chou�
security: Aucune information d'horodatage disponible
java.lang.NullPointerException
     at com.sun.deploy.ui.UIFactory.showSecurityDialog(Unknown Source)
     at com.sun.deploy.security.TrustDeciderDialog.showDialog(Unknown Source)
     at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
     at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
     at sun.plugin.security.PluginClassLoader.getPermissions(Unknown Source)
     at java.security.SecureClassLoader.getProtectionDomain(Unknown Source)
     at java.security.SecureClassLoader.defineClass(Unknown Source)
     at java.net.URLClassLoader.defineClass(Unknown Source)
     at java.net.URLClassLoader.access$100(Unknown Source)
     at java.net.URLClassLoader$1.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.net.URLClassLoader.findClass(Unknown Source)
     at sun.applet.AppletClassLoader.findClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at sun.applet.AppletClassLoader.loadClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at sun.applet.AppletClassLoader.loadCode(Unknown Source)
     at sun.applet.AppletPanel.createApplet(Unknown Source)
     at sun.plugin.AppletViewer.createApplet(Unknown Source)
     at sun.applet.AppletPanel.runLoader(Unknown Source)
     at sun.applet.AppletPanel.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)
security: L'utilisateur a refus� les droits d'acc�s au code
basic: Taille de cache du chargeur de classes courant : 1
basic: Termin�...
basic: Jonction du thread d'applet...
basic: Destruction de l'applet...
basic: Elimination de l'applet...
basic: Sortie de l'applet...
java.lang.ExceptionInInitializerError
     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
     at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
     at java.lang.reflect.Constructor.newInstance(Unknown Source)
     at java.lang.Class.newInstance0(Unknown Source)
     at java.lang.Class.newInstance(Unknown Source)
     at sun.applet.AppletPanel.createApplet(Unknown Source)
     at sun.plugin.AppletViewer.createApplet(Unknown Source)
     at sun.applet.AppletPanel.runLoader(Unknown Source)
     at sun.applet.AppletPanel.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)
Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.C:\Program Files\BICImpression\impression_api.dll)
     at java.security.AccessControlContext.checkPermission(Unknown Source)
     at java.security.AccessController.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkLink(Unknown Source)
     at java.lang.Runtime.load0(Unknown Source)
     at java.lang.System.load(Unknown Source)
     at applets.impression.Impression.<clinit>(Impression.java:38)
     ... 11 moreand then the certicat authentification windows appears but it's too late, the applet won't never execute ...
the apache/jboss server is accessed via some gateway, firewal, ... tha t i can't control
the apache jboss/server on my own PC is accessed directly :
What is amazing, is that work fine with my own professionnal PC on W2000 SP4, with JRE1.5.0.14 and Firefox 2.0.0.11 :
when I look in the java console, the java freeze until i have answered this java security window (certicat authentification windows). And when i answered "run" no problem the applet makes her own job.
here is the code when it works :
security: La v�rification du certificat � l'aide des certificats AC racine a �chou�
security: Aucune information d'horodatage disponible
basic: Plugin modality.pushed
basic: Modalit� empil�e
basic: push javax.swing.JDialog[dialog0,379,296,519x323,layout=java.awt.BorderLayout,modal,title=Avertissement - S�curit�,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,3,22,513x298,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
basic: Chargement arr�t�...
basic: Arr�t de l'applet...Conclusion
POS : Win XP SP2, JRE1.5.0.14 (i tried 1.5.0.6 and 1.6.3 the latest), Firefox 2.0.0.11 (I tried 2.0.0.0 and 3 beta2 don't work anyway)
my own server/client : W2000 SP4, JRE1.5.0.14, Firefox 2.0.0.11
Linux server : RHEL4
It works with IE on the POS with the linux sever but it's not the selected browser.
It works with IE on the POS with my own server.
It works with Firefox on the POS with my own server.
It works with IE on my own server with the linux sever but it's not the selected browser.
It works with IE on my own server with my own server.
It works with Firefox on my own server with the linux sever.
It works with Firefox on my own server with my own server.
If you have some idea to make it work i'm you're buyer !!
Thank a lot for reading this, and i apologize for my poor english ...
greetings,
Benoit
Edited by: bendur on Feb 29, 2008 3:49 AM

Ok I have found my problem :
On every web pages, we have defined some inactivity timeouts.
On my own server I have disabled these timeouts but not on the distant timeout.
And it seems that the timeout (defined in javascript ont he web pages : 3s) has a very bad influence on the launching of my applet ... only with firefox (with IE and Opera no problem)
My problem is anwsered but the problem keep alive for firefox ...

Prevent abuse of a signed applet?

Hi
I am creating an application using HTML, javascript, and a set of java classes.
Communication betwwen the javascript and java is done by an applet, signed with a real certificate.
I would like to prevent someone copying my signed jar, and abusing it.
The classes behind my applet will do (a.o.) local I/O.
The type of abuse I am worried about is e.g. java code from another jar calling public methods on classes in my signed jar, using them to read or write files, and thus abusing my certificate for doing something else than my applet/jar was meant to.
I am looking for advice on how to prevent such things from happening.
Thoughts that already crossed my mind, are:
- making sure only my applet (and as few as possible other classes) has a public constructor
- declaring as much classes as possible (at least the sensitive classes) as final
- avoid non-final public static variables that contain default names of files
If anyone has some more ideas, please post them! I'll be very gratefull!
If you know about a similar question (and answer) in this forum, please let me know, as I have not found it.

harmmeijer,
thanks for the answer, and especially the idea of checking the call stack!
You scared the hell out of me however, by saying:
Your applet would not work at all in jre 1.4.2 signed or policy, when the method is called by javascriptand reading the thread you referenced!
Everything worked fine in jre 1.4.1_2 and earlier. It continued working in 1.4.2_01 in combination with Netscape (v 7.1)
But the combination MSIE (v6.0) with jre v1.4.2_01 did require a minor change:
From my signed applet, I called a .class.getResource(...).getURL()
It didn't work anymore, so I do it know in my applet's init() method, instead of in a stack started by javascript.
All my other I/O (and reflection) still works (thank all gods!), since I do it in a separate thread that I start in my applet's init() method. I hope it keeps working in jre 1.5 :-)
Any other input is very welcome!

Signed applet throws security exceptions

Since nobody seems to be reading the Signe Applet forum, I decided to try here:
Hi all
I have problems with signed applet (self-made cert), and after reading this forum I see this is more or less common.
The problem that I am having is, that I can not use doPrivilege() and similar tricks, because applet needs to be Java 1.1 compatible.
So, signing will have to work.
Applet is signed using 1.5.0_06 jarsigner. Jarsigner verifies it OK.
It works on JVM 1.5.0_06 but not on 1.4.2_08.
Please help me make if work under any JVM.
The error I get is:
Java(TM) Plug-in: Version 1.4.2_08
Using JRE version 1.4.2_08 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\miha
Proxy Configuration: Automatic Proxy Configuration
     URL: http://orion.nil.si/proxy.pac
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
l:   dump classloader list
m:   print memory usage
o:   trigger logging
p:   reload proxy configuration
q:   hide console
r:   reload policy configuration
s:   dump system properties
t:   dump thread list
v:   dump thread stack
x:   clear classloader cache
0-5: set trace level to <n>
java.security.AccessControlException: access denied (java.net.SocketPermission host.domain.dom resolve)
TelnetWrapper PROXY: java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:0 connect,resolve)
java.lang.NullPointerException
     at net.propero.rdp.ISO.connect(ISO.java:123)
     at net.propero.rdp.MCS.connect(MCS.java:84)
     at net.propero.rdp.Secure.connect(Secure.java:153)
     at net.propero.rdp.Secure.connect(Secure.java:171)
     at net.propero.rdp.Rdp.connect(Rdp.java:498)
     at net.propero.rdp.Rdesktop.main_nonstatic(Rdesktop.java:615)
     at net.propero.rdp.applet.RdpThread.run(RdpApplet.java:222)
FATAL: java.lang.NullPointerException: nullWhat is funny, is that I have two applets, and one works and the other one doesn't. It is like this:
Applet A (signed) needs to connect to host1, fails and tries to connect through proxy using my proxy library (also signed - different JAR). Everything works.
Applet B (signed) needs to connect to host1, fails and tries to connect through proxy using the same proxy library. It gets a security exception.
All JARs are signed using the same key/certificate.
Both applets try to connect to the same "host1".
Both applets try to use the same proxy - which is different from "host1".
The one thing that might make a difference, is that in the working applet, everything is within one thread, and in the broken applet, the proxy object is in the main applet thread, and this applet may open many windows, that all utilize the same proxy object - only they can't.
When I tried to move the proxy object down to the child threads, I get the following exception:
Exception in thread "Thread-1952" java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.sun.misc)
     at java.security.AccessControlContext.checkPermission(Unknown Source)
     at java.security.AccessController.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkPackageAccess(Unknown Source)
     at sun.applet.AppletSecurity.checkPackageAccess(Unknown Source)
     at sun.applet.AppletClassLoader.loadClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at java.lang.ClassLoader.loadClassInternal(Unknown Source)
     at net.propero.rdp.Rdesktop.main_nonstatic(Rdesktop.java:567)
     at net.propero.rdp.applet.RdpThread.run(RdpApplet.java:211)It seems that I can only create the proxy object in the Applet.init() method, to avoid this exception.
So to, summarize: I would prefer just one object for all threads that I will create, but then my applet behaves like it is not signed (at least under JVM 1.4.2_08). Java 1.5.0_06 doesn't have any problems with this.
Regards, Miha Vitorovic

The one thing that might make a difference, is that in the working applet, everything is within one thread, and in the broken applet, the proxy object is in the main applet thread, and this applet may open many windows, that all utilize the same proxy object - only they can't.
When I tried to move the proxy object down to the child threads, I get the following exception:
Exception in thread "Thread-1952" java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.sun.misc)
     at java.security.AccessControlContext.checkPermission(Unknown Source)
     at java.security.AccessController.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkPackageAccess(Unknown Source)
     at sun.applet.AppletSecurity.checkPackageAccess(Unknown Source)
     at sun.applet.AppletClassLoader.loadClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at java.lang.ClassLoader.loadClassInternal(Unknown Source)
     at net.propero.rdp.Rdesktop.main_nonstatic(Rdesktop.java:567)
     at net.propero.rdp.applet.RdpThread.run(RdpApplet.java:211)It seems that I can only create the proxy object in the Applet.init() method, to avoid this exception.
So to, summarize: I would prefer just one object for all threads that I will create, but then my applet behaves like it is not signed (at least under JVM 1.4.2_08). Java 1.5.0_06 doesn't have any problems with this.
Regards, Miha Vitorovic

Signed applet stopped working in 1.4.2_04

We have a signed applet that accesses the file system. After installing 1.4.2_04 it produces this exception
java.security.AccessControlException: access denied (java.io.FilePermission <<ALL FILES>> execute)
     at java.security.AccessControlContext.checkPermission(Unknown Source)
     at java.security.AccessController.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkExec(Unknown Source)
     at java.lang.Runtime.exec(Unknown Source)
     at java.lang.Runtime.exec(Unknown Source)
     at java.lang.Runtime.exec(Unknown Source)
     at java.lang.Runtime.exec(Unknown Source)
     at edu.nebraska.foundation.applets.AccessApplet.openNewSession(AccessApplet.java:35)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at sun.plugin.com.MethodDispatcher.invoke(Unknown Source)
     at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
     at sun.plugin.com.DispatchImpl$2.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
java.lang.Exception: java.security.AccessControlException: access denied (java.io.FilePermission <<ALL FILES>> execute)
     at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
     at sun.plugin.com.DispatchImpl$2.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
.This was working in 1.4.2 and 1.3.1_08. Anyone else have this problem?

Sorry, copied and pasted the following, hope it helpes.
The following examples are for a win 2000 machine, for linux
you have to use alternative paths but I think the commands
are about the same.
The SUN jre doesn't care about IE settings, if an applet is signed it will ask the user "do you trust", if
the user chooses yes or always the applet can do pretty much anything.
Because anybody can sign an applet so it will pop up the do
you trust dialog I prevent this dialog from popping up by
adding the following to the
C:\Program Files\Java\j2re****\lib\security\java.policy
under grant { [/b]
[color red]
permission java.lang.RuntimePermission "usePolicy";
[color]
You now need to set up special permissions for sites that
need it, signed applets get no special treatment since you
specified in the java.policy that policy should allways be
used.
When your applet needs to do something it normally could
not do (applet security) [b]and it needs to do this
when a user clicks on a html button (applet method called
from javascript), than all the signing and policy settings
in the world wouldn't work Unless you grant all permission
to all code.
This is because the Java Plug-in executes methods with
applet sandbox security restrictions.
http://archives.java.sun.com/cgi-bin/wa?A2=ind0404&L=java-security&F=&S=&P=4012
To solve this you can start a new thread that checks ...
times a second if a variable meets certain conditions.
These conditions are changed with public methods called
from JavaScript. When a variable meets certain Conditions
this thread will start the method that will perform
normally restricted tasks.
Here is an example where the applet doesn't work
(the batchfile, html file are OK)
Note that running this code with Mozilla on my w2k machine
crashes Mozilla (not on my Fedora machine)
Batch file to sign the applet: (please note this will
delete some files)
del *.cer
del *.com
del *.jar
del *.class
javac -classpath ".;C:\Program Files\Java\j2re1.4.2_04\lib\plugin.jar" test.java
keytool -genkey -keystore harm.com -keyalg rsa -dname "CN=Harm Meijer, OU=Technology, O=org, L=Amsterdam, ST=, C=NL" -alias harm -validity 3600 -keypass pass -storepass pass
jar cf0 test.jar test.class
jarsigner -keystore harm.com -storepass pass -keypass pass -signedjar sTest.jar test.jar harm
del *.classThe html page:
<DIV id="dvObjectHolder"> </DIV>
<br><br>
<script>
if(window.navigator.appName.toLowerCase().indexOf("netscape")!=-1){ // set object for Netscape:
     document.getElementById('dvObjectHolder').innerHTML = "        <object ID='appletTest1' classid=\"java:test.class\"" +
                "height=\"0\" width=\"0\" onError=\"changeObject();\"" +
          ">" +
                "<param name=\"mayscript\" value=\"Y\">" +
                "<param name=\"archive\" value=\"sTest.jar\">" +
        "</object>";
}else if(window.navigator.appName.toLowerCase().indexOf('internet explorer')!=-1){ //set object for IE
     document.getElementById('dvObjectHolder').innerHTML =      "<object ID='appletTest1' classid=\"clsid:8AD9C840-044E-11D1-B3E9-00805F499D93\"" +
               "         height=\"0\" width=\"0\" >" +
               "   <param name=\"code\" value=\"test.class\" />" +
                  "<param name=\"archive\" value=\"sTest.jar\">" +
               " </object>"
</script>
<LABEL id="lblOutputText">This text will be replaced by the applet</LABEL>
<BR>
<input value="Javascript to java" type=button onClick="document.appletTest1.fromJavaScript()"><br>The applet:
// new class for jsObject!!!! since 1.4.2 compile this:
// javac -classpath "C:\Program Files\Java\j2re1.4.2_01\lib\plugin.jar" test.java
// since jaws.jar does not exsist anymore
// to compile with jaws: javac -classpath "C:\j2sdk1.4.0_03\jre\lib\jaws.jar" test.java
import netscape.javascript.*;
public class test extends java.applet.Applet {
    JSObject win;
    JSObject outputLabel;
    public void init() {
         try{
             win = JSObject.getWindow(this);
             outputLabel = (JSObject) win.eval("document.getElementById('lblOutputText')");
          outputLabel.setMember("innerHTML", "<center><h1>From Init<br>Your homedir " + System.getProperty("user.home") + "</h1></center>");
        }catch(Exception e){
             e.printStackTrace();
    public void fromJavaScript(){
         try{
                 outputLabel.setMember("innerHTML", "<center><h1>From javascript<br>Your homedir: "+ System.getProperty("user.home") + "</h1></center>");
        }catch(Exception e){
             e.printStackTrace();
}When you put the files in c:\temp, run the batch file to
compile and sign the applet and then open the html file you
will be asked if you trust ... you can say yes and from
init the applet can read user.home. Click on the button and
you will get the following stack trace:
java.security.AccessControlException: access denied (java.util.PropertyPermission user.home read)
     at java.security.AccessControlContext.checkPermission(Unknown Source)
     at java.security.AccessController.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
     at java.lang.System.getProperty(Unknown Source)
     at test.fromJavaScript(test.java:20)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at sun.plugin.com.MethodDispatcher.invoke(Unknown Source)
     at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
     at sun.plugin.com.DispatchImpl$2.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at sun.plugin.com.DispatchImpl.invoke(Unknown Source)Conclusion: the applet can read user.home but not from
JavaScript.
Here is the applet that does work because a method called
from javaScript doesn't perform a restricted task.
// new class for jsObject!!!! since 1.4.2 compile this:
// javac -classpath "C:\Program Files\Java\j2re1.4.2_01\lib\plugin.jar" test.java
// since jaws.jar does not exsist anymore
// to compile with jaws: javac -classpath "C:\j2sdk1.4.0_03\jre\lib\jaws.jar" test.java
import netscape.javascript.*;
public class test extends java.applet.Applet {
     JSObject win;
     JSObject outputLabel;
     boolean buttonFromJavaClicked = false;
     checkJavaScriptEvent evt = new checkJavaScriptEvent();
     public void init() {
          try {
               evt.start();
               win = JSObject.getWindow(this);
               outputLabel =
                    (JSObject) win.eval("document.getElementById('lblOutputText')");
               outputLabel.setMember(
                    "innerHTML",
                    "<center><h1>From Init<br>Your homedir "
                         + System.getProperty("user.home")
                         + "</h1></center>");
          } catch (Exception e) {
               e.printStackTrace();
     public void fromJavaScript() {
          buttonFromJavaClicked = true;
     private void fromJavaScript2() {
          System.out.println("fromjavascript2 is started");
          try {
               String strLbl =
                    "<center><h1>From javascript<br>Your homedir: "
                         + System.getProperty("user.home")
                         + "</h1></center>";
               outputLabel.setMember("innerHTML", strLbl);
          } catch (Exception e) {
               e.printStackTrace();
     class checkJavaScriptEvent extends Thread {
          public void run() {
               while (true) {
                    if (test.this.buttonFromJavaClicked) {
                         System.out.println("OK buttonfromjava is true");
                         test.this.buttonFromJavaClicked = false;
                         test.this.fromJavaScript2();
                    try {
                         Thread.sleep(300);
                    } catch (Exception e) {
                         System.out.println("exception in sleep");
                         e.printStackTrace();
                         System.exit(1);
}

Unable to read InputStream in Signed Applet when interacting with ISA proxy

Background info:
We have an applet that we use for incremental refresh of data items.
The applet model works for all but one of our customers
Client info:
VeriSIgn signed applet.
IE 6.0 browser
Java JRE version: 1.5.0_06-b05
OS: Windows XP Version 2002 service pack 2
Problem description:
I am consistently getting a premature EOF exception when trying to read from a BufferedInputStream.
The stack trace, if captured ends up in the ChunkedInputStream reader.
I have tried a variety of request header settings to no avail.
Connection: close
Connection: Keep-Alive
etc...
Any comments are welcome
Thanks for reading and considering
Kurt

We are using the HttpURLConnection. If I have to go down the stack to the Socket object, well I guess I have to re event the wheel so to speak.
I have tried both Connection: close and Connection: Keep-Alive. Not at the same time :) but in different intrim releases of test applet.
// Here is the current incarnation of how I am trying to connect.
URL url = new URL(sURL);
trace("attempting to connect to URL: " + sURL, DEBUG);
connection = (HttpURLConnection)url.openConnection();
connection.setDoOutput(true);
connection.setDoInput( true );
connection.setRequestMethod("POST");
connection.setUseCaches( false );
connection.setInstanceFollowRedirects( true );
connection.setAllowUserInteraction( false );
connection.setRequestProperty("Pragma", "no-cache");
connection.setRequestProperty("Expires", "-1");
connection.setRequestProperty("Connection", "Keep-Alive");
connection.connect();
// Now I write our form POST data and flush and close the output stream.
BufferedOutputStream bos = new BufferedOutputStream(connection.getOutputStream());
bos.write(sForm.getBytes());
bos.flush();
bos.close();
// Get the input and read
bis = new BufferedInputStream(connection.getInputStream());
trace( "reading input stream for action: " + sAction );
byte[] responseBuffer = new byte[4096];
int bytesRead = 0;
while( (bytesRead = bis.read( responseBuffer, 0, responseBuffer.length )) != -1 )
sbResponse.append( new String( responseBuffer, 0, bytesRead ));
totalBytesRead += bytesRead;
catch (Throwable e)
e.printStackTrace();
try
m_connections.remove( sAction );
connection.disconnect();
catch ( Throwable t ) {}
finally
if ( bis != null )
try
bis.close();
catch( Throwable t ) {}
With the above code in place what I am now seeing, as opposed to a premature EOF exception, is blocking behavior on the read.

Granting SocketPermission using signed applet

I have had a dream of locally caching a jar file for an applet so that all the code will be on the client machine after the first time the applet was loaded. Basically, I have a very thin applet composed of a jar class loader and a tiny applet which will check for a jar file on the client and download it from the server if it does not exist. These simple classes are in a signed jar file. Basically, this thin applet does the following:
1) Check for the big, app jar file in c:\Temp
2) If it does not exist, open a URL input stream and get the big jar
3) instantiate a jar class loader object on the now local, big jar file
4) load the "main" class
5) use reflection to run its initialization method
6) the application then attempts to open a socket to the server
I get all the way to step 6 and this is where things go bad. As far as I can tell, the "thin" app loader class has permission to do anything it wants since it was downloaded from a signed jar - I haven't tried to do anything I was not able to do with this class. I think the problem arises because the app class came from a non-signed jar file and it appears to have all the typical applet restrictions. I can make URL connections to the local client (since that's where the code was loaded from), but not anywhere else.
I was hoping all classes the "thin", privileged class loaded would inherit these privileges, but obviously the class permissions come from where the class was loaded from. This is a bummer and my guesses for solving this problem are:
1) grant permission to the entry class for the app somehow (I tried something like this by executing the entry method for the app in a AccessController.doPrivieleged block - no luck)
2) sign the app jar and somehow read and accept its certificate so that all classes loaded from this jar are privileged (I am not sure of how to do this)
I am hoping someone might have an elegant solution to this problem as this is really the last step in my caching solution. By the way, the entry app class is not an applet itself if this is useful information to anyone. The "thin" applet is the only applet and just hands control off to the entry method of the main app class in the jar.
TIA!

Signing an applet provides it with the ability to run outside the sandbox. This does not automatically give the applet permission to do anything it wants. The applet must still request the desired permission before actually attempting an operation that requires that permission. Depending on the browser or whether you are relying on the Java plugin, you need to call the necesary security method first. I wrote a signed applet back in May 2000 which also needed socket permission. I don't have access to the code anymore so I cannot recall exactly the classes and methods you need to invoke. If you search the Signed Applets forum for my name, there are several messages that should help you.
For example:
http://forums.java.sun.com/thread.jsp?forum=63&thread=132336

ClassCastException launching Applet under JRE 7u21

I'm working on a signed Applet that will no longer start under version 7u21 of the JRE, and I've been able to isolate the problem to the Java Plugin's cache. If I disable Temporary files in the Java Control Panel, then everything's file. If I enable Temporary files, I get this exception in the Java console on startup:
basic: exception: com.sun.deploy.net.DownloadEngine$2 cannot be cast to com.sun.deploy.cache.CacheEntry.
ExitException[ 3]java.lang.ClassCastException: com.sun.deploy.net.DownloadEngine$2 cannot be cast to com.sun.deploy.cache.CacheEntry
at sun.plugin2.applet.JNLP2Manager.loadJarFiles(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The applet is being deployed using Oracle's deployJava script.
This is happening on all our test systems in Chrome, FireFox, IE 8 and 9, which reinforces that this is a plugin problem. It's currently impacting a production system that's been running just fine for over a year before this JRE update.
Any insight anyone has would be greatly appreciated.

Seems like you did proper research there, I would report your findings as a bug if there isn't already one similar to yours.

Signed applets (are policy files needed!)

I have experienced on a number of different machines that a signed applet that the client trusts (via clicking on yes to the prompt asking to trust the applet), is able to access the local resources with NO policy file on the client machine. I'm using JRE 1.4.1_02
Is this the expected behavior?
I sure hope it is because how in the world can you install applications to many clients and update their policy file? you can't via the web! BUT why am I reading that you have to have a policy file even if you sign an applet. I want to get rid of using Netscape security model but I can not update many client machine policy files... Please help!!! thanks. Is signing an applet all you have to do to access local machines, I sure hope so! Thanks in advance.

I've done some more research specifically a very good article at http://developer.java.sun.com/developer/technicalArticles/Security/applets/index.html. I'll try to highlight the more interesting comments that I found. At least for the JRE 1.3 there appears to be a new class loader, sun.plugin.security.PluginClassLoader that allows a signed jar file (once trusted by the client) to have access to local resources.
Code signed using the private key of the signer can be run on client machines once the public key corresponding to the signer is deemed as trusted on the respective machine.
Applet security in browsers strives to prevent untrusted applets from performing potentially dangerous operations, while simultaneously allowing optimal access to trusted applets.
There is no simply way to deploy and use customized policy files, a policy will have to be set by files based on the JRE installation. Customized class loaders or security managers cannot be installed easily.
Policy files are difficult or at least not very straightforward for normal users, which could be thousands of machines where an applet is deployed.
The java plug-in (I believe its 1.3 and later) provides a workaround although its recommended to use policy files wherever practical and applicable. (This implies to me that using the plug-in, all that is required is to sign the jar file to have access to local resources).
RSA-signed applets can be deployed using the Java plug-in. (which can run in an identical way for Netscape and IE).
In order for a plug-in enhanced browser to trust an applet and grant it all privileges or a set of fine-grained permissions (as specified in a J2EE policy file), the user has to preconfigure his or her cache of trusted signer certificates (the .keystore file in JRE 1.3) to add the applet's signer to it. However, this solution does not scale well if the applet needs to be deployed on thousands of client machines, and may not always be feasible because users may not know in advance who signed the applet that they are trying to run. A NEW CLASS LOADER, sun.plugin.security.PluginClassLoader in the Java Plug-in 1.3, OVERCOMES THE LIMITATIONS MENTIONED ABOVE.
I hope this helps, I've been looking for this solution for quite some time, trying to understand why singed applets work with no policy files for version 1.4... Talk to you later, Jay.

Checking integrity of signed applets in JRE cache

Similar Messages

Maybe you are looking for