Java applet manifest - Allow all Caller-Allowable-Codebase
Asked Answered
H

16

65

As of Java 7u45 an applet will display a warning message (even if signed with a trusted cert) if a webpage tries to interact with it via javascript and that page isn't listed in the manifest's Caller-Allowable-Codebase attribute.

Release notes about this change: http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html

Oracle blog post about this bug: https://blogs.oracle.com/java-platform-group/entry/7u45_caller_allowable_codebase_and

Attribute description: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/manifest.html#caller_allowable

I have tried just a wildcard (*), but I still get the warning.

Is there a way around this other than listing all codebases it may run at?

The reason this is a problem for me is that this applet runs on many different machines and networks, but always on intranets at various locations. This applet also needs to communicate with javascript because it talks to local USB scales and displays results and interacts with the page.

Example of warning message

Applet in question: https://github.com/JaggedJax/CIO_Scale

Handknit answered 16/10, 2013 at 1:32 Comment(2)
I am having the same issues, I think it's ridiculous that signed applets require this, I have not come up with a solution yet.Impound
I'm looking into Deployment Rule Sets but haven't gotten it to work yet. Plus it would involve going back and installing them at each location.Handknit
D
26

Removing the Trusted-Library attribute seems to be mandatory to get Caller-Allowable-Codebase working, no more warnings. However, this breaks Java 7 Update 21 - 40 which treated JavaScript code that calls code within a signed applet running with all permissions as mixed code and warning dialogs are raised if the signed JAR files are not tagged with the Trusted-Library=true attribute.

Disfrock answered 16/10, 2013 at 8:53 Comment(1)
As a disclaimer, I am the author of some of the posts on the Oracle product management blog including the one linked above. While the * Caller-Allowable-Codebase works and it's clear why ISVs need it, those who can specify it should. There's an article covering browser botnets from WhiteHat's presentation (at BlackHat). If you have the url, please provide it to the best of your ability.Kern
P
35

My findings are the same:

This prevents warnings with Java 7u21 - 7u40:

Manifest-Version: 1.0
Trusted-Library: true

This exclusivly prevents warnings with Java 7u45:

Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *

Mixing both won't work in 7u45.

Now what? Did anyone find a way to allow SIGNED applets with "all-permissions" to run without warnings in both JRE-versions?

What the hell is wrong with oracle?

Precession answered 16/10, 2013 at 9:56 Comment(10)
This has me wondering if embedding the applet using a .jnlp descriptor would allow you to supply one .jar for 7u45 and another .jar for 7u21–7u40: <java version="1.7.0_45+"><resources><jar href="MyApp-CodebaseInManifest.jar"/></resources></java> <java version="1.7.0_21+"><resources><jar href="MyApp-TrustedLibraryInManifest.jar"/></resources></java>Mineralogy
Confirmed that I had to delete Trusted-Library for update 45. And agreed - what the hell is wrong with Oracle!Annapolis
Unfortunately the approach suggested by VGR doesn't seem to work for me, it doesn't appear to be possible to specify that a resource section should only be used with a specify Java version.Whitmer
Worked perfectly for me!Schlenger
Agree with rasto - i didnt find either. Whats NOT working is this: <resources><j2se version="1.7.0_45+" href="http://java.sun.com/products/autodl/j2se"/><!-- NOT WORKING VERSION SELECTION --><jar href="a_45.jar" main="true"/></resources><resources><j2se version="1.6+" href="http://java.sun.com/products/autodl/j2se"/><!-- NOT WORKING VERSION SELECTION --><jar href="a_21.jar" main="true"/></resources>Precession
Did anyone find how to avoid this warning with SIGNED applets? none of the two methods work when the applet is signed and you try to access it through javascript.Kathie
The only solution is to detect the client plugin (per javascript) and load the corresponding manifested applet-jar. Use this: pinlady.net/PluginDetect but disable "notf" (not on the fly), because it tries to load an applet and... fails... at... liveconnect... ... ... ... ...Precession
This is all a waste of time now, with 1.7u51 liveconnect will not work except with the newest version as far as i can find.Precession
FYI: It appears that if you have both Application-Library-Allowable-Codebase and Caller-Allowable-Codebase attributes, they must appear in that order. If Caller-Allowable-Codebase occurs before Application-Library-Allowable-Codebase, with 7u60, it doesn't seem to get recognized.Ellen
i've found another way of dealing with this situation: Dont call the applet from JS, call JS from the applet. I've written a callstack that is beeing filled by JS and beeing polled by the applet periodically. This brings in some little delays, but clears the liveconnect issues.Precession
D
26

