技巧:防范代码的 finalizer() 漏洞 一种预防创建无效类的模式

简介:

本文原作者:Neil D. Masson, Java 支持工程师, IBM (本人在拜读过程中添加了自己的一些理解。)

原文地址:http://www.ibm.com/developerworks/cn/java/j-fv/index.html?ca=drs-

简介: 您的 Java 代码有可能会因终结操作带来的漏洞而易受到攻击,了解这一漏洞是如何起作用的,并学习如何通过修改代码来防止此类攻击。

在使用终结器 (finalizer) 来创建对象时,其可能会给 Java 代码带来漏洞。该漏洞是使用终结器来恢复对象的著名技术的一种变体。当包含 finalize() 方法的对象变得无法访问时,它会被放入一个将在以后某个时刻处理的队列上。本文解释此类攻击的工作原理,介绍如何保护代码免遭此类攻击。所有代码示例都可供 下载

终结器的理念是允许 Java 方法释放任何需要返回到操作系统的本机资源。遗憾的是,任何 Java 代码都可以在终结器中运行,可以使用类似清单 1 的代码:

清单 1. 一个可恢复的类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public  class  Zombie {
     static  Zombie zombie;
 
     public  void  finalize() {
         zombie =  this ;
     }
 
     public  static  void  main(String[] args) {
         Zombie demo =  new  Zombie();
         System.out.println(demo.zombie);
         demo.finalize();
         System.out.println(demo.zombie);
     }
}

运行结果:

null

Zombie@18a992f

在调用 Zombie 终结器时,它获取被终结的对象(由 this 引用)并将它存储在静态 zombie 变量中。现在该对象又是可访问的,其不能被垃圾收集。

此代码的一种存在更大隐患的版本甚至允许恢复部分构造的对象。即使对象在初始化过程中不能通过正确性检查,其仍能够被终结器创建出来,如清单 2 所示:

清单2 :创建一个非法的类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public  class  Zombie2 {
     static  Zombie2 zombie;
     int  value;
 
     public  Zombie2( int  value) {
         if  (value <  0 ) {
             throw  new  IllegalArgumentException( "Negative Zombie2 value" );
         }
         this .value = value;
     }
 
     public  void  finalize() {
         zombie =  this ;
     }
     public  static  void  main(String[] args) {
         Zombie2 demo= new  Zombie2( 1 );
         System.out.println(demo.value);
         demo.value=- 1 ;
         demo.finalize();
         System.out.println(demo.value);
     }
}
运行结果:
1
-1
finalize()  方法的存在使对  value  参数的检查变得无效
当然,可能没有人会编写类似  清单 2  这样的代码。但如果类被继承了的话,则可能出现漏洞,如清单 3 所示:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
                 
class  Vulnerable {
   Integer value =  0 ;
  
   Vulnerable( int  value) {
     if (value <=  0 ) {
       throw  new  IllegalArgumentException( "Vulnerable value must be positive" );
     }
     this .value = value;
   }
   @Override
   public  String toString() {
     return (value.toString());
   }
}

清单 3 中的 Vulnerable 类用于预防设置非正的 value 值。此意图被 AttackVulnerable() 方法破坏,如清单 4 所示:

清单 4. 破坏 Vulnerable 类的类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
class  AttackVulnerable  extends  Vulnerable {
   static  Vulnerable vulnerable;
 
   public  AttackVulnerable( int  value) {
     super (value);
   }
 
   public  void  finalize() {
     vulnerable =  this ;
   }
 
