苹果LLVM编译器栈溢出

7月15日，美国CERT/CC发布编号为VU#129209的漏洞通告：LLVM编译器后端的一个bug导致某些情况下在ARM平台上针对传统栈溢出漏洞而设计的Stack cookie防护机制失效，详细信息参见: https://kb.cert.org/vuls/id/129209/ 1996年 Aleph One在Phrack杂志上发表了题为《Smashing The Stack For Fun And Profit》的技术文章，掀开了针对传栈溢出漏洞利用的大幕。由于当时软件中栈溢出问题普遍存在，一时间腥风血雨，不知多少软件折在栈溢出漏洞里；很长时间内有些漏洞扫描器的漏洞判定规则就是查看strcpy/memcpy等函数中目的地址是否在栈上。如何阻断栈溢出漏洞攻击的重担落在了编译器身上，Stack cookie机制应运而生：在编译阶段，在局部变量和函数返回地址中间，插入一个cookie变量，函数返回前，通过比对栈上cookie和堆上的副本就可以判断返回地址是否被连续内存copy操作破坏。由于stack cookie可忽略的性能影响和有效性，该机制很快被所有主流编译器采纳。 随着stack cookie以及DEP/ALSR等防护机制的不断应用，栈溢出漏洞渐渐退出了历史舞台。2012年出版的《iOS Hacker’s Handbook》一书中，作者直言不讳的说，“We decided not to cover stack-related bugs because, albeit still present in some software, they are in general less likely to be exploitable…”。一句话概括，栈溢出漏洞很难利用。 时间来到2019年。我们在审计FaceTime的过程中，发现了一个经典的栈溢出漏洞：调用memcp从堆复制数据到栈buffer，长度完全可控。令我们意外的是，构造POC后我们在崩溃日志中发现PC完全受控，stack cookie防护完全失效。进一步分析后，我们发现漏洞所在函数的stack cookie并没有被放置于局部变量和返回地址之间，而是在局部变量之后，这就导致栈溢出发生的时候，根本不会影响到stack cookie。栈溢出漏洞我们会在BlackHat USA上做详细分析。但stack cookie为何失效更令我们感到好奇。 除了这个函数，我们在不同模块中都发现了同样的错误：stack cookie没有放置在局部变量和返回地址之间。我们意识到苹果的编译环节出了问题。苹果是LLVM编译器最大推手，如果苹果的编译器出了问题，意味着LLVM很可能也出了问题。考虑到LLVM的使用范围，我们及时把问题提交给苹果。最终在苹果Security Team的分析和推进下，LLVM上游很快发布了补丁（O网页链接）。 这个LLVM编译器的bug影响了多少应用我们不得而知，影响将持续多久也不得而知。历史总是充满了戏剧性。在人们都以为栈溢出已经退出了历史舞台，它就这样华丽的回归了。 出处来源：INT80（https://weibo.com/int80 ）