Removing the Trusted-Library attribute seems to be mandatory to get Caller-Allowable-Codebase working, no more warnings. However, this breaks Java 7 Update 21 - 40 which treated JavaScript code that calls code within a signed applet running with all permissions as mixed code and warning dialogs are raised if the signed JAR files are not tagged with the Trusted-Library=true attribute.

Disfrock answered 16/10, 2013 at 8:53 Comment(1)
As a disclaimer, I am the author of some of the posts on the Oracle product management blog including the one linked above. While the * Caller-Allowable-Codebase works and it's clear why ISVs need it, those who can specify it should. There's an article covering browser botnets from WhiteHat's presentation (at BlackHat). If you have the url, please provide it to the best of your ability.Kern
D
10

This will be fixed in a future release, according to the oracle blog post:

https://blogs.oracle.com/java-platform-group/entry/7u45_caller_allowable_codebase_and

They recognize the error "Both of these attributes should work together to support the various versions of client installations". But for now, their solution is: "The current work-around would be to favor using Caller-Allowable-Codebase over the old Trusted-Library call. "

Deci answered 21/10, 2013 at 9:11 Comment(7)
Welcome to Stack Overflow! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.Hanukkah
Unless I missed it I didn't see anything saying this will be fixed in that post. They just acknowledge that it should work but doesn't. Helpful, thanks Oracle!Oven
In the table explaining the possible attribute combinations (Trusted-library and Caller-Allowable-Codebase), they say: "This will be fixed in a future release so that both attributes can co-exist."Deci
@Deci Thanks. I just re-read it and spotted that second time through.Oven
Does anyone know yet if this was fixed in 7u51 released yesterday?Oven
With the new version 1.7.0_55, now, if you have set Caller-Allowable-Codebase to "*", you will see a security warning. Only the first time if you check not to see it again. Release notes: oracle.com/technetwork/java/javase/7u55-relnotes-2177812.htmlDeci
Not the same here: with 1.7.0_55 and 1.7.0_60 warning still remain even if you check not to see it again. #24238374Gantlet
S
6

I had the same issue. Solution for me was using same parameters in manifest as Oracle used on donwload page in applet for verify java version http://www.java.com/en/download/installed.jsp Their applet does not popup any warnings.

so solution is:


Manifest-Version: 1.0
Codebase: *
Permissions: all-permissions
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
Application-Name: APPNAME

it works on:
1.7.0_17-b02
1.7.0_25-b17
1.7.0_45-b18

Swound answered 16/10, 2013 at 13:27 Comment(2)
What it needs to work with is the updates 21 through 40, those after the trusted-library property was introduced. Before that, I fully expect these properties to work because they are ignored.Annapolis
I can not confirm this working - LiveConnect refuses JS-Calls with this Manifest on 1.7.0_25-b17. Everything looks fine (no warnings), but it still doesn't work :(Precession
U
5

from oracle:

Area: Deployment/Plugin Synopsis: Caller-Allowable-Codebase may be ignored when used with Trusted-Library.

