Java和.net在安全性能上的比较：吸取到的教训和遗漏外文翻译资料

 2022-10-26 10:14:26

英语原文共 13 页，剩余内容已隐藏，支付完成后下载完整资料

Java和.net在安全性能上的比较：吸取到的教训和遗漏

纳撒尼尔·保罗、大卫·埃文斯

维吉尼亚大学计算机科学系

【摘要】为了调节对系统资源的访问，许多系统在虚拟机上执行不受信任的程序。甲骨文公司在1995年推出了Java虚拟机，主要是把其作为一个轻量级的平台以便在网页上执行不受信任的代码。最近，微软出于同样的目的开发了.net平台。两个平台在设计和属性实现上面有很多相似之处，但是Java和.net的核心区别对它们的安全性产生了影响。本文考察了.net的设计是如何避免了漏洞以及已经发现的Java的缺陷，同时讨论从Java安全经历中得到的教训和遗漏。

【关键字】虚拟机安全性 Java安全性 .net 安全性 安全性设计原则 字节码验证器 恶意代码 代码安全

正文

介绍

·Java和.net都是在安全限制先执行不受信任程序的平台。虽然它们有着相似的目的，它们的设计在许多方面也都相似，但这两个平台的安全性缺陷却有着很大不同。

图1，已经报道的主要的安全性缺陷

图一展现了两个平台各自被报道的主要的安全缺陷。在2005年12月份，共同漏洞和风险数据库包含了150个与Java漏洞相关的入口（mitre公司，共同风险公司），其中38个漏洞归类于Java平台安全漏洞（我们不考虑与虚拟机本身无关的特殊应用错误）。剩下的不是由CVE提供的包含在图一中的漏洞来自Sun公司（Sun微型系统，2002）（9个漏洞）还有McGraw和Felten（1999）（5个漏洞）。与之相比，没有被发现任何主要安全漏洞的.net平台着实让人吃惊。这篇文章研究两个平台的安全性漏洞的数量上的不同是否是因为它们在基础上设计的差异。

表格1 Java安全漏洞

表格一总结了在过去10年内被报道java安全漏洞。Hopwood（1996），普林斯顿安全的互联网编程团队以及McGraw和Felten，指出了早期Java实现中的数个漏洞。其余部分记录在Sun公司的年表上（Sun 微型系统，2002；Sun 微型系统 Sun j警示）以及CVE的数据库中（Mitre 公司，共同漏洞）。

相比较而言，目前为止.NET平台还没有任何安全方面的漏洞被报道出来。最广泛公开的在.NET安全方面的问题即W32.Donut，这是一种在.NET进行时起作用之前就会控制执行。因为这个漏洞发生在.NET运行时取得控制权之前，我们认为这个问题和操作系统转移控制权给.NET有关与.NET平台本身无关。其它八个被指出来的.net的安全问题被列在微软的知识库中（Farkas）以及CVE的数据库中（Mitre 公司，通用漏洞）,但是本篇文献的所使用的标准看，这些都不是平台安全漏洞。附录A解释了这些问题以及为什么我们不考虑它们。

关于.net平台表面上看起来很少有漏洞有许多可能的解释。一种可能是与Java相比，.net平台对攻击者有更少的吸引力，因此它还没有受到揭示漏洞所必要的监视。但是，自从.net框架已经作为一项Windows更新这似乎不是那么回事。因为Windows已经占据了笔记本市场的90%，许多机器都是使用.net,这让.net平台成为一个具有吸引力的目标。

另外一种可能的原因是，Java虚拟机的实现方式有很多种，然而.net只是微软的单一的实现，因此，Java的漏洞被发现的较多。从可以得到的信息中，一种有许多自己独有的漏洞的实现就是微软的Java实现。某种程度上这主要是由于在2002年12月份的时候被Pynnonen被报道出来的10个漏洞。在早些年头，1996年3月份的时候，微软公司和网景公司已经给Java颁发许可证，即1.0版本被发布出来2个月之后（Sun微型系统，Java）。作为java许可，微软和网景实现都是基于Sun实现（Sun 微型系统，2002）许多代码和设计都是被三种实现共享的。最初的九个被报道的java漏洞确实影响了这三种实现，包括最初的13个验证漏洞中的5个。虽然流行的.net平台的开源存在，但是无论是Mono还是dotGun，都没有完全通过安全性实施代码使之能够运行部分的可信赖代码。

另外一种可能性.net避免了已经通过java之前的经验了解了的特殊漏洞。这也许是对的在某些情况下，但是一般说来这并不是.net安全漏洞较少的原因。在这些平台之间有足够的区别，许多安全漏洞不能够直接模拟。而且，在.net发布之后新版本的java中依然持续出现新的漏洞。

