Security researchers have discovered multiple security vulnerabilities in reference implementation of Java Card technology from Oracle used in financial, government, transportation and telecommunication sectors among others.
According to a posting on Full Disclosure, security researcher Adam Gowdiak said that due to certain architectural choices from the past, it's hard to perceive Java Card technology in terms of security.
"There are ways for malformed applications loaded into a vulnerable Java Card to easily break memory safety. Such a breach directly leads to the security compromise of a Java Card VM, applet firewall breach and jeopardises security of co-existing applications," he said.
"In some cases, whole card environment can be compromised, but that's dependant on the underlying OS / processor architecture (ie presence of the flat address space, isolation between tasks)."
He said that he was able to verify 18 of the issues in the environment of the most recent Java Card 3.1 software from Jan 2019 (Oracle Java Card VM reference implementation in the form of a simulator).
"One issue was specific to Gemalto cards. These cards could not be immediately exploited with the use of our "favorite" issue found in Oracle reference implementation, so there was a need to find and use another one (which we did)," said Gowdiak.
He said that the vulnerabilities found make it possible to break memory safety of the underlying Java Card VM. "As a result, full access to smartcard memory could be achieved, applet firewall could be broken or native code execution could be gained."
Gowdiak said that while none of the exploit codes can successfully pass off-card verification process, the vulnerabilities should be still perceived in terms of a significant weak point of given Java Card VM implementation.
Gowdiak gave several reasons for this. First, the vulnerabilities could be used to compromise security of trusted chips used by financial, government and telecommunication sectors, this paves the way for their in-depth analysis, "which can result in a discovery of far more serious issues".
Second, Java Card thrives to provide secure environment for multiple applications (applets), "as such no malicious application should be able to compromise security of the other one".
He added that split verification process is a known architectural/ design weakness of Java Card, "the environment should at least provide memory safety if type safety cannot be guaranteed (type safety is a direct consequence of memory safety)".
Lastly, Gowdiak said that the nature of the issues undermine trust to Java Card as a secure environment and software platform eligible to run security services on smart cards and secure elements.
"It should be emphasised 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," he said.
Gowdiak said that he has sent vulnerability notices to Oracle and Gemalto containing detailed information about discovered vulnerabilities. Both companies are now looking into the issues raised.
Sivan Nir, threat intelligence team leader of Skybox Labs, Skybox Security, told SC Media UK that as expected from any responsible disclosure, more detailed information about the vulnerabilities was only relayed to affected vendors with very little information in the public domain. "It’s safe to assume Oracle will be patching soon," she said.
"If exploited, the vulnerabilities could break the memory safety of the Java Card VM. This could lead to sensitive information being disclosed, applet firewall breaking, or even native code being executed," she added.