On 1/24/19 11:05 AM, Sean Mullan wrote:
On 1/24/19 8:25 AM, Robert Marcano wrote:
On 1/23/19 8:59 AM, Sean Mullan wrote:
On 1/22/19 8:50 PM, Bernd Eckenfels wrote:
I don’t think the launcher is doing this, it is the class loader,
that’s nothing new. You can turn on verbose security debug to see it
in all versions.
Yes, and it only verifies the signature(s) on the JAR. It doesn't
validate the certificate chain.
--Sean
I noticed that trying to identify the higher memory usage after what
looks like a big application is loaded. I am doing memory profiling
and notice JarFile taking more memory that on Java 8. Still need to
detect the real cause for an independent test case. We probably didn't
notice this slowdown before because Oracle's JNLP implementation was
slow enough at startup.
IMHO the class library should not do doing signature checks without
certificate validation, because it doesn't give any protection if the
signature is not verified, the only thing it could do now is to detect
some random bit flips, that maybe the Zip format CRC detect before
that. With no certificate verification the signature could be replaced
by anybody with bad intentions.
It's a fair point, although since URLClassLoader is a subclass of
SecureClassLoader the certificate chain does get populated into the
CodeSource of the classes loaded, so one could potentially write a
custom ClassLoader or additional code to additionally validate the
certificate chain. Also, keep in mind that validating a certificate
chain for signed code is not usually sufficient to determine if you
actually trust who signed the code; some additional policy configuration
(or UI prompts) are usually required. Also, if you run the application
with a SecurityManager you can grant the signed JARs additional
permissions based on who signed the code in an associated policy file,
see [1] for more info.
Thanks for the info, but this is for corporate intranet application
distribution of an ISV (us) application, no untrusted code installation.
We are signing our code with a certificate from a private CA and the CA
is embedded on the native updater/launcher as the exclusive CA used for
dowloaded updates validation. It is more like the Firefox/Chrome updater.
Maybe adding a constructor flag to URLClassloader to pass to JarFile
to skip verification and a system property to tell the Java startup
code to skip verification of java.class.path (just for compatibility
with old code that expect it to be done). There is precedent of other
runtimes that added options to disable this, like CLR [1] (Ii not only
verified signatures, It do CRL/OSCP checks too)
It's easy enough to strip signatures from JAR files (which you mention
below). So if this is really an issue, I would be more inclined to just
do that if it is an option.
Yea, I added an option to remove the signatures from the downloaded
updates (after signature validation) so they are not validated anymore
at launch time.
Our new launcher replacing JNLP now do signature verification in
native code, at download time, and install on a system area (not user
home directory), so signature verification at application launch is a
slowdown we want to avoid, but think on another kind of users, those
deploying to OS Stores (for example Windows Store), why add the
slowdown of verification when the application is verified by the store
client at install time?, this could help these situations too.
Note: This can be avoided removing the signatures of all JARs if you
distribute to an OS store, there are a few libraries that distribute
their JARs signed (The old Java Help framework comes to my mind right
now)
[1]
https://blogs.msdn.microsoft.com/shawnfa/2007/05/07/bypassing-the-authenticode-signature-check-on-startup/
--Sean
[1]
https://docs.oracle.com/en/java/javase/11/security/permissions-jdk1.html#GUID-7450CEFD-8EDC-495E-A7A3-6C2561FA4999
