内在/字节码注释安全性

时间:2015-02-10 22:11:24

标签: bytecode language-design intrinsics jvm-languages

我目前正在制作基于JVM的编程语言。我没有使用运算符,而是选择允许符号作为方法名称,并为原始数据类型创建编译器引用类。这些都使用所谓的@Intrinsic注释进行注释,这些注释将Bytecode指令作为其参数。编译器不是使用INVOKE指令,而是在每次调用时使用这些指令生成字节码。

我现在想知道这个(公共)注释是否可用于在JVM上做任何恶意攻击,以及它是否应该被编译器限制,例如通过静态分析。

(语言本身也支持字节码表达式)

2 个答案:

答案 0 :(得分:1)

JVM将在使用前验证字节码,字节码的历史记录与此过程无关。最后,如果验证者无法识别某种无效的,可能是恶意的字节码模式,其危险性不取决于该字节码模式是使用编译器和注释创建的还是手工创建的。

这就是首先验证概念的原因。 JVM并不认为编译器总是没有错误。

但是,让编译器执行合理性检查,静态分析甚至对创建的字节代码执行自己的验证仍然是个好主意。如上所述,如果JVM的安全性依赖于编译器正确地执行所有操作,那么它就不会涉及安全性。但它是关于可用性的,大多数用户喜欢立即得到错误的响应,而不需要实际运行代码来了解它是无效的。

答案 1 :(得分:0)

通常,如果您可以在JVM上执行您选择的代码,那么您已经可以做恶意的一切。 JVM很难正确地沙箱。

真正的问题是你的威胁模型是什么。通常,如果您在计算机上运行已编译的可执行文件,则假定它可以执行您可以作为当前用户执行的任何操作。甚至JVM也在台式机上遵循这种模式。 (还有Java浏览器插件试图在从web加载的applet上强制实施Java级沙箱,但遗憾的是收效甚微)