最近 OpenVPN 的安全性漏洞...

看到「The OpenVPN post-audit bug bonanza」這個只有苦笑啊...

作者在 OpenVPN 經過一連串的安全加強後 (包括 harden 計畫與兩個外部單位的程式碼稽核找到不少問題),決定出手挖看看:

After a hardening of the OpenVPN code (as commissioned by the Dutch intelligence service AIVD) and two recent audits 1 2, I thought it was now time for some real action ;).

然後就挖出不少問題了...

可以看到作者透過 fuzzing 打出一卡車,包含了不少 crash XDDD:(然後有一個是 stack buffer corruption,不知道有沒有機會變成 RCE)

  • Remote server crashes/double-free/memory leaks in certificate processing (CVE-2017-7521)
  • Remote (including MITM) client crash, data leak (CVE-2017-7520)
  • Remote (including MITM) client stack buffer corruption
  • Remote server crash (forced assertion failure) (CVE-2017-7508)
  • Crash mbed TLS/PolarSSL-based server (CVE-2017-7522)
  • Stack buffer overflow if long –tls-cipher is given

iOS 透過無線網路的 RCE...

在「About the security content of iOS 10.3.1」這邊的說明:

Available for: iPhone 5 and later, iPad 4th generation and later, iPod touch 6th generation and later
Impact: An attacker within range may be able to execute arbitrary code on the Wi-Fi chip
Description: A stack buffer overflow was addressed through improved input validation.
CVE-2017-6975: Gal Beniamini of Google Project Zero

這描述看起來就不太妙...

分析現在還有多少不安全的 JavaScript Library 被使用

在「Thou shalt not depend on me: analysing the use of outdated JavaScript libraries on the web」這邊看到對 JavaScript Library 的研究。

jQuery 沒有什麼疑問的還是最大宗,查了一下應該是 CVE-2011-4969 的影響,對 jQuery 1.6、1.6.1、1.6.2 三個版本有影響。

另外也提到了 hosting 的部份,可以看到 Google Hosted Libraries 還是佔有最高的比率。

cURL 接下來的安全性更新...

cURL 的維護老大放話要大家注意接下來的安全性更新:「An alert on the upcoming 7.51.0 release」。

最少 11 個安全性更新:

This release will bundle no less than _eleven_ security advisories and their associated fixes (unless we get more reported in the time we have left).

由於這些 security issue 的特性,會採取不公開的 branch 修正再 merge 回來,再加上這麼大的數量,對於穩定性的衝擊是未知的:

Merging eleven previously non-disclosed branches into master just before a release is not ideal but done so to minimize the security impact on existing users when the problems get known.

所以目前的規劃是會在 release 的 48 個小時前公開 (希望藉由這封信讓有能力的人一起集中來看),藉此來降低衝擊:

My plan is to merge them all into master and push around 48 hours before release, watch the autobuilds closesly, have a few extra coverity scans done and then fix up what's found before the release.

這安全更新的數量好像有點多 orz

Cisco 與 Fortinet 防火牆的 RCE 漏洞

NSA 使用這些漏洞來大量監聽企業的流量:「Leaked Exploits are Legit and Belong to NSA: Cisco, Fortinet and Snowden Docs Confirm」。

Cisco 已經確認這個安全性漏洞了,全系列包括已經停產的 Cisco PIX、上個世代的 Cisco ASA 5500 (但還有些型號還在賣),以及目前主力的 Cisco ASA 5500-X,另外還包括了安全模組系列也中獎:「Cisco Adaptive Security Appliance SNMP Remote Code Execution Vulnerability」。

  • Cisco ASA 5500 Series Adaptive Security Appliances
  • Cisco ASA 5500-X Series Next-Generation Firewalls
  • Cisco ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers
  • Cisco ASA 1000V Cloud Firewall
  • Cisco Adaptive Security Virtual Appliance (ASAv)
  • Cisco Firepower 4100 Series
  • Cisco Firepower 9300 ASA Security Module
  • Cisco Firepower Threat Defense Software
  • Cisco Firewall Services Module (FWSM)*
  • Cisco Industrial Security Appliance 3000
  • Cisco PIX Firewalls*

標星號的是目前已經沒有在維護的產品,這次只確認受到影響,但不會更新:

Cisco Firewall Service Modules and Cisco PIX Firewalls have passed the last day of software support milestone as stated in the published End of Life (EoL) documents. Further investigations into these devices will not be performed, and fixed software will not be made available.

這次 Cisco 的安全性問題是 SNMP 的洞造成的:

Administrators are advised to allow only trusted users to have SNMP access and to monitor affected systems using the snmp-server host command.

這個洞被 NSA 用來寫 exploit 植入系統:

