小编给大家分享一下服务器中意外内存泄漏的示例分析，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
创新互联是一家专注网站建设、网络营销策划、微信小程序、电子商务建设、网络推广、移动互联开发、研究、服务为一体的技术型公司。公司成立十年以来，已经为成百上千家成都混凝土搅拌罐各业的企业公司提供互联网服务。现在，服务的成百上千家客户与我们一路同行，见证我们的成长；未来，我们一起分享成功的喜悦。
我们的路由器使用的是一块Macronix MX15L12835FMI闪存芯片（16针脚SOP）：
首先，我需要观察芯片的常规操作。在研究过程中，我发现它的闪存并没有得到充分使用，只有设备在启动（或加载整个操作系统）时或在使用Web管理面板时会使用到闪存。闪存芯片似乎使用的是Single API模式，其常规读取命令如下所示：
命令开头为一个05 FF命令，根据数据表提供的信息，这条命令可以读取出寄存器的状态信息。我最初的目的是对闪存读取命令进行篡改，并用它来从硬盘中读取数据。
考虑到SPI命令是与时钟信号同步的，那我的攻击同样可以跟同一个时钟信号同步：我可以记录下时钟上升沿信号的数量，并在特定数量的时钟信号下将闪存芯片的15号针脚接地，然后修改闪存的读取命令并用它来读取其他信息。放大时钟信号后我们可以看到，数据只会在时钟信号的下降沿发生变化，所以我们的攻击应该是有效的。
首先我们进入到设备的串行控制台中，然后使用命令cat /dev/mtdblock0来触发闪存的读取命令。该命令的原始状态如下所示：
为了方便进行对比，所以我运行了cat /dev/mtdblock2：
接下来，我连接了一个晶体管和一个FPGA，FPGA可以读取时钟信号并控制晶体管的开关，接地针脚15暂时等待几个时钟周期，并让其中的一个读取指令地址失效：
我还专门编写了一个脚本来让程序等待一定的时钟周期，并修改闪存的读取操作，然后运行cat /dev/mtdblock2并通过示波器来监控闪存的命令执行情况：
如果你仔细看的话，你就会发现右边是原始闪存读取操作的残余部分（原始命令/dev/mtdblock2为03 01 00 00），我们可以通过运行cat /dev/mtdblock2命令来验证我们的发现：
需要注意的是，命令确实成功执行了，/dev/mtdblock2的第一个数据块跟之前/dev/mtdblock0的一样，表示我们的操作已经成功了。
现在，我们就可以用这种方法来对Web服务器接口进行攻击了，如果我可以让硬盘中的某个资源加载失败，理论上来说我就可以让它来读取任何我想要读取的内容了，比如说通过Web请求来获取到固件文件等等。
但是，我很快就遇到了如下所示的问题：
虽然我可以从物理闪存中读取任意区块，但我无法保证数据可以正确解压。虽然Web服务器似乎还可以正常工作，但是其中的一个图片已经无法正确加载了。用Burp进行分析后，我很快就找到了“罪魁祸首”：
这是一个针对/wireless_1.gif的有效请求的一条响应数据，我知道这是一个无效的GIF文件，但我并不知道它到底是什么，我猜测它要么来自于Web服务器的内存，或者是磁盘中的数据块。
为了进行测试，我对整个Web应用程序进行了分析，然后发送了一条新的/wireless_1.gif请求：
神奇的是，这个gif文件竟然自己发生了变化，而且我也没观察到其他的SPI流量生成，这表示我成功实现了内存泄漏（很可能是一个内存用后释放漏洞），只不过唯一的遗憾是它并非目标系统的密码文件。
以上是“服务器中意外内存泄漏的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联行业资讯频道！
