0x01背景：
4.2.8p9之前的NTP中的read_mru_list函数允许远程攻击者通过精心设计的mrulist查询导致拒绝服务（崩溃）
0x02复现：
Kali启动服务充当server
Win上执行poc
然后kali上的ntp服务就报错奔溃了
0x03源码分析：
看到focus的reference
漏洞出现在read_mru_list中
在4000-4019可以看到它把mrulist数据包中各字段输入in_parms中，并且用到了sizeof()
4006行sizeof处理的nonce_text在其定义时为
即：nonce_text为6字节
传入变量后
定位到4041行可以看到ctl_getitem（），和在处理变量时使用的estrdup（）
先看ctl_getitem,功能是处理解码后数据包中的数据
在part one 中主要是验证包状态
在3111行的for循环中，cp赋初值为reqpt,而cp = reqend时或出出现,则终止，而3103的while循环中我们知道出现，或者空的时候，reqpt++.3106行可以看出，程序正常执行时reqpt<reqend的。所以结合以上分析，可以知道for循环出现,则终止，出现=则赋值。如果没有出现=进行赋值，则tp字段就会一直为null
再看estrdup
从源码中可以看到estrdup中包含了strdup（）
而strdup又包含了strlen
由于strlen参数不能是null（如果是null，则segmentation faults）
所以如果val引入了空指针 ，则会触发漏洞
如上图所示，nonce前面的一个字节正常格式原本应该是=（/x3d）的，漏洞发现者把它置为6了(16进制就是\x36),所以才会导致漏洞产生
0x04
Exp结合流量分析：
exp比较简单，主要还是关注在socket建立之后发送的buffer，buffer中就是构造的payload
exp给出的payload是以16进制表示的
\x16\x0a\x00\x10\x00\x00\x00\x00\x00\x00\x00\x36\x6e\x6f\x6e\x63\x65\x2c\x20\x6c\x61\x64\x64\x72\x3d\x5b\x5d\x3a\x48\x72\x61\x67\x73\x3d\x33\x32\x2c\x20\x6c\x61\x64\x64\x72\x3d\x5b\x5d\x3a\x57\x4f\x50\x00\x32\x2c\x20\x6c\x61\x64\x64\x72\x3d\x5b\x5d\x3a\x57\x4f\x50\x00\x00
转成文本得部分乱码
事实上，这就是wireshark中解析出来的ntp的报文（灰底部分）
对照着ntp协议的格式
第一个字节是16，转换成二进制就是00010110，根据上图，第0、1比特代表的是LI（Leap Indicator），当这个值为11的时候是告警状态，代表时间同步出现问题，其他则不处理，这里是00；随后第2、3、4比特是010，代表的是版本，之后的5、6、7比特110代表的是Mode，这里也就是6，代表着mrulist特性处理，而这次漏洞，确实就是由于mrulist导致的。