另外列出 YoY 成長：
看到「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)
其中他們為了支援舊設備 (沒有支援 SNI 的)，決定直接把所有 wildcard 類的 SSL certificate 都包進去 (另外找 DigiCert 處理)：
然後中間提到這個真的頗無奈的，抱怨 SVG 的 XML... XDDD：
Finding and killing these was a little fun because you can’t just search for "http://". Thank you so much W3C for gems like this:
被拿出來當 PR 宣傳了：「Stack Overflow: Helping One Million Developers Exit Vim」。
可以看到 pageview 破一百萬次了 XDDD 而且流量也都很穩定：
然後做交叉分析，看這些卡在 Vim 的人平常是看什麼其他的文章：
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
Stack Overflow 的重要性可以從前陣子 Twitter 上流傳的一張讓大家笑的很開心的圖看出來：
— Jordan Hall (@DivineOmega) February 5, 2016
上次公開 Stack Overflow 的系統架構是 2013 年年底了 (參考當時寫的「Stack Overflow 的現況...」這篇)，這份更新距離上次兩年多了，也有很多可以交叉比較的事情。
You may be wondering about the drastic ASP.Net reduction in processing time compared to 2013 (which was 757 hours) despite 61 million more requests a day. That’s due to both a hardware upgrade in early 2015 as well as a lot of performance tuning inside the applications themselves.
另外他們的 Websockets 也拿來做有趣的事情：
We use websockets to push real-time updates to users such as notifications in the top bar, vote counts, new nav counts, new answers and comments, and a few other bits.
另外他們也發現有些瀏覽器連線已經連 18 個月了 (喂喂)，也許應該去看一下人是不是還活著：
Fun fact: some of those browsers have been open for over 18 months. We’re not sure why. Someone should go check if those developers are still alive.
我猜是 production server 上開瀏覽器查資料後沒關掉，就一直連著...
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!
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」。
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.
Versions of PuTTY and pterm between 0.54 and 0.65 inclusive have a potentially memory-corrupting integer overflow in the handling of the ECH (erase characters) control sequence in the terminal emulator.
不過老問題還是沒解啊，透過 HTTPS (i.e. Certificate authority 架構) 雖然有很多問題，但至少還是個靠稽核制度而建立的安全信任機制，在沒有任何可信任環境下可以當作起點下仍然是最好的方案：「如何安全下載軟體...」。