freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

【缺陷周话 】第23期:双重检查锁定
2019-02-25 20:36:40

代码审计是使用静态分析发现源代码中安全缺陷的方法,能够辅助开发或测试人员在软件上线前较为全面地了解其安全问题,防患于未然,因此一直以来都是学术界和产业界研究的热点,并且已经成为安全开发生命周期 SDL 和 DevSecOps 等保障体系的重要技术手段。

360代码卫士团队基于自主研发的国内首款源代码安全检测商用工具,以及十余年漏洞技术研究的积累,推出“缺陷周话”系列栏目。每周针对 CWE、OWASP 等标准中的一类缺陷,结合实例和工具使用进行详细介绍,旨在为广大开发和安全人员提供代码审计的基础性标准化教程。


1、双重检查锁定

在程序开发中,有时需要推迟一些高开销的对象初始化操作,并且只有在使用这些对象时才进行初始化,此时可以采用双重检查锁定来延迟对象初始化操作。双重检查锁定是设计用来减少并发系统中竞争和同步开销的一种软件设计模式,在普通单例模式的基础上,先判断对象是否已经被初始化,再决定要不要加锁。尽管双重检查锁定解决了普通单例模式的在多线程环境中易出错和线程不安全的问题,但仍然存在一些隐患。本篇文章以JAVA语言源代码为例,分析双重检查锁定缺陷产生的原因以及修复方法。详见CWE ID 609: Double-Checked Locking (http://cwe.mitre.org/data/definitions/609.html)。

2、 双重检查锁定的危害

双重检查锁定在单线程环境中并无影响,在多线程环境下,由于线程随时会相互切换执行,在指令重排的情况下,对象未实例化完全,导致程序调用出错。

3、示例代码

示例源于Samate Juliet Test Suite for Java v1.3 (https://samate.nist.gov/SARD/testsuite.php),源文件名:CWE609_Double_Checked_Locking__Servlet_01.java。

3.1缺陷代码

23-3-2-1.png

上述代码行23行-38行,程序先判断 stringBad 是否为 null,如果不是则直接返回该 String 对象,这样避免了进入 synchronized 块所需要花费的资源。当 stringBad 为 null 时,使用 synchronized 关键字在多线程环境中避免多次创建 String 对象。在代码实际运行时,以上代码仍然可能发生错误。

对于第33行,创建 stringBad 对象和赋值操作是分两步执行的。但 JVM 不保证这两个操作的先后顺序。当指令重排序后,JVM 会先赋值指向了内存地址,然后再初始化 stringBad 对象。如果此时存在两个线程,两个线程同时进入了第27行。线程1首先进入了 synchronized 块,由于 stringBad 为 null,所以它执行了第33行。当 JVM 对指令进行了重排序,JVM 先分配了实例的空白内存,并赋值给 stringBad,但这时 stringBad 对象还未实例化,然后线程1离开了 synchronized 块。当线程2进入 synchronized 块时,由于 stringBad 此时不是 null ,直接返回了未被实例化的对象(仅有内存地址值,对象实际未初始化)。后续线程2调用程序对 stringBad 对象进行操作时,此时的对象未被初始化,于是错误发生。

使用360代码卫士对上述示例代码进行检测,可以检出“双重检查锁定”缺陷,显示等级为中。在代码行第27行报出缺陷,如图1所示:


23-3-1-2.png

图1:“双重检查锁定”的检测示例


3.2 修复代码

23-3-1-1.png

在上述修复代码中,在第23行使用 volatile 关键字来对单例变量 stringBad 进行修饰。 volatile 作为指令关键字确保指令不会因编译器的优化而省略,且要求每次直接读值。

由于编译器优化,代码在实际执行的时候可能与我们编写的顺序不同。编译器只保证程序执行结果与源代码相同,却不保证实际指令的顺序与源代码相同,在单线程环境中并不会出错,然而一旦引入多线程环境,这种乱序就可能导致严重问题。 volatile 关键字就可以从语义上解决这个问题,值得关注的是 volatile 的禁止指令重排序优化功能在 Java 1.5 后才得以实现,因此1.5 前的版本仍然是不安全的,即使使用了 volatile 关键字。

使用360代码卫士对修复后的代码进行检测,可以看到已不存在“双重检查锁定”缺陷。如图2:


23-3-2-2.png

图2:修复后检测结果


4 、如何避免双重检查锁定

要避免双重检查锁定,需要注意以下几点:

(1)使用 volatile 关键字避免指令重排序,但这个解决方案需要 JDK5 或更高版本,因为从JDK5 开始使用新的 JSR-133 内存模型规范,这个规范增强了 volatile 的语义。

(2)基于类初始化的解决方案。

23-3-2-3.pngJVM在类的初始化阶段(即在Class被加载后,且被线程使用之前),会执行类的初始化。在执行类的初始化期间,JVM会去获取一个锁。这个锁可以同步多个线程对同一个类的初始化。



关联阅读

【缺陷周话】第 22期:错误的内存释放对象

【缺陷周话】第 21 期:数据库访问控制

【缺陷周话】第 20 期:无符号整数回绕

【缺陷周话】第19期:LDAP 注入

【缺陷周话】第18 期  XPath 注入

【缺陷周话】第17 期:有符号整数溢出

【缺陷周话】第 16 期 — 资源未释放:流

【缺陷周话】第 15 期 — 资源未释放:文件

【缺陷周话】第 14 期 :HTTP 响应截断

【缺陷周话】第 13期 :二次释放

【缺陷周话】第 12期 :存储型 XSS

【缺陷周话】第 11期 :释放后使用

【缺陷周话】第 10 期 :反射型 XSS

【缺陷周话】第 9 期 :缓冲区下溢

【缺陷周话】第 8 期 :路径遍历

【缺陷周话】第 7 期 :缓冲区上溢

【缺陷周话】第 6 期 :命令注入

【缺陷周话】第5期 :越界访问

【缺陷周话】第4期 :XML 外部实体注入

【缺陷周话】第3期 :内存泄漏

【缺陷周话】第 2 期 :SQL 注入

【缺陷周话】第1期 :空指针解引用


扫一扫,获取更多资讯

qrcode_for_gh_bba053bd7494_1280.jpg



# 代码审计 # 安全缺陷分析
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者