If a trusted, signed jar is using the Caller-Allowable-Codebase manifest attribute along with Trusted-Library then the Caller-Allowable-Codebase manifest entry will be ignored and, as a result, a JavaScript -> Java call will show the native LiveConnect warning. The workaround is to remove the Trusted-Library manifest entry.

http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html

Unguiculate answered 16/10, 2013 at 13:23 Comment(0)
F
3

The only solution that I can think of that works with 7u45 and the Trusted-Library versions (7u21, 7u25 and 7u40) is to create two different JARs with different manifests and then detecting the user's version and loading the right one.

The main version served to versions before 7u21 and 7u45 and up will have the new Caller-Allowable-Codebase and no Trusted-Library entry. The second version produced will have Trusted-Library and will be served only to 7u21, 7u25 and 7u40.

Here is an ant macro to create the new jar with the modified manifest:

<macrodef name="addtrustedlibrarytojar">
    <attribute name="jarpath" />
    <attribute name="newjarpath" />
    <sequential>
        <echo>Unzipping @{jarpath} to add Trusted-Library</echo>
        <mkdir dir="build/temp_trusted_library" />
        <unjar src="@{jarpath}" dest="build/temp_trusted_library" />

        <echo>Inserting Trusted-Library in manifest</echo>
        <replaceregexp match="^" replace="Trusted-Library: true${line.separator}" flags="s">
            <fileset dir="build/temp_trusted_library/META-INF" includes="MANIFEST.MF"/>
        </replaceregexp>

        <echo>Creating @{newjarpath}</echo>
        <zip file="@{newjarpath}" basedir="build/temp_trusted_library" />

        <echo>Deleting build/temp_trusted_library directory</echo>
        <delete dir="build/temp_trusted_library" />
    </sequential>
</macrodef>

Call the macro like this for each JAR that needs the change made:

    <addtrustedlibrarytojar jarpath="dist/myapplet.jar" newjarpath="dist/myapplet_tl.jar" />

Remember to sign the new JAR. If it was signed already this change will invalidate the signature.

We use the PluginDetect library to detect the version of Java. Just extract PluginDetect_Java_Simple.js and getJavaInfo.jar. This code will get the java version:

<script type="text/javascript" src="js/PluginDetect_Java_Simple.js"></script>
<script type="text/javascript">
var javaVersionDetected = '0';
function javaDetectionDone(pd) {
    javaVersionDetected = pd.getVersion("Java");
    if (console) console.info('Detected java version: ' + javaVersionDetected);
}
PluginDetect.onDetectionDone("Java", javaDetectionDone, "js/getJavaInfo.jar", null);
</script>

We use javascript to launch our applets so we use this to decide between the standard and trusted-library applets:

        if (javaVersionDetected === '1,7,0,21' || javaVersionDetected === '1,7,0,25' || javaVersionDetected === '1,7,0,40') {
            if (console) console.debug('Using TL applet');
            attribs['archive'] = 'applets/myapplet_tl.jar';
        }
        else {
            if (console) console.debug('Using normal applet');
            attribs['archive'] = 'applets/myapplet.jar';
        }
Foeman answered 18/10, 2013 at 14:0 Comment(1)
I've also ended up with two applets and loading them according to detected Java version. Seems to be the only solution.Disfrock
E
2

I had the same issue, So I remove Trusted-Library=true from my MANIFEST.MF, work Caller-Allowable-Codebase attribute fine.

Ectomorph answered 16/10, 2013 at 7:10 Comment(2)
I found related infomation at follow url. bugs.openjdk.java.net/browse/JDK-8026347 This Bug mark duplication to JDK-8026228, but I can't view that bug infomation.Ectomorph
Except then you'll get warnings for updates 21 - 40. And your users may not have updated yet, plus corporate idiocy may prevent them from getting update 45 for quite some time.Annapolis
A
2

This set of attributes allows the applet to load without warnings in Java 7u45:

Application-Name: ...
Main-Class: com...
Sealed: true
Codebase: *
Caller-Allowable-Codebase: *
Permissions: all-permissions

