CVE-2019-5768
gdb交叉编译
Gdb / buildroot 交叉编译。
使用buildroot 编译低版本的mips gdb 的时候，gdb源码需要手动打补丁，主要是uClibc库的问题。
链接：
https://git.busybox.net/uClibc/commit/?id=2da958760f798224065508431787e3a83b7fe2ae
cve-2017-7269
已经搞定了弹计算器。
以后就可以定制自己的shellcode了。
回弹shell的c代码也倒是写好了，慢慢转成shellcode就行。
回弹cmd的shellcode坑有点多，写倒是写好了。感觉自己写代码的能力真的不够
很多小细节的问题忽略就会出错。
配合火狐的洞测试了一下，效果可以。测试了火狐的沙盒，当等级为3的时候，也能够回弹cmd，执行命令，往system32里写文件这些。
但是沙盒等级高于3就不行了。
CVE-2019-8014
图补上了，顺便把自己写的exp放上了：https://github.com/f01965/CVE-2019-8014
写的比较乱，图也没上完。空了补。
CVE-2019-8014 分析记录
xmm浮点寄存器特殊情况
Win 10 x64下的shellcode 在执行的时候，当遇到浮点浮点寄存器的操作：
movaps xmmword ptr [rsp+ xxx ],xmm
movaps xmmword ptr [rsp+ xxx ],xmm1
如下如：
这里如果执行失败，那么错误的关键就是 rsp+500h 的地址不能被 16 整除。
因此代码会崩溃在这里。
修复的关键就是，需要让 rsp+500h 的地址能够被 16整除。
我们最初提供的shellcode ，在编译器生成之后会出现如下的代码：
这是shellcode 最开始的部分，它执行了这几个Push 操作之后， rsp 的地址就不能被16整除了。所以，删点这几个push 操作，shellcode就正常了。
下图红框部分，就对应这几个push指令。删除即可。
ISS6 webdav（CVE-2017-7269）
环境：windows server 2003
装上IIS ，开启webdav
我们这里漏洞分析从poc开始，分析漏洞出现的原因。
漏洞成因分析
1.开启IE访问LocalHost ，用windbg 挂载w3wp.exe
2.利用python脚步，创建tcp链接，发送数据，让w3wp崩溃。
自己写代码，让 Sstr 可变，这样我们就能得到让其的崩溃的字符串的长度。
3.在崩溃点，上层打下断点。然后用 ba 数据断点，快速定位到崩溃的位置数据来自何处。
回溯调用栈空间，把断点打在 sub_673F5326，然后进行单步调试，遇到call函数的数据就注意esp 中传入的参数。
走到如下位置的时候，可以看到，由于输入的数据过长，导致 0x12ff90c 位置的低4位被0000 覆盖了
正常的情况下，0x12ff90c 应该存放 0x012ff804 ，被溢出数据的覆盖为 0x012f0000
接着
push [ebp-0x328] ebp-0x328 = 0x012f0000 ( 原本应该是 0x012ff804)
call edi ，edi = msvcrt!wcslen (77ba8ef2) 函数。
把 [ebp-0x328] 当作数据存放的指针，进行数据长度的计算。由于 0x012f0000 是被溢出数据覆盖了，因而发生了错误。
firefox数据结构
SpiderMonkey内部每个对象都与一个由一个JSClass对象组成的组相关联。该JSClass含有的元素ClassOps，其中包含函数指针控制属性的方式添加，删除等。如果我们能够劫持这个函数指针，然后执行代码是一个完成的工作。
JIT 利用过程：
CVE-2019-9813
该漏洞参加了 2019 pwn2own 攻下firefox（另一个CVE-2019-9810），POC 有2个获取途径：