   public  static  void  main(String[] args) {
     try  {
       new  AttackVulnerable(- 1 );
     catch (Exception e) {
       System.out.println(e);
     }
     System.gc();
     System.runFinalization();
     if (vulnerable !=  null ) {
       System.out.println( "Vulnerable object "  + vulnerable +  " created!" );
     }
   }
}

AttackVulnerable 类的 main() 方法试图创建一个新的 AttackVulnerable 对象实例。因为 value 的值超出了范围,所以抛出了一个被catch 块捕获的异常。System.gc() 和 System.runFinalization() 的调用促使 VM 运行一个垃圾回收周期并运行一些终结器。这些调用不是成功攻击的必要条件,但它们可用来说明攻击的最终结果,那就是创建了一个包含无效值的 Vulnerable 对象。

运行测试用例会得到以下结果:

java.lang.IllegalArgumentException: Vulnerable value must be positive
 
Vulnerable object 0  created!

为什么 Vulnerable 的值是 0,而不是 -1?请注意,在 清单 3 中的 Vulnerable 构造函数中,在执行参数检查后才会给 value 赋值。所以 value 拥有自己的初始值,在本例中为 0。

这种类型的攻击甚至可用于绕过显式安全检查。例如,如果在 SecurityManager 下运行并且调用方没有权限向当前目录写入数据,就可以使用清单 5 中的 Insecure 类来抛出 SecurityException

清单 5. Insecure 类


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
import  java.io.FilePermission;
 
public  class  Insecure {
   Integer value =  0 ;
 