This flaw was included inside two NSA exploits, dubbed EPICBANANA as well as JETPLOW, which is an enhanced version of EPICBANANA, but with better persistence capabilities, Cisco's Omar Santos said in a blog post.

在 NSA 洩漏出來的文件裡可以看到 ace02468bdf13579 這個特殊辨識字串,而在受感染的樣本上也找到了這個痕跡:

而且不只是 Cisco,其他幾家也中獎了,可以參考「The NSA Leak Is Real, Snowden Documents Confirm」這邊更多的資訊 @_@

Libgcrypt 與 GnuPG 的安全性問題

在「Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316]」這邊看到這個歷史悠久的 bug:

Felix Dörre and Vladimir Klebanov from the Karlsruhe Institute of Technology found a bug in the mixing functions of Libgcrypt's random number generator: An attacker who obtains 4640 bits from the RNG can trivially predict the next 160 bits of output. This bug exists since 1998 in all GnuPG and Libgcrypt versions.

就這樣的行為,對於自己用的機器應該是還好... 不過得到 4640 bits 後就可以預測接下來的 160 bits,這個 RNG 有點囧 @_@

官方目前是認為應該還好:

A first analysis on the impact of this bug in GnuPG shows that existing RSA keys are not weakened. For DSA and Elgamal keys it is also unlikely that the private key can be predicted from other public information. This needs more research and I would suggest _not to_ overhasty revoke keys.

不過如果你有絕對的安全需求的話還是可以考慮 revoke 再重新生一把...

OpenSSL 的 DSA 被 Side-channel attack 打爆

在「Make Sure DSA Signing Exponentiations Really are Constant-Time」這篇文章裡面,直接透過 end-to-end 的 timing attack 打爆 (也就是透過 internet 觀察攻擊),而不需要在同一台機器上對 cache 之類的區域攻擊:

A unique feature of our work is that we target common cryptographic protocols. Previous works that demonstrate cache-timing key-recovery attack only target the cryptographic primitives, ignoring potential cache noise from the protocol implementation. In contrast, we present end-to-end attacks on two common cryptographic protocols: SSH and TLS. We are, therefore, the first to demonstrate that cache-timing attacks are a threat not only when executing the cryptographic primitives but also in the presence of the cache activity of the whole protocol suite.

而且次數相當的少,就可以 key recovery:

260 SSH-2 handshakes to extract a 1024/160-bit DSA host key from an OpenSSH server, and 580 TLS 1.2 handshakes to extract a 2048/256-bit DSA key from an stunnel server.

CVE 編號為 CVE-2016-2178OpenSSL 全系列 (包括 fork 出去的版本) 與 OpenSSH 只要是 DSA 的實作都中獎...

最近的兩個安全性漏洞:OpenSSL、ImageMagick

OpenSSL 的安全性漏洞公告:「OpenSSL Security Advisory [3rd May 2016]」。ImageMagick 的安全性漏洞說明頁:「ImageTragick」。

CVE-2016-2107 是修 Lucky 13 問題時沒修好造成的:

This issue was introduced as part of the fix for Lucky 13 padding attack (CVE-2013-0169). The padding check was rewritten to be in constant time by making sure that always the same bytes are read and compared against either the MAC or padding bytes. But it no longer checked that there was enough data to have both the MAC and padding bytes.

CVE-2016-2108 是組合技,從兩個「看似無害」的安全性問題開始:

This vulnerability is a combination of two bugs, neither of which individually has security impact.

The first bug (mishandling of negative zero integers) was reported to OpenSSL by Huzaifa Sidhpurwala (Red Hat) and independently by Hanno Böck in April 2015. The second issue (mishandling of large universal tags) was found using libFuzzer, and reported on the public issue tracker on March 1st 2016.

然後 Google 的人找出來可以打穿:

The fact that these two issues combined present a security vulnerability was reported by David Benjamin (Google) on March 31st 2016.

另外隔壁棚的 ImageMagick 安全性問題是個慘劇,是個 RCE 等級的,而且 exploit 已經在外面跑了:

One of the vulnerabilities can lead to remote code execution (RCE) if you process user submitted images. The exploit for this vulnerability is being used in the wild.

Git 的安全性問題

在「Remote Code Execution in all git versions (client + server) < 2.7.1: CVE-2016-2324, CVE-2016‑2315」這邊看到歡樂的 CVE-2016-2315CVE-2016-2324,屬於 RCE 類漏洞。

Git 2.7.1 之前的所有版本都有問題,看起來由於問題過於大條,在 2016/02/06 發表的「Git v2.7.1 Release Notes」沒有標出這兩個 CVE,讓所有 vendor 有時間升級。

不過看起來 GitLab 不在被通知的 vendor 裡面,很無奈的在 CVE 公開後馬上推出新版,需要升級到最新版本:「GitLab 8.5.7 Released」。

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」。