TRON漏洞:通过耗尽内存和CPU来引发DoS

简介:
单个请求向/wallet/deploycontract提交几兆数据包,将会引发CPU密集型长解析并占用大约10分钟CPU,同时仍然在堆中保存几兆字节码。发起足够的请求(假设1K-10K取决于可用内存),足以使用所有可用线程来处理传入的HTTP请求,这将填满内存并导致产生拒绝服务。

描述:

*从一个很大的带有大指数的十进制数中获取longValue非常慢。例如new BigDecimal("10000000e100000000").longValue();  这段代码大约需要2-3分钟才能在较新的macbook pro中运行完成。
*/wallet/deploycontract 有6个字段,它们从解析的json对象中获取longValue,即token_id,call_token_value,fee_limit,call_value,consume_user_resource_percent,origin_energy_limit。这意味着单个请求可以使用最多12分钟的线程(假设每次解析2分钟)。
*当一个线程被锁定12分钟/deploycontract时,整个字节码也会放入内存中,这会占用内存并过早地将对象从eden内存空间移动到旧的内存空间
*一旦将对象移动到旧的存储空间,当指针被释放时将很难清理它们,因此GC会在尝试清理之前卡住。请注意gc日志和屏幕截图,其中内存在攻击停止后很长时间内保持在3G状态。

参考:

  • jconsole代表内存,CPU和线程的截图

  • gc log来显示JVM进入无限的GC并且仍然无法释放内存

修复建议

  • JSONObject.parse使用Feature.UseBigDecimal.getMask(); 默认情况下。不使用BigDecimal会解决问题,但可能会在需要BigDecimal的其他地方引入问题。

  • 如果整个字节码一直没有放入内存中那就好了。

影响
使用单台计算机,攻击者可以向所有或51%的SR节点发起DDOS攻击,并使Tron网络无法使用。

图片.png

*文章为作者独立观点,不代表BSCEC立场

转载此文章须经作者同意,并请附上出处(hackerone)及本页链接。原文链接 https://hackerone.com/reports/479144

白帽汇安全研究院转载2019-05-21 15:12:35 hackerone 2112