[SE-2019-01] Java Card vulnerabilities

From: Security Explorations <contact@security-explorations.com>
To: bugtraq@securityfocus.com,fulldisclosure@seclists.org
Subject: [SE-2019-01] Java Card vulnerabilities

Hello All,

We discovered multiple security vulnerabilities in reference implementation
of Java Card technology [1] from Oracle used in financial, government,
transportation and telecommunication sectors among others.

According to Oracle, "Java Card technology provides a secured environment
for applications that run on smart cards and other trusted devices with
limited memory and processing capabilities. With close to six billion
Java Card-based devices deployed each year, Java Card is already a leading
software platform to run security services on smart cards and secure
elements, which are chips used to protect smartphones, banking cards and
government services" [2].

Unfortunately, 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 jeopardizes
security of co-existing applications. In some cases, whole card environment
can be compromised, but that's dependant on the underlying OS / processor
architecture (i.e. presence of the flat address space, isolation between

We were 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 [3] 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).

As for the impact, 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.

We verified this impact for the following Gemalto SIM cards:
- GemXplore 3G V3.0-256K
- 3G USIMERA Prime

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. The reasons
are the following:
- 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 [4], which can result in a discovery
  of far more serious issues,
- 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,
- 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 
- the nature of the issues undermine trust to Java Card as a secure 
  and software platform eligible to run security services on smart 
cards and
  secure elements.

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.

On Mar 20 2019, Security Explorations sent vulnerability notices to Oracle
and Gemalto containing detailed information about discovered 

Thank you.

Best Regards,
Adam Gowdiak

Security Explorations
"We bring security research to a new level"

[2] Oracle Java Card Boosts Security for IoT Devices at the Edge
[3] Gemalto
[4] Reverse engineering Java SIM card

Copyright © 1995-2019 LinuxRocket.net. All rights reserved.