CVE-2015-7547:getaddrinfo() 的 RCE (Remote Code Execution) 慘案

Google 寫了一篇關於 CVE-2015-7547 的安全性問題:「CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow」。

Google 的工程師在找 OpenSSH 連到某台特定主機就會 segfault 的通靈過程中,發現問題不在 OpenSSH,而是在更底層的 glibc 導致 segfault:

Recently a Google engineer noticed that their SSH client segfaulted every time they tried to connect to a specific host. That engineer filed a ticket to investigate the behavior and after an intense investigation we discovered the issue lay in glibc and not in SSH as we were expecting.

由於等級到了 glibc 這種每台 Linux 都有裝的情況,在不經意的情況下發生 segfault,表示在刻意攻擊的情況下可能會很糟糕,所以 Google 投入了人力研究,想知道這個漏洞到底可以做到什麼程度:

Thanks to this engineer’s keen observation, we were able determine that the issue could result in remote code execution. We immediately began an in-depth analysis of the issue to determine whether it could be exploited, and possible fixes. We saw this as a challenge, and after some intense hacking sessions, we were able to craft a full working exploit!

在研究過程中 Google 發現 Red Hat 的人也在研究同樣的問題:「(CVE-2015-7547) - In send_dg, the recvfrom function is NOT always using the buffer size of a newly created buffer (CVE-2015-7547)」:

In the course of our investigation, and to our surprise, we learned that the glibc maintainers had previously been alerted of the issue via their bug tracker in July, 2015. (bug). We couldn't immediately tell whether the bug fix was underway, so we worked hard to make sure we understood the issue and then reached out to the glibc maintainers. To our delight, Florian Weimer and Carlos O’Donell of Red Hat had also been studying the bug’s impact, albeit completely independently! Due to the sensitive nature of the issue, the investigation, patch creation, and regression tests performed primarily by Florian and Carlos had continued “off-bug.”

攻擊本身需要繞過反制機制 (像是 ASLR),但仍然是可行的,Google 的人已經成功寫出 exploit code:

Remote code execution is possible, but not straightforward. It requires bypassing the security mitigations present on the system, such as ASLR. We will not release our exploit code, but a non-weaponized Proof of Concept has been made available simultaneously with this blog post.

技術細節在 Google 的文章裡也有提到,buffer 大小固定為 2048 bytes,但取得時有可能超過 2048 bytes,於是造成 buffer overflow:

glibc reserves 2048 bytes in the stack through alloca() for the DNS answer at _nss_dns_gethostbyname4_r() for hosting responses to a DNS query.

Later on, at send_dg() and send_vc(), if the response is larger than 2048 bytes, a new buffer is allocated from the heap and all the information (buffer pointer, new buffer size and response size) is updated.

另外 glibc 官方的 mailing list 上也有說明:「[PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overflow」。

libpng 漏洞...

libpng 的安全性問題,CVE-2015-8126

Multiple buffer overflows in the (1) png_set_PLTE and (2) png_get_PLTE functions in libpng before 1.0.64, 1.1.x and 1.2.x before 1.2.54, 1.3.x and 1.4.x before 1.4.17, 1.5.x before 1.5.24, and 1.6.x before 1.6.19 allow remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a small bit-depth value in an IHDR (aka image header) chunk in a PNG image.

一堆軟體要更新啊...

Adobe 的 Typekit 推廣 HTTPS only

AdobeTypekit 宣佈之後的 embed code 預設就會是 HTTPS only:「Font loading update: All HTTPS, all the time」。

主要的原因是出自於最近發現的安全問題,攻擊者可以藉由字型處理的 security issue 攻擊,而導入 HTTPS 後可以降低這部分的風險:

We’ve made this change as a response to the recent vulnerabilities and exploits in the OpenType and TrueType font formats. A malicious attacker could use these vulnerabilities to modify a Typekit font while it is being transmitted from our servers to your browser. Serving fonts (and other resources) over HTTPS ensures that the communication channel between your browser and our servers is not compromised and fonts are delivered in a secure way.

就目前看起來,use.typekit.net 還是使用 EdgeCast 的 CDN 服務,在 HTTPS 上還是沒有 SPDY 或是 HTTP/2,對效能的影響還是要測試過才知道...

Hacking Team 購買 Flash Exploit 的信件

前情提要:「Hacking Team 被黑而洩漏出來的資料」。

在「How a Russian hacker made $45,000 selling a 0-day Flash exploit to Hacking Team」這邊提到了 Hacking Team 被黑而洩漏出來的信件,透漏了俄羅斯的人賣 Flash Exploit 給 Hacking Team 的過程。

從內容就可以看出不同的賣法,包括「首次」與「獨家」都是可以談的條件:

1) The price is US$45,000.00 for the non-exclusive sale of any special discount for the "first" deal together will be greatly appreciated :)

