Home » Posts tagged "issue" (Page 2)

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

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 再重新生一把...

LinkedIn 在 2012 年的密碼外洩比想像中嚴重,超過一億筆帳號密碼洩漏

在「Another Day, Another Hack: 117 Million LinkedIn Emails And Passwords」這邊看到 LinkedIn 在 2012 年的帳號密碼外洩情況比想像中嚴重許多,當時大家認為只有 650 萬筆資料洩漏,但實際上在 2016 年的現在被確認有 1.17 億筆。

官方也確認 2016 的這份洩漏是正確的,兩份公告在:

很多人都收到 password reset 信件了...

IPv6 表示法的包袱

IPv6 address 表示法的確有不少問題,說「包袱」是因為應該是很難改了。

在「The IPv6 Numeric IP Format is a Serious Usability Problem」這篇文章裡作者討論 IPv6 address 表示法的問題,像是因為用 colon 切割造會跟 url 裡的 port 混淆,於是引入了 bracket 的 workaround:

An IPv4 URL of the form indicates that HTTP should be used to access a service at port 1234. But what does http://dead:beef::1:1234/ mean? To fix the ambiguity, brackets were introduced. Now you have to type http://[dead:beef::1]:1234/.

Address Shortening Obfuscation 這邊講的就有點過火了,不過的確是不好讀,一眼看過去不是很容易切開一個 colon 與兩個 colon 的部份。

作者有提出一些建議方法,不過看起來只是 murmuring... XD

GitHub 對 Open Source Community 請願的回應

大約一個多月前 (2016 年一月 15 日),一群用 GitHub 發展 Open Source 軟體的人對 GitHub 提出請願,要求重視 Open Source Community 在 GitHub 平台上遇到的問題:「An open letter to GitHub from the maintainers of open source projects」。

這個請願在卡了將近一個月後,陸陸續續有相當多要搬出 GitHub 的討論,像是 eslint 就直接在 GitHub 開了 issue,討論搬出 GitHub 會遇到的問題以及可能的解決方法:「Investigate switching away from GitHub」。

在二月 13 日的時候,GitHub 透過 pull request 發出回應說「我們在處理了」,但也沒講正在處理什麼,看起來就是個很 PR 的回應:「Dear Open Source Maintainers」。

直到昨天,三個主要的請願中關於 issue 範本的問題 (也就是下面這段) 總算有進展了:

Issues are often filed missing crucial information like reproduction steps or version tested. We’d like issues to gain custom fields, along with a mechanism (such as a mandatory issue template, perhaps powered by a newissue.md in root as a likely-simple solution) for ensuring they are filled out in every issue.

為了解決使用者在開 issue 時有時會忘記給出完整的環境資訊 (以及其他有用的資料),GitHub 推出了新的功能,在開 issue 或 pull request 時利用 template 讓使用者有個範本可以照著填寫,同時 template 也支援 Markdown,讓填寫的方式會更豐富一些:「Issue and Pull Request templates」。

這總算開始有進展了。但也開始感覺到 GitHub 的動作已經開始慢下來了...

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

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,對效能的影響還是要測試過才知道...