[翻译]【移动Java的安全性分析】

 

移动Java的安全性分析

Mourad Debbabi, Mohamed Saleh, Chamseddine Talhi and Sami Zhioua
Concordia Institute for Information Systems Engineering
Concordia University
{debbabi, m saleh, talhi, zhioua}@ciise.concordia.ca}

Proceedings of the 16th International Workshop on Database and Expert Systems Applications (DEXA’05)
1529-4188/05 $20.00 © 2005 IEEE

 

摘要

Java2微型版之可连接、资源受限设备配置（J2ME CLDC）是在资源受限设备（手机、机顶盒等）上运行移动应用程序所选择的平台。这个平台的大部署使得它成为安全性攻击的目标。

本文有两个目的：首先，我们研究J2ME CLDC的安全架构，然后我们提供这样一个Java平台的弱点分析。要分析的元件有：虚拟机，CLDC API 和 MIDP(Mobile Information Device Profile) API。分析包括规范、参考实现(RI) 以及在此平台上另外一些普遍部署的实现。

1 介绍

随着移动、无线和可上网设备（例如PDA、手机、寻呼机等）的增加，Java由于其安全性、可移植性、灵活性和网络支持功能，正做为一个标准的运行环境而显现出来。这里所选择的平台就是J2ME CLDC [10]。根据IDC（一个享有声望的市场研究公司）的预测，到2006年将会有超过12亿的基于Java配置的移动通讯设备。典型的J2ME CLDC平台配置由一些可分类的组件构成: 虚拟机，API和工具。虚拟机为KVM[15]。API 为 CLDC[10] 和 MIDP[13]。工具是预先校验器和 Java代码压缩机(JCC)。 KVM(Kilobyte Virtual Machine) 是 Java虚拟机 (JVM) 的一个实现。它位于主机操作系统的顶端，其主要作用是运行已编译的程序单位 (class文件)。CLDC为资源受限的、可网络连接的设备提供了最基本的库和虚拟机功能。MIDP是位于CLDC配置顶端的一层。它扩展了后者，提供了更多详细的功能，即网络、图像、安全性、应用程序管理和持久存储。预先校验检查所有的Java类，以加强对象、栈和控制流的安全。这是在脱机情况下完成的，结果就作为属性储存在被编译的程序单元里。Java代码压缩机(JCC) 管理ROMize过程。后者是KVM的一个功能，它允许在启动时载入和链接Java类。就是在一个文件中产生这些类的一个映象，最终用KVM链接此映象。随着运行在支持Java设备上的可用应用程序的大量出现，安全性就极为重要了。现在，电话上的病毒开始浮现 (例如 Cabir), 一些典型的特定攻击已有报告 (例如诺基亚 6210 DoS, Siemens S55 SMS, 等等) ，而且移动攻击开始得到黑客社区的注意 (例如 www.defcon.org)。本文就针对 J2ME CLDC的安全性进行仔细研究。

在这方面，我们采取了两个主要途径。一个关于规范，另一个关于实现。

在规范的情形下，我们要提供一个对J2ME CLDC 安全性架构的全面研究，指出可能存在的缺点和可以改进的方面。至于实现，我们的目标是研究一些实现，比如Sun公司的参考实现 (RI) 平台、电话模拟器和真实电话机。

本文从介绍开始，分为四个部分。在第2部分中，我们介绍J2ME的主要安全性构架。在第3部分中，我们以先前报告的缺点开始，列出缺点分析的结果。最后，第4节总结本文。

 

2 J2ME CLDC安全性架构

