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
tasks).

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 
memory
   safety),
- 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 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 
vulnerabilities.

Thank you.

-- 
Best Regards,
Adam Gowdiak

---------------------------------------------
Security Explorations
http://www.security-explorations.com
"We bring security research to a new level"
---------------------------------------------

References:
[1] JAVA CARD TECHNOLOGY
https://www.oracle.com/technetwork/java/embedded/javacard/overview/index.html
[2] Oracle Java Card Boosts Security for IoT Devices at the Edge
https://www.oracle.com/corporate/pressrelease/oracle-java-card-boosts-security-011619.html
[3] Gemalto
     https://www.gemalto.com/
[4] Reverse engineering Java SIM card
http://www.security-explorations.com/materials/javasim-reversing.pdf