How Advisors Can Protect Themselves from a Java Sucker Punch

Posted by Dave Curry on March 12, 2013

Like defense in boxing, software security is generally a matter of keeping your guard up. In the ring, your opponent will throw punches at you. On the Internet, attackers will be trying to hack you. It comes with the sport. All software has defects and a certain percentage of them will be security vulnerabilities. Software vendors work with security specialists to identify vulnerabilities and correct applications before attackers can widely exploit these flaws. Standard security practice emphasizes applying software updates (also called “patches”) as soon as they are available. That’s basic defense. Gloves up. Elbows in. Chin down. You’ll be okay, kid.

However, a “zero-day exploit” is technology’s equivalent of boxing’s “sucker punch” — an unfair, unexpected blow that allows its victim no opportunity for defense. A hacker discovers a previously-unknown vulnerability in some popular software and, rather than brag about it on an online forum, crafts an exploit calculated to spread some malicious payload as widely as possible before the hole can be patched. If you’re in the way of it, there’s no chance to duck or block. The bell rings the end of the round, the ref looks away and a punch you never saw coming lays you out flat.

Because of the potential for grave injury, the sport of boxing bans sucker punches thrown outside the rules. Unfortunately, the Internet has become a back-alley bare-fist match fought for ever-higher stakes. That’s why zero-day exploits against widely-used Internet-connected software have come to be highly valued by individual scammers, groups of hactivists, criminal syndicates and the espionage arms of national governments alike. Software tools known as “exploit kits” place even complex attacks in the repertoire of relatively unskilled hackers. Consequently, the threat has multiplied to the extent that publicity about zero-day exploits has extended beyond technical circles to business and mainstream news. Popular applications such as Internet Explorer, Acrobat Reader and Adobe Flash have all had their share of zero-day vulnerabilities and the infamy that attends their discovery.

Recent Attacks on Java

Recently, it’s been Java’s turn in the stocks. Java, which powers applications that can run on multiple operating systems, has been the target of a series of high-profile zero-day vulnerabilities — to the extent that organizations from Apple to the Department of Homeland Security have recommended that users disable Java on their PCs unless they absolutely need it. Especially since the latter warning was issued in January of this year, Oracle has taken the situation seriously and has aggressively released a series of updates to Java, the most recent of which was published only a few hours before I sat down to write this post. Yet, the very frequency of the updates and the urgent tone of the warnings to install them immediately are unsettling in themselves.

Implications for Trust Company of America Applications

Trust Company of America uses Java extensively in its applications, which is why we monitor reports of vulnerabilities in Java very closely. The encouraging news is that Trust Company of America’s applications, Liberty and TCAdvisorII, use Java in ways that are not vulnerable to the kinds of zero-day exploits that led to the DHS warning. The most recent Security Alert from Oracle (CVE-2013-1493) is typical:

“This Security Alert addresses security issues … affecting Java running in web browsers. These vulnerabilities are not applicable to Java running on servers, standalone Java desktop applications or embedded Java applications.”

The phrase “Java running on servers” describes the way in which Liberty uses Java, while TCAdvisorII is an example of a “standalone Java desktop application”. These kinds of applications are not vulnerable to the zero-day exploits discovered thus far. No Trust Company of America application uses Java Applets, which is what is meant by “Java running in web browsers” — the use of Java that has proved vulnerable.

Even though Trust Company of America’s applications are not directly affected by the recent high-profile zero-day exploits, there’s still an indirect concern that relates to the TCAdvisorII launch page. In order to install and launch the TCAdvisorII client software, the launch page uses the Java Plug-in, a browser extension that is installed with Java. Although the TCAdvisorII launch page itself cannot be used by exploit code, the fact that the Java Plug-in is available in the browser allows other web-sites to run Java Applets. If the user visits a web-site that contains a malicious Applet that uses a zero-day exploit… well, there’s the sucker punch.

Protecting Yourself from a Java Sucker Punch

For this reason, Trust Company of America recommends that users install the latest update of Java 7 and disable the Java browser Plug-in except when visiting the TCAdvisorII launch page to launch the TCAdvisorII client for the first time. After that, Java will cache the TCAdvisorII standalone Java desktop application and allow it to be launched from a shortcut on the desktop or the Start menu. The user should then disable the Java Plug-in in the browser, which will prevent its misuse by zero-day exploits launched by malicious web-sites. When Trust updates TCAdvisorII, Java will detect this the next time it starts the application from the shortcut and will automatically download and install the update.

This advice to install Java 7, keep it updated, and disable the Java Plug-in except when it is needed is essentially the same as the Department of Homeland Security’s recommendation. As a reminder, the February 2013 release of the TCAdvisorII launch page issues a warning when it detects that the latest update of Java 7 is not installed. The May 2013 release will drop support for Java 6 in TCAdvisorII altogether.

Admittedly, this is cumbersome. That’s one of the reasons why Trust Company of America has committed to redesign TCAdvisorII in the Liberty architecture, which does not require Java on the desktop. We don’t doubt that Oracle, with all its resources and investment in Java, will eventually put things to rights. But we’d just as soon enable our customers to avoid the whole issue. After all, out where they never heard of the Queensbury rules, a wise fighter learns to keep his mug out of range even during the handshake.

User login