在这一部分，我们介绍J2ME的安全性架构。我们要区别可连接、受限设备配置 (CLDC)的安全性和移动信息设备Profile(MIDP) 的安全性。区别的理由是二者的安全性关系是分开的。为J2ME CLDC java 平台开发的应用程序称为MIDlets。它们以二个文件的形式被下载到设备上：JAR是包含下列文件的一个档案库：JAR 清单文件, 类文件和支持文件。JAR 清单文件是包含各种属性（如MIDlet名称和发布者）的文本文件。类文件是经过预先校验的MIDlet类文件(预先校验将会在稍后讨论)。支持文件是应用程序需要的任何文件，例如实例中的图像文件。JAR文件可以包含不止一个应用程序(MIDlet) 。这组MIDlet成为一个MIDlet程序组。JAD的另一方面, 也是一个带有运行MIDlet需要的一些属性的文本文件，诸如MIDlet名称和MIDP版本。

2.1 CLDC 安全性

由于性能和安全性问题，CLDC抛弃了一些Java的普遍功能，因此其安全性也受到了影响。从而，CLDC有如下特点：没有Java本地界面(JNI)，没有用户定义的类载入程序，不支持映象，以及没有线程组或后台线程。CLDC低水平安全性一般是建立在类型安全机制上的。校验器是进行类型检查的模块。因为对资源受限设备来说，完全的字节码验证过于繁重，所以在CLDC中就改变了验证，故而一个应用程序的类首先在开发平台上进行预先校验，在目标设备上执行前，虚拟机将只会对应用程序类做有限的验证。

 

2.2 MIDP 安全性

 

2.2.1 MIDP 1.0 安全性

在 MIDP 1.0 的应用程序安全性是以Java沙箱模型为基础的。MIDP 1.0(和 CLDC)的沙箱安全性模型不同于传统的Java沙箱模型。没有安全性管理器也没有安全性策略为访问控制所用。MIDP 1.0允许MIDlet程序组把数据保存在持久储存的文件中 (记录仓储)。然而，在 MIDlet 程序组之间不能共享记录仓储。这为 MIDlet 提供了对MIDlet持久存储的一个很好保护。关于连接协议，http协议是MIDP 1.0 支持的唯一网络协议。

 

2.2.2 MIDP 2.0 安全性

MIDP 1.0 安全性模型和 MIDP 2.0 安全性模型之间的差异在于，在MIDP2.0中,存取敏感的资源（受保护的API及函数）不会被完全禁止。相反, MIDP 2.0 通过联合每个API的许可来控制存取受保护的API。一个保护域是一个这样的许可和描述如何授予许可的集合，它可能处于以下两个模式之一：允许或用户授权。在MIDlets被下载的时候，有一个算法决定这个MIDlet应该属于哪个保护域。举例来说，一个不能验证由来的MIDlet将会被赋予“不受信任”的保护域,它只有一个最小的许可集合。许可和保护域是由设备的安全性策略指定的。MIDP 2.0 安全性的详细资料能在著作[13] 和 [7]中找到。此外， MIDP 2.0引入了在 MIDlet 程序组之间共享记录存储的能力。同时，MIDP 1.0 和 MIDP 2.0 最重要的安全性差异是，后者通过允许使用https协议建立安全网络，以提供端到端的安全性。

 

3 弱点分析

在这一部分，我们介绍J2ME CLDC安全性的弱点分析。首先说明我们所使用的方法论，然后列出先前已经公布的安全性相关的缺陷。最后，给出我们能够发现的弱点列表。

 

3.1 方法学