We have tested on the following JVMs:

  • Java 6u20 (OK, well duh!)
  • Java 7u21 - must include Trusted-Library to avoid warning
  • Java 7u25 - must include Trusted-Library to avoid warning
  • Java 7u40 - must include Trusted-Library to avoid warning
  • Java 7u45

So the long and short is we have a dilemma; to have no warning on 7u21, 7u25 and 7u40 you must include Trusted-Library:true, and to have no warning on 7u45 you must omit this property.

Thanks Oracle for a Kobayashi Maru - we love you.

Annapolis answered 16/10, 2013 at 23:24 Comment(6)
Is your JS directly calling an applet method? For me the applet runs fine until the js on the page tries to access a method and then the warning appears. Removing Trusted-Library did remove the warning in 7u45 for me, but you're right that it might not be the root cause.Handknit
@William: Yeah it is; the JS client entirely drives the applet via an API.Annapolis
This doesn't make any sense. If JS calls into the applet then Trusted-Library is required with 7u21 or you will get the mixed code warning. Did you change your settings to not prompt you? Try deleting all your Java settings and test again.Foeman
@Sarel: Good catch; my tester had changed her security level to Medium - she is now retesting with High (on Very High, of course, you always get a warning).Annapolis
@Sarel: And she set it to medium because Java won't allow you to use an older JVM when it's set to High if it knows there are newer JVMs available. Frustrating.Annapolis
Haha, I don't know Star Trek that well. Thanks for the intro to this. Yes, it is a Kobayashi Maru, but it can be solved by thinking outside the box. Make two JARs and choose which to load. That's what we've done because we have a lot of users and they're on many different JVM versions. My answer has some code to accomplish this.Foeman
E
2

For update 1.7.0_25 (and probably 21-40), setting the security settings to Medium in the Java Control Panel -> Security tab removes prompting when using the manifest tags for update 1.7.0_45.

Eboni answered 17/10, 2013 at 11:58 Comment(0)
M
2

I'm finding now that some of my users still get this "mixed signed and unsigned code" warning (due to LiveConnect calls in the web page to the applet) even though I've set Caller-Allowable-Codebase correctly, and the difference between those that get it and those that don't get it is whether they have applet .jar file caching enabled in the client host. Those that allow Java to keep temporary files on the client (i.e., allow applet .jar files to be cached) get the warning, and those that turned caching off (because applet caching has never worked quite right) don't get the warning. Go figure.

Martinelli answered 20/11, 2013 at 19:33 Comment(1)
You should use cache-version attribute in <object>, where you apply your applet. And then you should manually or with help of autobuild, increase this value before each release build. Thus you'll not be bothered with client's option "keep temporary files".Philbrick
M
1

Without using Trusted-Library and setting:

Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *

Doesn't work for me, and i still see the warning.

Update: Tried also with http://... but didn't work either.

Update2: Seems even worse. I didnt update 7u40 (to 7u45) but Java console (full debug) shows the "LiveConnect 1.7.45" text. After that, my Javascript->Java calls are blocked.

Update 3: I noticed my warning shows Application and Publisher = UNKNOWN. Altought i have:

Application-Name: MyApplet
Implementation-Vendor: MyCompany

I tried using JDK7u45 instead of JDK7u5 i was using.

Mcauliffe answered 16/10, 2013 at 8:15 Comment(1)
About Update3: JRE will fail to display application and publisher details if java caching (temporary files) is disabled.Knuckle
I
1

To disable this "Security Warning" popup and other related popups using the Java 8 Update 45 JRE.

Trusted-Library: true
Caller-Allowable-Codebase: *.mycompany.com

Note: security warning popup was not disabled with wildcards * and *.com.

Ify answered 27/5, 2015 at 14:34 Comment(0)
H
0

