According to its developer, Oracle's Java Card technology is found in approximately 6 billion smart card applications used by organizations across multiple industries, all over the world. The platform is most frequently found in SIM cards, as well as authentication tools, cryptography applets and other devices with a minimal memory footprint, as The Register noted. This allows for low-code (but critical) security functions to occur within the card-driven devices, which in theory should leave little room for unauthorized access and resultant exploitation.
However, security researchers have discovered a considerable number of vulnerabilities within the smart-card platform over the course of the past several months, and it does not appear – as of May 31, 2019 – as if any full-fledged updates or fixes are on the horizon. If your organization uses any devices that are powered by Java Card for security applications, or you've considered adopting such a technology, it will be critical to learn exactly what flaws and risks you could end up facing.
Discovery of the Java Card flaws
Security Explorations, a cybersecurity consultancy and evaluation firm based in Poland, first discovered this batch of weak spots in the Java Card Platform March 20. Shortly after reporting the presence of the problematic issues to Oracle (and smart-card manufacturer Gemalto) the company's founder and CEO, Adam Gowdiak, announced them publicly in a press release.
These vulnerabilities pertain to Java Card 3.1 software – which, according to ADTMag, Oracle had debuted just two months before Gowdiak went public with what he and his team members had found. The Security Explorations CEO said there are 18 bugs in total, which can be introduced to the platform if a cyberattacker hacks into a card reader and loads a malware applet that finds its way into cards scanned on the reader, potentially taking control of them. Three of the bugs are only found in smart cards directly manufactured by Gemalto.
It's worth noting that exploiting these bugs to the degree necessary for worst-case-scenario hacks would be quite difficult. Gowdiak said as much in his initial announcement of the matter, while also doing his best not to soft-pedal the full level of risk involved.
"There are ways for malformed applications loaded into a vulnerable Java Card to easily break memory safety," Gowdiak stated. "Such a breach directly leads to the security compromise of a Java Card VM, applet firewall breach and jeopardizes security of co-existing applications … It should be emphasized that successful loading of a malicious applet into target card requires either knowledge of the keys or existence of some other means facilitating it (a vulnerability in card OS, installed applications, exposed interfaces, etc.). Such scenarios cannot be excluded, though."
Security Explorations' efforts revealed that the biggest dangers stemming from these bugs would be to government departments, as well as organizations in telecommunications, finance and other sectors with similarly wide-ranging customer bases.
Oracle, Gemalto appear nonplussed regarding platform vulnerabilities
When news of the Java Card flaws first broke, neither Oracle nor Gemalto publicly commented on the matter. The former party issued the first statement March 29, telling Gowdiak and his team that the Oracle Reference Implementation architecture featuring the flaws wasn't intended for use in a production environment but rather as a tutorial exemplifying Java Card functions (presumably for new users to consult upon implementation). The company also said organizations using proper bytecode verification would most likely avoid the possibility of exposure to all of the bugs.
Gemalto commented the next day to say that its products weren't based in Java Card 3.1 and thus would not be vulnerable to the problems Gowdiak had cited. According to SecurityWeek, more bugs were discovered in the Gemalto cards throughout April, including one that could allow unauthorized actors to load unfamiliar or malicious Java applet code via over-the-air transmission. This issue in particular may alarm users of Gemalto's smart cards – which, after all, are still based in an iteration of Java architecture – as it doesn't require a hacker to compromise a reader. After this point, both Oracle and Gemalto stopped offering any further information to the public about any of these issues.
Because of Java's popularity and ease of use, there will always be debate even with the continued revelations of different flaws related to the coding language, and software and applications likely won't stop being created with it. But if unfazed by nothing else, business leaders should consider the two corporations' disinterested response to the announcement of the bugs – as well as the fact that Java Card evaluation is a service offered by numerous cybersecurity firms (including Gowdiak's) and existed well before this latest news. Taking all of this into account, it seems readily apparent that using Java or Java-adjacent IT resources is a risk simply not worth taking in any legacy application modernization plan.
Here at the Inventu Corporation, we equip organizations of all sizes with a revolutionary terminal emulation tool called the Flynet Viewer. This solution allows developers to craft reliable and safe software using clean HTML and JavaScript hosted on secure Windows servers. All in all, the Flynet Viewer supports streamlined IT modernization and meets employer and staff expectations in a way that feels both familiar and simple. Contact us today or review our extensive product catalog to see how Inventu can help you rid your servers of unsafe Java.