在本文中我们探索了更具有积极意义的假说，.net在基础的设计上安全性就强于java，而且尤其是，它从java使用经验中学习和加强的一般安全原则中受益。从java的经验中学到的一般的教训都不是最新的。它们中的大部份甚至可以追溯到Saltzer和Schroeder的经典论文中，而且这些教训对安全分析员来说都不会感到惊讶。尤其是，经济运行机制，最小特权，故障安全缺省值都是加强安全性的设计原则，但是这会经常与其他目标冲突比如可用性和复杂性，其他安全性原则，包括Viega和McGrawrsquo;s（2001），都包含相似的属性，比如深度保护以及保护最弱的一环。Viega和Mcgraw强调在应用程序的上下文中安全原则，而且遵从这些统一的安全性原则允许程序员在为与过去不同的方式不同的未知的攻击做准备时去权衡不同的设计优劣，（Viega和McGraw，2001）。Java的具体的经验告诉我们使用在一个特定的安全关键的系统中这些众所周知的原则是怎么样失败导致了漏洞的。

先前的工作，包括Pilipchuk的文章，已经从操作性角度比较的java和.Net的安全机制以及特点。在这篇文章中，我们会从java使用的经验教训思考这些不同产生的原因，

这篇文章主要的贡献在于以下方面：（1）阐述了java安全漏洞的历史是如何证明遵从已经建立其阿里的安全原则是失败的；（2）确认.net的安全机制是如何表明java的漏洞和缺陷；（3）讨论java和.net设计上的不同是如何影响它们的安全属性。

接下来，我们提供一个关于两个平台的概览。第三部分描述低级代吗的安全强调了简单的重要性。第四部分检查了原则的定义和权限强调了故障安全缺省值的原则，最小优先权，以及完全控制。根据代码属性把代码和原则链接起来会在第五部分讨论。接下来，第六部分描述了jvm和CLR执行原则是如何评估它们在应用这些最小优先权，故障安全默认值以及完全执行原则。。第七部分将从心理接收方面讨论两个平台的缺点。

2.平台综述

如实图二所示，Java和.NET使用虚拟机在执行程序时执行政策。Java这个词，既可以指高级编程语言又可以指一个平台。我们使用java表达一个平台的概念，这个平台包含运行java类的一切东西，包括在图一左边部分包含java虚拟机代码语言（JVML，又被称为“java字节码”），除了这个操作系统以及受保护的资源。一个java jar文件封装java类同时包括其他资源比如数字签名或者图片。Java设计出来主要是挺一个可信的环境用来执行嵌入到网页的小程序。

.NET包括.NET图的部分涉及执行组件，除了操作系统以及受保护的资源。一个.net组件，类似于java的jar文件，死一个可执行的或者动态的链接库，包含微软中级指令语言（MSIL），一些关于组件元数据，以及一些可选择资源。.NET在托管代码和未托管代码之间作区分。因为安全策略不能用来执行未托管代码，我们只考虑托管代码。

Java和.NET都有巨大的可信计算基，这就允许许多失败点。TCB包含图一中的一切东西出来外部不受信程序（java类或者.NET组件）。在java中，在字节码校验器，类加载器，java虚拟机或者底层操作系统中出现的漏洞能够用来检验安全性属性。在.NET中，在策略管理员，类加载器，JIT校验器，公共语言运行库，或者底层操作系统能够用来验证安全性属性。可信计算基的大小使得对两个平台整体安全性做阐述变得不可行；相反，我们可以假定其他因素（尤其是底层操作系统）正常运行，以便来分析单个因素。

JVML或者MSIL代码能够被源代码由高级语言程序比如java或者c#编写的编译器执行， 但是这些文件能够以其他方式被创造出来。虽然高级编程语言能够提供确定的安全属性，没有任何一种方式能够确保交付的JVML或者MSIL代码是通过一个可信的编译器以一种特殊的语言从源代码中产生的。因此，这个唯一的与不受信代码相对的安全性是由平台提供的。这篇文章没有考虑相关的java和C#编程语言的优点，只是比较这两个执行平台的安全属性。

因为java平台于1992年被发布出来，java的安全模式已经逐步发展为整合额外的安全机制，包括代码信号和逐步增加的灵活的政策。当具体的执行问题考虑进来的时候，我们解决当前每个平台的执行标准：java 2 软件开发包1.4.1以及.NET framework1.1.

Java和.NET使用静态分析和动态检验的组合，在执行程序时执行策略。Java的字节码校验器和.NETde JIT校验器静态的校验低级代码属性，这是允许程序运行之前类型安全，内存安全以及控制流安全所必须的。其他属性必须动态的检验以确保低级语言代码的安全。第三部分描述的低级代码安全属性。30个在通用漏洞和风险暴露数据库中（Mitre公司，通用漏洞）java平台的安全漏洞以及6个早先的漏洞（McGraw和Felton，1999，Sun 微型系统，2002）直接归于java字节码检验器执行的缺陷。通过校验器的程序都是在java虚拟机上执行的或者.Net公共语言运行库。虚拟机使用一个引用监视器间接访问以保护系统资源。