我们所习惯的做弱点分析由五个阶段组成，说明如下。阶段1 的目标是识别主系统的软件组件。我们认为那些组件API是在最新修订版本的无线Java技术工业标准（JTWI）（即JSR 185）中托管推荐使用的。除 KVM 之外，托管性的组件是 CLDC ，MIDP 和无线消息 API(WMA)。来自Java Community Process (JCP)的可用规范文档和相关出版物都是我们的研究对象。阶段2 的目标是对平台进行逆向工程。被分析的源程序代码是 Sun 公司 对KVM ，CLDC ，MIDP 和 WMA的参考实现（RI）。我们将借助逆向工程工具(举例来说, Understand for C++, Understand for Java, and Rational Rose)。阶段3 的目标是为发现脆弱点而进行的编码安全性分析。为了达到这一目标, 我们使用两种技术：安全性编码检查和自动安全性分析。安全性编码检查依照在[1]中列出的“检查方法列表”进行。自动编码安全性分析由一些工具完成，比如：针对C语言的FlawFinder、ITS4 [19]和针对Java语言的Jlint [20]。阶段4 的目标是通过安全性测验手段发现更多的脆弱点。为了达到这一目标，我们以安全性攻击的形式设计测试用例。这些攻击情节设计的基础是：（1）我们在编码检查期间编译时可能弱点的列表，(2) 在诸如[8]和[3]这样的一些文章中介绍的所熟知的弱点，以及(3) 依照以特性为基础的测试原则从规规范文档中提取的安全性特性 [2]。这些测试用例运行于：Sun 公司的参考实现，电话模拟器，和真实的电话（摩托罗拉 V600 和诺基亚 3600）。阶段5 的目标是组织排列发现的弱点，并按照已良好确立的标准框架来评估潜在的风险。MEHARI方法[9]被用来达成这一个目标。作为这个阶段的顺便结果，一个合理有效的安全需求集将被详细描述，以便加强J2ME CLDC平台的执行。本文呈现的结果是在阶段1到4期间获得的。它们按照网络攻击时在不同系统组件里被发现而进行了分类。

 

3.2 先前报告的缺陷

 

3.2.1 Siemens S55 SMS

在2003年底，Phenoelit黑客组织[14]就已经发现Siemens S55电话有一个缺陷，使得该设备在未经用户授权的情况的下发送SMS消息。恶意MIDlet在目标用户下载它的时候执行这个攻击，在没有获得许可的情况下从用户系统发送SMS信息。这是由于一个race情形，在这种情形下，Java代码用任意的屏幕显示覆盖正常的许可请求。

 

3.2.2 Sun 公司 MIDP RI 中的问题

