CentOS 將會變成 CentOS Stream

讓不少團隊要炸的消息,CentOS 將會被消滅變成 CentOS Stream:「CentOS Project shifts focus to CentOS Stream」與「CentOS Stream: Building an innovative future for enterprise Linux」。

很多團隊用 CentOS 的主要原因就是因為他基本上就是個 RHEL 重新打包的版本,一來更新速度沒有很快 (所以穩定不少,跑得好好的就不要動他最穩...),二來很多商用軟體都可以在支援 RHEL 時「順便」支援 CentOS。

再來是考慮到他有超級長的支援期,像是 2011 年推出的 CentOS 6 到上個月月底 (2020/11/30) 才終止支援,相較於 Ubuntu LTS 提供的五年來說長很多。

所以兩邊都有選擇的理由 (以及族群),一邊是追求穩定性,一邊是有新技術的需求。

不過 IBM 在 2018 年收購 Red Hat 後看起來對這件事情有很不一樣的看法:決定要收掉 CentOS,然後借屍還魂叫做 CentOS Stream,上面開始會有與 RHEL 不同的東西。

When CentOS Linux 8 (the rebuild of RHEL8) ends, your best option will be to migrate to CentOS Stream 8, which is a small delta from CentOS Linux 8, and has regular updates like traditional CentOS Linux releases.

所以接下來還有支援的兩個版本,分別是 2014 年出的 CentOS 7,將照原訂的 10 年計畫支援到 2024/06/30,以及 2019 年出的 CentOS 8,就只會支援到 2021/12/31 了。

翻了一下 Hacker News 上的討論,先不講幹聲一片的問題,看起來原來建立 CentOS 的 Gregory Kurtzer 決定出來再幹一次:「Original CentOS founder intends to create new fork of RHEL (rockylinux.org)」。

來看看後續社群會怎麼玩吧...

AWS 推出可以在 Red Hat Enterprise Linux 上跑 Microsoft SQL Server 的 AMI

自從 Microsoft SQL Server 宣佈可以在 Linux 上跑後 (參考「Microsoft SQL Server 出 Linux 版...」),就沒看到什麼 Linux 上跑 SQL Server 的消息了... 結果在這波 AWS 的活動上推出了 RHEL 上跑 SQL Server 的消息:「Amazon EC2 now offers SQL Server 2017 with Red Hat Enterprise Linux 7.4」。

SQL Server 2017 is now available for Amazon EC2 instances running Red Hat Enterprise Linux (RHEL) 7.4 as an Amazon Machine Image (AMI) from the AWS Marketplace. With this release, you can now launch RHEL instances on-demand using SQL Server 2017 Enterprise License Included AMIs without having to bring your own license. SQL Server 2017 on RHEL 7.4 AMI is available in all public AWS regions starting today.

這個消息看到的時候嚇了一跳...

把主力手機從 iPhone 換到 Android

上次主力用 Android 應該是 HTC Desire 時代了,那個時候跑得是 2.2。

總算把 LG G2 (D802) 刷完機器了 (刷了半年,每次都卡關 XDDD),這次刷了 CyanogenModOpen GApps,儘量都用 command line 來刷。

adb devices # 看裝置順便打 RSA public key 進去
adb shell # 進去後可以 ls/su 看一看
adb push filename.zip /sdcard/
adb reboot recovery

Android Marshmallow (6.0) 另外多了對權限的管理,這也是想刷到 6.0 的原因之一,使用者可以隨時 revoke 掉某些權限 (沒有處理好的會 crash XD):

Android Marshmallow introduces a redesigned application permission model: there are now only eight permission categories, and applications are no longer automatically granted all of their specified permissions at installation time. An opt-in system is now used, in which users are prompted to grant or deny individual permissions (such as the ability to access the camera or microphone) to an application when they are needed for the first time. Applications remember the grants, which can be revoked by the user at any time.

其他安裝的流程主要都是苦工了,尤其是 2FA 是少數為了安全性只能一個一個換的東西 (不提供 export,都是用手機提供的 HSM 避免被盜走),剛好趁機會把自己與公司用到的 2FA 帳號分開。

Android 上的 Google Authenticator 不怎麼好用 (不能調整位置,另外不希望隨時都給密碼),測了測 Red Hat 出的 FreeOTP Authenticator 算是比較好用的,就把 FreeOTP Authenticator 拿來給個人用,Google Authenticator 拿來給公司的帳號用。

繼續熟悉現在的 Android 環境,應該會有一陣子不習慣...

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