3.低层代码安全

低层代码安全包括代码的类型，内存以及控制流属性。没有这些属性，应用能够规避几乎所有的高层安全机制。这个从java低层代码安全经验中学到的主要的教训可以追溯到最高的安全原则之一：保证事情的简单。

类型安全确保了一个给定类型对象会被一个合适的的方式使用。特别是，类型安全阻止了非指针被引用访问内存。没有类型安全性，一个程勋不可能构建一个整数值来对应于一个-目标地址，接着使用它作为一个指针来引用内存中一个任意的位置。内存安全保证了一个程勋不能够访问内存从外部适当的分配对象。缓冲区溢出攻击通过重写其他数据检验内存安全，即通过在分配的存储区外重写。控制安全，保证了所有的跳出都是有效的地址。没有控制安全，一个程序有可行直接跳到系统代码段或者注入代码，因此绕过安全检查。

Java和.NET取得底层代码安全通过静态验证和运行时检验。在典型的java执行中，静态的校验是在加载的时候通过字节码验证器做到的。一个万千的雷士在它在虚拟机上执行之前就会被验证。在.NET中部分验证是编译做到了。所有的代码必须通过验证器，在它们被允许运行之前。

3.1校验器

校验程序的第一步就是校验代码的文件（ECMA国际，2002；Lindholm和Yellin，1999）。这些文件根据java类文件或者.NET的PE/COFF文件格式来检验（lindholm和Yellin，1999；微软公司，微软便携可执行）。紧跟着文件格式的验证，这个验证器也会检验一些静态的规则以确保对象，方法和类被良好的建立。

接下来，校验器促使每个指令沿着每个潜在的执行路径检验类型以及其他的验证。因为JVML和MSIL是基于堆栈的语言，标记堆栈的状态来促使执行，同时追踪每个指令的信息来保证底层代码安全性。如果类型验证出现或者堆栈操作引起上溢或者下溢验证就会失败。另外，所有的分支指令目标都有合法位置用来确保控制流的安全。

校验类型安全的一般问题是不可判定的。所以做出确定的假定必须确保校验可追踪。两者的校验器都是保守的：如果一个程序通过了校验，它就能够保证满足规定的安全属性，然而，那些类型安全却验证失败的程序存在。一个更成熟的验证器能够接受更多的安全程序（仍然拒绝所有的不安全程序），但是增加验证器的复杂性更有可能产生更多的漏洞。

通过验证器的代码允许在虚拟机上运行，但是附加的运行时检验也是必须的但是不能够被静态检验。运行时检验是用来保障数组的存储和读取在分配的范围内，元素的存储近数组的类型是正确的（因为协变类型的数组在JVML和MSILz红都不能够被静态的检验），而且低投对象是正确的类型。

在java字节码验证器或者微软的JIT验证器中的漏洞能够被有敌意的程序利用来规避所有的安全措施，所以验证器的复杂性要尽可能的避免。

JVML和MSIT验证器都是相对比较小但是复杂的程序.Sun的1.4.2版本的验证器（Sun微系，java 2 SDK）是由4077行代码构成（不包括检查文件格式的代码）。对.NET而言，我们检查Rotor，他是共享的资源代码，是微软ECMA CLI的执行标准的元数据。

3.2 指令集

自验证的复杂性直接相关的指令组的虚拟机，检查指令集提供验证的复杂性的一些措施。 每个平台都使用200操作码，但在他们的指导一些重要的区别设置在其核查的复杂影响。 本节考虑从它是多么复杂的验证底层代码安全性的角度之间的差异JVML和MSIL指令集。

表2 总结了指令集为每个平台。 指令集之间的一个明显的区别是JVML具有每种类型的指令独立的版本，而.NET使用单个指令来对不同类型的执行相同的操作。 例如，Java有四种不同的附加 ​​说明根据数据的类型（IADD添加整数，FADD添加浮筒等），其中，.NET具有一个指令，该指令在不同类型的作品。 使用通用指令多种类型，而不是仅仅两种类型进行操作，使核查稍有难度，但同时也意味着.NET具有可用于其他用途更多的指令操作码。 .NET使用一些指令，能提供溢出和算术运算符号版本。 算术运算的溢出版本扔如果计算溢出异常，使应用程序能够更好地处理溢出，避免算术溢出（如 核心安全技术咨询 报告的Snort的TCP

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[153975]，资料为PDF文档或Word文档，PDF文档可免费转换为Word

原文和译文剩余内容已隐藏，您需要先支付 30元 才能查看原文和译文全部内容！立即支付

以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。

您可能感兴趣的文章