As was promised in previous post, I describe how make webtop customers happy.
What is the problem?
It seems that when Oracle acquired Sun it also acquired a bunch of security issues in JRE, for example, it’s pretty obvious that even if applet is signed by valid certificate it’s not enough to consider it as trusted – benign applet could be potentially used for malicious purposes (for example UCF applet is capable to launch any program on user’s machine, so attacker may exploit this capability). Security measures for this issue are obvious: just bind applet to specific website, and Oracle did it: JAR File Manifest Attributes for Security. Unfortunately these “innovations” are barely suitable for self-hosted applications – URLs vary from customer to customer, which makes it impossible to create applet suitable for every customer, though, I suppose EMC’s customers pay enough support fees to have an ability to request “custom” UCF applet from EMC, “custom” means that only manifest changes are required and such procedure could be easily automated – why do not create special service on customer portal? Instead of doing correct things EMC suggests something weird:
Actually, I double-checked Oracle’s documentation and was unable to find a place where they suggest to delegate security-related questions to business users, I suppose that EMC guys think that some posts in forums/blogs/etc have a status of official documentation, that, in fact, is not surprising: for example, IIG’s director of security prefers to get inspiration from this blog instead of performing code review:
Anyway, Oracle’s suggestions related to security prompts are:
- Use deployment rule sets
- get an applet with valid manifest and signature
Though rule sets option is straightforward I do not think that it is helpful due to following reasons:
- it costs money: “The JAR file must be signed with a valid certificate from a trusted certificate authority”
- it is dangerous: “The Deployment Rule Set feature is optional and shall only be used internally in an organization with a controlled environment. If a JAR file that contains a rule set is distributed or made available publicly, then the certificate used to sign the rule set will be blacklisted and blocked in Java”, i.e. you risk to loose money spent for your certificate
- if you already have a “valid certificate from a trusted certificate authority” why do not sign all applets in enterprise? So, this option is more suitable for cases when applets are embedded in hardware devices like KVMs, iLOs, etc and you unable to replace those applets
- I think the best case for rule sets is enable certain known applets and block all other
Second option costs money too because it requires a “valid certificate from a trusted certificate authority”, but it’s the only disadvantage of this option. So, what did I do to disable all security prompts in previous video? Obviously, at first, we bought code-signing certificate.
Let’s take a look at security prompts raising when UCF applet gets loaded:
- Java’s standard prompt asking whether user is going to trust applet’s certificate:
- UCF’s prompt aimed to prevent malicious usage of applet (whitelisting):
- Java’s prompt about not following security best practices:
For the third option EMC, as we already know, suggests to tick “Do not show this again for this app and web site” checkbox before accepting security warning. Besides the fact that delegating security-related questions to end-users is not a good idea, this options does not work properly. The problem is WDK generates special URLs for applets to prevent them from caching by JRE:
here “19gmgko28” and “98th” parts of URL are just encoded values of last modified time and size of applet file:
-bash-4.1$ stat -c "Last Modified: %Y, size: %s" \ > app/webapps/wp/wdk/system/ucfinit.jar Last Modified: 1426684797, size: 304049 -bash-4.1$ groovysh Groovy Shell (2.4.1, JVM: 1.6.0_45) Type ':help' or ':h' for help. groovy:000> import com.documentum.web.util.StringUtil ===> com.documentum.web.util.StringUtil groovy:000> StringUtil.toUnsignedString(1426684797000,5) ===> 19gmgko28 groovy:000> StringUtil.toUnsignedString(304049,5) ===> 98th
Such behaviour of WDK has following disadvantages:
- redeploying/updating webtop changes last modified time or/and size of applet file
- in clustered environment it’s expected that applet file has different last modified time on different nodes
also we already know that the cornerstone of UCF troubleshooting is to delete everything related to Java and Documentum, reinstall JRE, press ctrl+alt+reset, etc – these activities obviously wipe user’s settings, it’s clear that ticking “Do not show this again for this app and web site” checkbox is just a temporary workaround, so, we decided to sign applet by our certificate. The procedure is straightforward:
- edit META-INF/MANIFEST.MF, you should get something like (note Caller-Allowable-Codebase, Application-Library-Allowable-Codebase and Codebase headers):
Manifest-Version: 1.0 Built-By: dmadmin Application-Name: Documentum Created-By: 1.5.0_11-b03 (Sun Microsystems Inc.) Copyright: Documentum Inc. 2001, 2004 Caller-Allowable-Codebase: docum-at-app Build-Date: January 17 2015 09:07 PM Ant-Version: Apache Ant 1.8.4 Title: Documentum Client File Selector Applet Application-Library-Allowable-Codebase: docum-at-app Bundle-Version: 6.7.2220.0231 Build-Version: 6.7.2220.0231 Permissions: all-permissions Codebase: docum-at-app
- remove old signature files, i.e. META-INF/DOCUMENT.RSA and META-INF/DOCUMENT.SF
- run jarsigner to sign applet – do not forget to specify TSA URL
after that applet is ready for deployment in production. What about another two security prompts? I suppose it is obvious that whitelisting capability is now useless because now JRE performs the same checks, below is an example of security notice when applet gets loaded from non-trusted URL:
because of these considerations, I decided to disable whitelisting capability, unfortunately the only option to disable it in UCF is decompile com.documentum.ucf.client.install.installer.security.impl.Whitelist class: methods isHostAllowed(String) and isHostAllowed(String, IHostVerifier) must always return true (I bet it doesn’t worth to mention that after replacing class in applet you must sign applet again).
And finally, to remove the first security prompt I read Deployment Configuration File and Properties article and decided that manipulating by User Level configuration files is not a good idea, but System Level configuration files could be easily distributed among users’ machines in enterprise using various deployment tools, so, I did following (note naming convention of certificate alias):
C:\Windows\system32>md C:\Windows\Sun\Java\Deployment C:\Windows\system32>cd C:\Windows\Sun\Java\Deployment C:\Windows\Sun\Java\Deployment>type CON > deployment.config deployment.system.config=file\:C\:/Windows/Sun/Java/Deployment/deployment.properties C:\Windows\Sun\Java\Deployment>type CON > deployment.properties deployment.system.security.trusted.certs=C\:\\Windows\\Sun\\Java\\Deployment\\trusted.certs C:\Windows\Sun\Java\Deployment>keytool.exe -importcert -keystore trusted.certs -file G:\Users\andrey\work\cert.crt -alias deploymentusercert$tsflag$loc=http//docum-at-app:8280##docbase:http//docum-at-app:8280##from:http//docum-at-app:8280 Enter keystore password: Re-enter new password: ... Trust this certificate? [no]: yes Certificate was added to keystore