1.Linux下的诱惑源码Meltdown攻击实践（含代码）
2.lodash源码分析——deepclone
3.安全干货DockerCVE-2018-6552
Linux下的Meltdown攻击实践（含代码）
北京时间年月日，Google Project Zero公开了Meltdown（熔毁）漏洞，诱惑源码指出该漏洞能够影响几乎所有的诱惑源码Intel CPU和部分的ARM CPU，于是诱惑源码相关的侧信道攻击方式由此开始走进大众的视野。
Meltdown攻击是诱惑源码一种直接针对底层硬件机制（CPU的乱序执行机制、Cache机制和异常处理机制）的诱惑源码暗底源码时间侧信道攻击，它的诱惑源码基本原理如下所示：
这里对上图及上述条件作简单解释：从顶层程序的角度来看，指令A、诱惑源码B和C应该是诱惑源码顺序执行的，且由于指令A访问了非法地址的诱惑源码数据会触发异常，故指令B和C的诱惑源码操作不会被执行；然而，从底层硬件的诱惑源码角度来看，指令A、诱惑源码B和C满足乱序执行的诱惑源码条件，于是诱惑源码在下一指令所需要的数据准备完成后就可以立即开始下一指令的执行。在图中指令A的“阶段A_1”结束后，指令B由于所需要的数据已经准备完成故可立即开始执行；在图中指令B的“阶段B_1”结束后，指令C由于所需要的数据已经准备完成故可立即开始执行。若“阶段A_2”的执行时间大于“阶段B_1”的执行时间和“阶段C_1”的执行时间之和，则非法数据能够经过运算产生合法地址，且该合法地址的坐标投影源码数据能够被放入L3_Cache中；若在指令A的“阶段A_2”结束后，检查出非法访问所引起的回滚冲刷不影响L3_Cache，则与非法数据相关的合法数据依然存在于L3_Cache中。最后，通过遍历访问合法地址的数据，并对访问时间进行计时，能够找到某个访问时间明显较短的合法数据，该数据的合法地址即为指令B中由非法数据经过运算后所得到的值，从而可以反推出原非法数据，于是间接地得到了非法地址中的数据。
随后将详细说明完整的Meltdown攻击是如何具体实施的，文中攻击实践的操作系统平台为虚拟机中的Ubuntu。此前，在虚拟机中的Ubuntu和某服务器中的某操作系统上也能够成功实施该Meltdown攻击，只是某些具体的实施步骤和本文有细微差别。
简单写一个字符设备驱动程序，该驱动程序运行在操作系统内核态，私有存储空间内有一段秘密信息。这里只实现了它的IOCTL函数、OPEN函数和READ函数，其中主要关注如下所示的网站源码 代购READ函数（带注释的完整源代码已上传至Github）：
该READ函数能够将内核空间中的秘密信息的存储地址反馈给用户空间中的一般用户程序，于是一般用户程序可通过直接调用该函数得到秘密信息的存储地址。然而，对于一般用户程序来说，通过该READ函数读取到的地址是一个不可访问的非法地址，其中的数据对一般用户程序不可见，也就是说一般用户程序无法通过正常的访问流程来获取该秘密信息。但是，随后的Meltdown攻击的对象即为该驱动程序，这一侧信道攻击方式可绕过操作系统的隔离间接地窃取到该秘密信息。
首先，编译该驱动程序的源代码，生成可加载的内核模块：
在加载编译生成的内核模块之前，先看一下操作系统中已经加载的内核模块，以作对比：
接下来，加载编译生成的内核模块；然后，再次查看操作系统中已经加载的内核模块：
对比以上两图，可以看出"Module"一列的第一行新增了内核模块"memdev"，说明OS内核模块加载成功。
最后，在内核模块加载完成的gym源码解析基础上，还需要在/dev目录下创建对应的设备节点文件，从而一般用户程序可以通过该文件访问内核模块：
尝试调用该内核模块（带注释的完整源代码已整合进Meltdown攻击代码中并上传至Github）：
至此，作为攻击对象的目标驱动程序已经被加载成为内核模块，且能够被一般用户程序正常调用。
首先，通过操作系统自带的文件查看是否存在Meltdown漏洞：
其次，通过Github上的spectre-meltdown-checker程序来查看是否存在Meltdown漏洞：
接下来，通过添加内核参数"nopti"以关闭操作系统的Meltdown补丁：
重启操作系统后再次查看是否存在Meltdown漏洞：
最后，通过运行Github上的meltdown-exploit程序来查看操作系统是否真的能够被Meltdown攻击窃取一些秘密信息：
至此，操作系统的Meltdown补丁已经被关闭，此时可通过Meltdown攻击窃取其中的部分秘密信息。
首先，分析Meltdown攻击的源代码（带注释的完整源代码已上传至Github）：
1. 主函数内主要包括五个运行步骤，具体说明分别如下：
2. 主函数内最关键的函数为attack函数，其中主要包括四个步骤，具体说明分别如下：
3. attack函数内的核心部分是attack_core函数，该部分也即是整个Meltdown攻击的硬件机制缺陷利用点所在：
其中值得注意的是上述汇编代码的第八行、第九行和第十一行。第八行：对目标地址进行非法访问，将其中的dropbear 源码下载字节数据放入寄存器al（寄存器rax的低8位）；第九行：将寄存器rax左移位，相当于乘上（该乘数至少为一个Cache_Line的大小，否则攻击中使用的相邻存储地址会相互影响）；第十一行：将非法访问的数据作为新地址的一部分，再访问新地址(rbx+rax*0x1)中的数据以将其载入Cache。在第八行的指令执行完后，以顺序执行的角度来看，由于第八行的指令进行了非法访问，故CPU会产生异常阻止接下来的指令执行；然而，由于乱序执行机制的存在，第九行和第十一行的指令会在第八行的指令的异常处理完成之前就开始执行，且CPU异常处理的回滚机制并不会改变L3_Cache中的内容，于是第九行的指令将秘密信息混入合法地址中，第十一行的指令将合法地址的信息混入L3_Cache中。在异常处理函数中简单地完成对相应异常的处理后，即可通过L3_Cache利用典型的"Flush+Reload"Cache攻击来反推出原秘密信息。
最后，编译并执行Meltdown文件，得出的Meltdown攻击结果如下所示：
至此，Meltdown攻击的具体实践成功完成。
以上三条防护措施只是所有可能的防护措施的一部分，也存在其它有效的针对Meltdown攻击的防护措施。
第1、2条防护措施需要对底层的硬件做出改动，对成本和性能的影响较大，在实际工程中难以接受其带来的负面作用；第3条防护措施是操作系统层面的漏洞修补，对成本和性能的影响相对较小，目前以各操作系统补丁的形式被实施(KAISER/KPTI)。
meltdownattack.com/
Meltdown: Reading Kernel Memory from User Space
github.com/paboldin/mel...
2. Linux驱动相关：
paper.seebug.org//
/article--1...
4. x汇编相关：
ibiblio.org/gferg/ldp/G...
blog.csdn.net/littlehed...
blog.chinaunix.net/uid-...
en.wikibooks.org/wiki/X...
5. 本文源代码相关：
github.com/hahaha...
lodash源码分析——deepclone
lodash源码分析——deepclone，基于4..版本
本文从源码阅读初心者的角度，一句一句深入分析lodash的deepclone方法，从入口函数开始，逐步解析每一个关键步骤。
入口函数调用cloneDeep.js，通过掩码位判断是否进行深拷贝与复制symbol类型。
在baseClone.js中，通过内部函数调用baseClone进行主要逻辑处理。先判断对象是否为普通对象，然后使用getTag方法获取对象的类型标识。
getTag方法通过baseGetTag进行判断，获取symbol类型时返回symbol.toStringTag属性。现代浏览器支持返回特定类型标签，如内置对象类型或新出现的类型如Map、Promise等。对于自定义类创建的对象，若无特定标签则返回[object Object]。
继续解析baseClone逻辑，重点在于针对不同类型的对象进行区分处理，包括数组、普通对象、函数等。函数和空对象返回{ }，不进行深拷贝。
在处理复杂类型如数组和对象时，baseClone采用initCloneArray和copyArray函数优化拷贝过程。对于循环引用问题，通过构造栈结构解决，保证了代码的兼容性和易用性。
对于symbol类型，通过Object.getOwnPropertySymbols方法获取symbol的副本，确保深拷贝操作的完整性。
总结，lodash的deepclone方法通过Object.prototype.toString.call得到对象的类型标识，根据标识进行针对性处理，同时解决循环引用问题，兼容现代浏览器的symbol类型。然而，对于function类型仍然采用引用拷贝，未进行深拷贝处理原型链上的属性。
本文由某初学者撰写，旨在分享lodash deepclone源码分析过程，提供一个从入门到深入理解的路径参考。完成日期：年7月日。
安全干货DockerCVE--
cve--
此漏洞未有公开分析，唯一的参考是长亭在滴滴安全大会的PPT，信息简略，仅在完成利用后发现一些未注意到的细节。漏洞基于条件竞争，主要影响未修复版本的is_same_as函数，通过特殊方法使其不执行正常逻辑，继续往下执行。
源码分析
展示了is_same_as源码，以及修复前后版本的对比。apport源码位于2..9版本，追踪源码找到更改过的pid进入get_pid_info，贴出源码。
apport为ubuntu程序，用于处理程序崩溃信息，配置文件如/sys/kernel/core_pattern影响生成core文件的命名方式。核心是确定生成的core文件路径，以及内核coredump.c传入的参数。
核心配置文件为/sys/kernel/core_uses_pid，值为1代表生成的core文件带.pid，0代表不带。同时，/proc/sys/kernel/pid_max限制最大pid值，影响核心循环计数。logrotate配置用于日志管理。
在Ubuntu .中，apport与漏洞版本差异大，选择替换整个apport文件。遇到程序不运行问题，可能涉及core_pattern配置。通过日志分析发现入参多了一个%E，删去后程序恢复正常。
逃逸步骤
利用条件竞争绕过分支，首先kill对应pid，然后通过大量fork等待创建进程，占用pid。利用docker内进程路径控制物理机中core生成路径。生成core前检查ulimit -c，限制core文件大小，设置ulimit -c unlimited。
逃逸第二步
通过logrotate定时任务触发执行core中的指令，将想运行的指令写成字符串形式，保存在core文件中。使用logrotate格式编写命令，确保成功执行。手动触发logrotate命令，监听对应端口以获取返回结果。