Sun微系统的bug数据库包含了有关J2ME CLDC 的数以百计的问题。然而, 很少涉及到安全性。下面就描述我们认为的与安全性立场相关的问题。建立一个socket连接时，许可是必要的(socket://hostname:portnumber)。但是如果一方在端口portnumber已经被占用PC上运行RI, 应用程序将不能通过许可检查 [18]。一个RSA算法执行时的问题已经有报告，报告称，大数除法函数检查的是被除数而不是除数为0[17]。在main()中调用midpInitializeMemory()方法的返回值从来不做检查[16]。当内存分配失败的时候，系统将会崩溃，而且没有任何办法断定崩溃的理由。在续篇中介绍了在我们自己的安全性分析期间发现的脆弱点。它们按照在不同系统组件里被发现而进行了组织分类（例如：仓储系统、KVM等）。

 

3.3 网络连接脆弱点

 

3.3.1 MIDP SSL 脆弱点

       为了建立一个远程的安全连接（https），MIDP 的参考实现使用了SSL v3.0 协议。此实现是以来自Sun实验室的KSSL[5]为基础的。在SSL握手期间，协议必须产生随机数来计算密钥。因此，产生不可预知的随机数是SSL安全性的一个重要方面。广为人知的是，产生优良随机数的挑战在于如何更新种子。种子是一个初值，对它应用一个特定的算法以产生随机数。产生一个随机数集合可以通过以下方法：当前种子值用来产生一个随机数，然后更新种子并产生第二个随机数，如此下去。通过检查SSL的参考实现，我们注意到种子更新仅仅依赖于系统时间(System.currentTimeMillis) 。因此，为了获得客户端产生的随机数，黑客要做的所有事情就只是猜测计算随机数时的系统精确时间（以毫秒计）。到最后，流行的以太网嗅探工具就派上用场了。举例来说，1996年针对Netscape浏览器SSL实现实施的攻击[4]中，就是使用嗅探工具来确定系统时间的秒变量。然后, 为了找出微秒变量, 尝试了一百万个可能性中的每一个可能值。

 

3.3.2 未经授权SMS发送

通常，当一个程序需要发送一个SMS消息的时候，设备会显示一个询问用户是否认可SMS消息发送并进而承担费用的对话框。从而，发送一个未经用户授权的SMS消息就被认为是一个安全缺陷。就像前面提到的那样，Phenoelit黑客组织发现了Siemens S55手机上有一个缺陷，造成设备在没有用户授权的情况下发送SMS消息。当设备询问用户SMS许可的时候，企图用不同项目来充满屏幕，这样，用户将无意中批准发送SMS消息，因为他们认为正在应答一个不同的问题。为了要证明这个弱点, 我们开发了一个使用两个线程的MIDlet。第一个发送一个SMS消息，第二个用其它项目充满屏幕但并不改变按钮的功能。这个攻击的关键点是只有荧屏被重绘。按钮 (软式按钮)的行为没有改变，它仍然是关于SMS消息许可的事件。我们使用Sun One Studio 4 在Siemens S55上运行此MIDlet。结果正如我们的期望: SMS授权对话框被一个不同项目隐藏了。这使用户认为他正在回答一个玩游戏的邀请! 我们在Siemens手机模拟器上(除了S55之外)，即2128、CF62和MC60，运行先前的MIDlet。我们发现所有的这些手机都易受到SMS授权攻击。通过检查这些手机的API，我们发现他们我SMS API几乎相同，这就解释了我们的结果。不同于Siemens手机，Sun的MIDP参考实现不易受到这样的攻击。理由是在得到用户回答以前，它阻塞了所有对屏幕的更改。

 

3.4 存储系统的弱点

 

3.4.1 管理可用的空闲存储

当一个MIDlet需要向持久存储器存储信息的时候，它能产生新的记录。因为持久存储被设备上所有的Midlet共享，因此对每个MIDlet必须约束其存储容量。就像我们在MIDp规范里看到的那样，没有对授予给定MIDlet的储存大小方面的约束。如果没有对授予一个MIDlet的储存大小方面的约束, 任何一个MIDlet为它的记录仓储获取所有可用的空闲空间，我们都不能避免。如果允许这样做，那么所有其它的MIDlet将会被禁止得到附加的持久存储(可能是对它们生命周期至关重要的)。前面的缺陷是在MIDP RI和无线工具包里发现的。

 

3.4.2 无保护的内联API缺陷

MIDP API是设计在不同抽象级别基础上的。最高级API包含开发者开发MIDlet的所有需要。低级API接近设备硬件，因此设计更困难，但是他们有较多的特权和较少的约束。倘若更高级API对这些API进行有限制的访问，这就不应该影响系统安全性。换句话说，开发者不应访问这些低级API。RecordStore类是MIDP的一组高级API。它提供给开发者需要的操纵记录仓储的功能，诸如打开、关闭、删除等等。这个类也在做这些操作之前检查存取权限，这将保护数据安全性和完整性。举例来说，没有MIDlet被允许删除另外一个MIDlet 的记录仓储。还有另外一个低级类RecordStoreFile，这个类接近设备硬件,它调用本地方法为RecordStore类提供服务。因为它有较多的存取权限并绕开安全性检验，所以这个类不应被开发人员直接可用。在Sun的RI里 ，这个类能够被程序员直接使用, 这可能会威胁到数据安全性。我们能够利用这个缺陷，使一个MIDlet删除属于另外一个MIDlet的记录仓储。

 

3.4.3 传送JAR文件[待补充]

3.4.4 传送MIDlet文件[待补充]

 

3.5 KVM 弱点[待补充]

3.5.1 内存溢出弱点[待补充]

 

3.6 线程系统弱点[待补充]

 

3.7 测试程序组

       我们工作的一个非常重要的结果，就是设计并执行一个由大量MIDlet构成的测试程序组，用来测试各种各样的Java平台安全性特征。这个测试程序组能被重复使用，来测试平台的任何更进一步的实现。程序组里的每个MIDlet都对准一个测试特定安全性功能的特定平台元件。这些MIDlet就是发现以上列出的弱点所用到的。

 

4 结论和未来工作

       本文中，我们提出了J2ME CLDC的一个安全性评估。开始我们介绍了它的安全性架构，接着介绍了我们对这个平台的弱点分析。我们研究了参考实现、电话模拟器以及真实的电话机。依照所影响的系统组件，我们提出了发现的脆弱点并进行了分类。同时，此工作的一个重要结果是设计测试程序组，能被用来评估J2ME CLDC的任何实现。有了手头的这一研究，为了改善J2ME CLDC的安全性，就得做出一些修正，可以通过对安全性模型提出修改建议，也可以为达到安全性目标，而提供一个包含在此平台上任何实现中的完全的安全功能集。

 

参考文献

[1] A. Dunsmore, M. Roper, and M. Wood. The Development
and Evaluation of Three Diverse Techniques for Object-
Oriented Code Inspection. IEEE transactions on software
engineering, 29(8), 2003.
[2] G. Fink and M. Bishop. Property Based Testing: A New
Approach to Testing for Assurance. In ACM SIGSOFT Software
Engineering Notes, pages 74–80, July 1997.
[3] G. Bracha, T. Lindholm, W. Tao and F. Yellin.
CLDC Byte Code Typechecker Specification. http:
//jcp.org/aboutJava/communityprocess/
final/jsr139/index.html, January 2003.
[4] I. Goldberg and D. Wagner. Randomness and the Netscape
Browser. Dr. Dobb’s Journal of Software Tools, 21(1):66,
68–70, Jan. 1996.
[5] V. Gupta and S. Gupta. KSSL: Experiments in Wireless Internet
Security. Technical Report TR-2001-103, Sun Microsystems,
Inc, Santa Clara, California, USA, November
2001.
[6] D. Hugo. FExplorer Web Site. http://users.
skynet.be/domi/fexplorer.htm.
[7] J. Knudsen. Understanding MIDP 2.0’s Security Architecture.
http://developers.sun.com/
techtopics/mobility/midp/articles/
permissions/, February 2003.
[8] I. Krsul. Software Vulnerability Analysis. PhD thesis, Purdue
University, 1998.
[9] MEHARI. MEHARI. Technical report, Club de la Securite
des Systemes d’information Francais, August 2000.
[10] S. MicroSystems. Connected, Limited Device Configuration.
Specification Version 1.0, Java 2 Platform Micro Edition.
Technical report, Sun MicroSystems, California, USA,
May 2000.
[11] Nokia. Series 60 Platform. http://www.nokia.com/
nokia/0,8764,46827,00.html.
[12] OMA. Implementation Best Practices for OMA DRM v1.0
Protected MIDlets, May 2004.
[13] J. V. Peursem. JSR 118 Mobile Information Device Profile
2.0, November 2002.
[14] Phenoelit Hackers Group. http://www.phenoelit.
de/, 2003.
[15] T. Sayeed, A. Taivalsaari, and F. Yellin. Inside The K
Virtual Machine. http://java.sun.com/javaone/
javaone2001/pdfs/1113.pdf, Jan 2001.
[16] Bug 4824821: Return value of midpInitializeMemory is not
checked. http://bugs.sun.com/bugdatabase/
view bug.do?bug id=4824821, February 2003.
[17] Bug 4959337: RSA Division by Zero. http:
//bugs.sun.com/bugdatabase/view bug.
do?bug id=4959337, November 2003.
[18] Bug 4802893: RI checks sockets before checking permissions.
http://bugs.sun.com/bugdatabase/
view bug.do?bug id=4802893, January 2004.
[19] J. Viega, J. Bloch, Y. Kohno, and G. McGraw. ITS4: A Static
Vulnerability Scanner for C and C++ Code. In ACSAC 2000,
2000.
[20] J. Viega, G. McGraw, T. Mutdosch, and E. Felten. Statically
Scanning Java Code: Finding Security Vulnerabilties. IEEE
Software, September/October 2000.