然後有些東西是另外加密通信的:

The two men then exchanged PGP keys, which they used to exchange a number of encrypted messages, presumably one including how Toporov would like to be paid.

然後還有 invoice:

而買了幾個建立關係後,後面還會有 discount:

Now your discount on the next buy is -5k and -10k is for a third bug.

最近應該會有不少人跳下去解讀洩漏出來的資料...

Hacking Team 被黑而洩漏出來的資料

這幾天資安領域最熱鬧的消息莫過於 Hacking Team 被黑之後洩漏出來的 400GB+ 的資料:「Hacking Team hacked, attackers claim 400GB in dumped data」、「Hacking Team hacked, attackers claim 400GB in dumped data」。

洩漏的資料可以在 GitHub 上的「hackedteam」取得,或是透過 BitTorrent 取得 (i.e. 51603bff88e0a1b3bad3962614978929c9d26955)。

烏雲上的「人手一份核武器 - Hacking Team 泄露(开源)资料导览手册」這篇寫得很完整了,現在的系統已經整合到這樣,於是要對這個人做任何事情都很容易:

也因為這次的 leak 而使得不少軟體在修正 0day exploit...

好精緻的核武...

在瀏覽器上面用 JavaScript 進行 Side-channel attack

用 JavaScript 就可以攻擊 L3 cache,進而取得資料:「JavaScript CPU cache snooper tells crooks EVERYTHING you do online」。

論文出自「The Spy in the Sandbox – Practical Cache Attacks in Javascript」(PDF) 這篇。

不需要任何外掛或 exploit,就純粹是利用 cache 反應時間的 side-channel attack。另外由於 AMD 的 cache 架構不同,這次的攻擊實作僅對 Intel 有效:

The Intel cache micro-architecture isinclusive– all elements in the L1 cache must also exist in the L2 and L3 caches. Conversely, if a memory element is evicted fromthe L3 cache, it is also immediately evicted from the L2 and L1 cache. It should be noted that the AMD cachemicro-architecture is exclusive, and thus the attacks described in this report are not immediately applicable tothat platform.

這次的攻擊方法真變態...

Mac OS X 的安全性漏洞:蘋果沒打算修 10.9 以下的版本...

在「Hidden backdoor API to root privileges in Apple OS X」這邊揭露了這個漏洞 (接近於後門的設計)。

10.10.3 修正了這個問題,但沒打算修 10.7.x 到 10.9.x 的版本:

Apple has now released OS X 10.10.3 where the issue is resolved. OS X 10.9.x and older remain vulnerable, since Apple decided not to patch these versions. We recommend that all users upgrade to 10.10.3.

從 2014 年十月發現回報,2015 年一月蘋果建立 CVE-2015-1130,到 2015 年四月才正式修復 10.10.x 的部份:「About the security content of OS X Yosemite v10.10.3 and Security Update 2015-004」。

靠靠,我不想升到 10.10 啊...

Rowhammer Bug:攻擊記憶體的值...

GoogleProject Zero 實做 Rowhammer Bug:「Exploiting the DRAM rowhammer bug to gain kernel privileges」。

開頭就很科幻:

“Rowhammer” is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows.

然後就提到實做了:

We tested a selection of laptops and found that a subset of them exhibited the problem. We built two working privilege escalation exploits that use this effect.

給出了 NaCl sandbox escape 與 Kernel privilege escalation 兩種方式。

這頭快炸了...

用 Shodan 掃台...

在「Using Shodan from the Command-Line」這邊看到跟資安有關的工具,然後跑回去研究 Shodan 這個工具。

這是預先掃好的資料庫啊啊啊~

而且還包括了目前已經有的 exploit 可以攻擊的對象?喂喂... (超開心?)

然後 port:22 的結果 (需要登入才能查詢),左邊列出全世界的數量排名,台灣居然是第三名?

一堆 Dropbear 看起來是一堆 WAN interface 對 internet 公開的分享器?我看到這些資料後才能理解,為什麼台灣在全世界跳板比率這麼高 XDDD

然後一如預期的,EC2 一堆機器開放全世界存取 ssh XDDDD

OpenSSL 的 Heartbleed 漏洞不限於 Server,也包含 Client...

Heartbleed 是惡意的 client 可以利用 OpenSSLHeartbeat Extension 漏洞取得 server 的機敏資訊。

而在「Testing for "reverse" Heartbleed」這篇說明 (並且 PoC) 這組漏洞也適用於反向的操作,也就是惡意的 server 可以取得 client 的資訊。

exploit 相較起來比正向的難一些,但還是可行並且成功做出來了。文章裡有描述怎麼實做的...

換句話說,反正手上的 OpenSSL 都趕快升級...