We had this problem too - we were building with 1.4.2, on the theory that clients might not have an updated JRE plugin. Despite putting in the new manifest attributes, we still got the popup warnings in the 1.7_u45 JRE. We rebuilt with 1.6, and the warnings went away.

Hillegass answered 16/10, 2013 at 6:9 Comment(0)
A
0

EDIT: As it turns out, our app was doing something different if the file was in a different directory -- specifically, it wasn't attempting to access the applet signed jar manifests. So the fact that the file was in a different directory was irrelevant. So the below information is not accurate. I've decided to detail the real reason for the warning in a new question: As of Java 7 update 45, one can no longer lookup manifest information without triggering a warning?

Unfortunately, the workaround given by Oracle and others here for getting around the update 45 problem does NOT work if your app needs to access files in a different directory than where the app is being run from.

With my web start app, everything worked fine and dandy with the "Trusted-Library" attribute that needed to be added for 7u21. With 7u45, removing the "Trusted-Library" attribute and adding in all the additional attributes talked about in the other answers will NOT work -- I will get the same warning that you would get if you were running 7u21 without the Trusted-Library attribute (stating the application contains both signed and unsigned code).

It took me FOREVER to figure this out, because for very inexplicable reasons Oracle has decided not to print out ANY indication of what the "unsigned" code is in its console, even when running at maximum tracing (level 5). But basically, our app needs access to a configuration file which can be used by the user to configure application properties (for example, the logging level of our app). This configuration file is a plain old text file. And we store the config file in a directory co-located to where the app runs from: ..\config\app.properties. We access this file as a part of the main jar's init routine. It is here where the warning occurs.

The workaround here? Move app.properties into the same directory where the app is running from (and change the reference in the jar to just "app.properties"). Voila, it works -- no more warnings (as long as using the aforementioned codebase attributes). What the hell Oracle???

Unfortunately, because our app allows customized config files on a per-user basis, it is not as simple for us to just put the config file in the app's startup directory -- since that is NOT customized on a per-user basis, we would only be able to allow one user per machine to use the app simultaneously.

I've been looking over Java's manifest documentation to see if there is some way I can make the config file directory "safe" such that loading up of this file doesn't cause the warning. The only thing I can think of is either being able to use the Class-Path attribute or a combination of the Extension attributes (http://docs.oracle.com/javase/7/docs/technotes/guides/plugin/developer_guide/extensions.html), however these all seem designed around the purpose of jars, not just regular files...

Any ideas? And since Oracle intends to fix the Trusted-Library issue anyway, is coming up with a (potentially) grandiose workaround-solution around this even worth the effort? Grrr....

Anishaaniso answered 16/11, 2013 at 18:49 Comment(0)
P
0

I found some strange thing with MANIFEST.MF file in scope of last Java security issue with new attribute "Caller-Allowable-Codebase". I had some issues, why this new attribute wasn't helpful for me and started investigation
(Attention!: it may be related only to my local computer configuration - because I had never seen such troubles over stackoverlow).

Manifest file had been upgraded according to new security feature:

Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *

and *.jar was build, but without signing.

So, then I unpacked my *.jar file and looked in folder META-INF in MANIFEST.MF, where source manifest.mf should be generated.

And I was embarrassed by absence of last line, it looked this:

Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *

I tested this behavior several times and found out, that last line always was exchanged to the whitespace. So, if it will be helpfull for someone, just append in the end of MANIFEST.MF file some unmeaningful attribute, like Codebase: *, which will be cutted during *.jar build.

Philbrick answered 13/12, 2013 at 15:41 Comment(0)
C
0

if you make a Manifest patch file remember to live an empty line in the end, otherwise it won´t work. For example you can make a patch like:

Permissions: all-permissions
Codebase: *
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *

But you need to add an empty line (in the example 5 lines instead of four!)

And then add it to the manifest:

jar uvfm jarName.jar permissions.txt
Class answered 6/1, 2014 at 15:19 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.