   public  Insecure( int  value) {
     SecurityManager sm = System.getSecurityManager();
     if (sm !=  null ) {
       FilePermission fp =  new  FilePermission( "index" "write" );
       sm.checkPermission(fp);
     }
     this .value = value;
   }
   @Override
   public  String toString() {
     return (value.toString());
   }
}

清单 5 中的 Insecure 类可通过与前面相同的方式攻击,如清单 6 中的 AttackInsecure 类所示:

清单 6. 攻击 Insecure 类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public  class  AttackInsecure  extends  Insecure {
   static  Insecure insecure;
 
   public  AttackInsecure( int  value) {
     super (value);
   }
 
   public  void  finalize() {
     insecure =  this ;
   }
 
   public  static  void  main(String[] args) {
     try  {
       new  AttackInsecure(- 1 );
     catch (Exception e) {
       System.out.println(e);
     }
     System.gc();
     System.runFinalization();
     if (insecure !=  null ) {
       System.out.println( "Insecure object "  + insecure +  " created!" );
     }
   }

在 SecurityManager 下运行 清单 6 中的代码会得到以下输出:

java -Djava.security.manager AttackInsecure
java.security.AccessControlException: Access denied (java.io.FilePermission index write)
Insecure object 0  created!

 如何避免攻击

在 Java SE 6 中实现第三版 Java 语言规范 (JLS) 之前,避免攻击的仅有方式是使用 initialized 标志、禁止子类化或创建 final 终结器)并不是令人满意的解决方案。

使用 initialized 标志

一种避免攻击的方式是使用 initialized 标志,在正确创建对象之后它被设置为 true。该类中的每个方法首先检查是否设置了initialized,如果没有设置则抛出一个异常。这样的代码编写起来很无趣,很容易被意外省略,也无法阻止攻击者子类化该方法。

预防子类化

您可以将所创建的类声明为 final。这意味着没有人可创建该类的子类,这会阻止攻击生效。但是,此技术降低了灵活性,无法扩展该类来特殊化它或增加额外的功能。

创建一个 final 终结器

可以为所创建的类创建一个终结器并将它声明为 final。这意味着该类的任何子类都无法声明终结器。此方法的缺点是,终结器的存在意味着对象的存活期比其他情况下更长。

一种新的、更好的方式

为了更容易避免此类攻击,而无需引入额外的代码或限制,Java 设计人员修改了 JLS(参见 参考资料),声明如果在构造java.lang.Object 之前在构造函数中抛出了一个异常,该方法的 finalize() 方法将不会执行。

但是如何在构造 java.lang.Object 之前抛出异常呢?毕竟,任何构造函数中的第一行都必须是对 this() 或 super() 的调用。如果构造函数没有包含这样的显式调用,将隐式添加对 super() 的调用。所以在创建对象之前,必须构造相同类或其超类的另一个对象。这最终导致了对 java.lang.Object 本身的构造,然后在执行所构造方法的任何代码之前,构造所有子类。

要理解如何在构造 java.lang.Object 之前抛出异常,需要理解准确的对象构造顺序。JLS 明确给出了这一顺序。

当创建对象时,JVM:

  1. 为对象分配空间。
  2. 将对象中所有的实例变量设置为它们的默认值。这包括对象超类中的实例变量。
  3. 分配对象的参数变量。
  4. 处理任何显式或隐式构造函数调用(在构造函数中调用 this() 或 super())。
  5. 初始化类中的变量。
  6. 执行构造函数的剩余部分。

重要的是构造函数的参数在处理构造函数内的任何代码之前被处理。这意味着,如果在处理参数时执行验证,可以通过抛出异常预防类被终结。

这带来了 清单 3 的 Vulnerable 类的一个新版本,如清单 7 所示:

清单 7. Invulnerable 类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class  Invulnerable {
   int  value =  0 ;
  
   Invulnerable( int  value) {
     this (checkValues(value));
     this .value = value;
   }
 
   private  Invulnerable(Void checkValues) {}
 
   static  Void checkValues( int  value) {
     if (value <=  0 ) {
       throw  new  IllegalArgumentException( "Invulnerable value must be positive" );
     }
     return  null ;
   }
 
   @Override
   public  String toString() {
     return (Integer.toString(value));
   }
}

在 清单 7 中,Invulnerable 的公共构造函数调用一个私有构造函数,而后者调用 checkValues 方法来创建其参数。此方法在构造函数执行调用来构造其超类之前调用,该构造函数是 Object 的构造函数。所以如果 checkValues 中抛出了一个异常,那么将不会终结Invulnerable 对象。

清单 8 中的代码尝试攻击 Invulnerable

清单 8. 尝试破坏 Invulnerable 类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
                 
class  AttackInvulnerable  extends  Invulnerable {
   static  Invulnerable vulnerable;
 
   public  AttackInvulnerable( int  value) {
     super (value);
   }
 
   public  void  finalize() {
     vulnerable =  this ;
   }
 
   public  static  void  main(String[] args) {
     try  {
       new  AttackInvulnerable(- 1 );
     catch (Exception e) {
       System.out.println(e);
     }
     System.gc();
     System.runFinalization();
     if (vulnerable !=  null ) {
       System.out.println( "Invulnerable object "  + vulnerable + "
created!");
     else  {
       System.out.println( "Attack failed" );
     }
   }
}
 
with the addition of
 
     else  {
       System.out.println( "Attack failed" );

使用 Java 5(针对较旧 JLS 版本而编写),创建了一个 Invulnerable 对象:

1
2
java.lang.IllegalArgumentException: Invulnerable value must be positive
Invulnerable object  0  created!

在 Java SE 6(自 Oracle 的 JVM 的通用版本和 IBM 的 JVM 的 SR9 开始)及以后的规范中,不会创建该对象

1
2
java.lang.IllegalArgumentException: Invulnerable value must be positive
Attack failed

结束语

终结器是 Java 语言的一种不太幸运的功能。尽管垃圾收集器可自动回收 Java 对象不再使用的任何内存,但不存在回收本机内存、文件描述符或套接字等本机资源的机制。Java 提供了与这些本机资源交互的标准库通常有一个 close() 方法,允许执行恰当的清理,但它们也使用了终结器来确保在对象错误关闭时,没有资源泄漏。

对于其他对象,通常最好避免终结器。无法保证终结器将在何时运行,或者甚至它是否会运行。终结器的存在意味着在终结器运行之前,不会对无法访问的对象执行垃圾收集,而且此对象可能使更多对象存活。这导致活动对象数量增加,进而导致 Java 对象的堆使用率增加。

终结器恢复即将被垃圾收集的能力无疑是终结机制工作方式的一种意外后果。较新的 JVM 实现现在保护代码免遭此类安全隐患。


==============================================================================
本文转自被遗忘的博客园博客,原文链接:http://www.cnblogs.com/rollenholt/archive/2011/10/13/2210166.html,如需转载请自行联系原作者
相关文章
|
10月前
|
安全 前端开发 JavaScript
信息服务上线渗透检测网络安全检查报告和解决方案2(安装文件信息泄漏、管理路径泄漏、XSS漏洞、弱口令、逻辑漏洞、终极上传漏洞升级)
信息服务上线渗透检测网络安全检查报告和解决方案2(安装文件信息泄漏、管理路径泄漏、XSS漏洞、弱口令、逻辑漏洞、终极上传漏洞升级)
137 0
使用LamdbaUpdateWrapper的setSql作用及风险
使用LamdbaUpdateWrapper的setSql作用及风险
使用LamdbaUpdateWrapper的setSql作用及风险
|
6月前
|
自然语言处理 安全 API
【网安AIGC专题10.11】①代码大模型的应用:检测、修复②其安全性研究:模型窃取攻击(API和网页接口) 数据窃取攻击 对抗攻击(用途:漏洞隐藏) 后门攻击(加触发器+标签翻转)(上)
【网安AIGC专题10.11】①代码大模型的应用:检测、修复②其安全性研究:模型窃取攻击(API和网页接口) 数据窃取攻击 对抗攻击(用途:漏洞隐藏) 后门攻击(加触发器+标签翻转)
180 0
|
6月前
|
机器学习/深度学习 人工智能 安全
【网安AIGC专题10.11】①代码大模型的应用:检测、修复②其安全性研究:模型窃取攻击(API和网页接口) 数据窃取攻击 对抗攻击(用途:漏洞隐藏) 后门攻击(加触发器+标签翻转)(下)
【网安AIGC专题10.11】①代码大模型的应用:检测、修复②其安全性研究:模型窃取攻击(API和网页接口) 数据窃取攻击 对抗攻击(用途:漏洞隐藏) 后门攻击(加触发器+标签翻转)
127 1
|
7月前
|
存储 设计模式 安全
渗透攻击实例-设计缺陷/逻辑错误
渗透攻击实例-设计缺陷/逻辑错误
|
9月前
|
安全 druid Java
【紧急】Apache Log4j任意代码执行漏洞安全风险升级修复教程
近期一个 Apache Log4j 远程代码执行漏洞细节被公开,攻击者利用漏洞可以远程执行代码。经过分析,该组件存在Java JNDI注入漏洞,当程序将用户输入的数据进行日志,即可触发此漏洞,成功利用此漏洞可以在目标服务器上执行任意代码。
223 1
|
SQL 安全 搜索推荐
如何处理网站被植入恶意的一些代码导致的被机房拦截提示
如何处理网站被植入恶意的一些代码导致的被机房拦截提示
245 0
如何处理网站被植入恶意的一些代码导致的被机房拦截提示
|
云安全 域名解析 安全
斩断Log4j2 RCE漏洞验证和利用链,主动外联管控你值得拥有
本文将介绍Apache Log4j2远程代码执行漏洞常见的验证、利用方式及其原理,并给出基于外联管控的防护方案。
1569 0
斩断Log4j2 RCE漏洞验证和利用链,主动外联管控你值得拥有
|
安全 数据安全/隐私保护
Gawker攻击事件暴露密码保护缺陷
导语:国外媒体今天撰文称,美国网络媒体公司Gawker Media的黑客攻击事件暴露出,在不同网站使用相同用户名和密码的安全隐患。 以下为文章全文: Gawker Media一周前遭遇的黑客攻击凸显出网络生活日益频繁所带来的安全风险:在多家网站使用相同的用户名密码虽然很方便,但却会面临很高的代价。
1071 0