繞過 Screensaver Lock 的有趣話題...

Hacker News Daily 上看到「Screensaver lock by-pass via the virtual keyboard」這篇,裡面這邊題到了 screensaver lock 的有趣話題。

先講嚴肅一點的,這個 bug 被編號為 CVE-2020-25712,問題出在 xorg-x11-server 上:

A flaw was found in xorg-x11-server before 1.20.10. A heap-buffer overflow in XkbSetDeviceInfo may lead to a privilege escalation vulnerability. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

比較有趣的事情是,這個 bug 是小朋友在亂玩時拉出 virtual keyboard 觸發的:

A few weeks ago, my kids wanted to hack my linux desktop, so they typed and clicked everywhere, while I was standing behind them looking at them play... when the screensaver core dumped and they actually hacked their way in! wow, those little hackers...

然後他說他自己搞不出來:

I tried to recreate the crash on my own with no success, maybe because it required more than 4 little hands typing and using the mouse on the virtual keyboard.

另外一個人也說他家小朋友也弄出 segfault 了:

My kids came upon a similar cinnamon-screensaver segfault! I've emailed details of how to reproduce the problem to root@linuxmint.com.

小朋友超強 XDDD

Zoom 的浮水印功能

Hacker News Daily 上看到 The Intercept 介紹了 Zoom 的浮水印功能,以及如果你要洩密的話要如何自保:「What You Should Know Before Leaking a Zoom Meeting」。這篇文章主要不是談 Zoom 之前被討論的那些問題,而就 Zoom 的浮水印功能來討論。

Zoom 支援 video watchmark 與 audio watchmark:

依照描述的兩個方式,看起來都不難破,但主要是要提醒記者,如果要放出線人提供的 Zoom 錄音或是錄影,要注意到裡面是否有 watchmark 導致線人的資訊被洩漏:

Journalists should also be wary of publishing raw audio leaked from Zoom meetings, particularly if the source is not sure whether audio watermarking was enabled or not.

翻了一下 GitHub 沒搜到有工具可以處理,這點可能要等人發展出來...

Nmap 變成非 Open Source Software

在 RSS reader 上看到「A license change for Nmap」這篇,雖然看不到內容,但標題已經先把重點講出來了 (雖然在 Hacker News 上找一下就有連結了),看起來 Nmap 的軟體授權有改過,查了一下是在去年十月出版的 7.90 發生的,不過最近突然被炒熱了起來:「Nmap 7.90 Released! First release since August 2019.」。

We also did some long-needed license cleanup and gave the license a name (Nmap Public Source License) to avoid the previous confusion of Nmap being under "GPLv2 with various clarifications and exceptions". The NPSL is still based on the GPLv2, but brings in terms from some other popular open source licenses. See https://nmap.org/npsl

看到這種自我宣稱的就超可疑,而翻了一下 NPSL 裡面的限制,看起來就不怎麼符合 open source license 的定義,在「Is nmap's custom NPSL license free?」這邊的說明算是很客氣了,都是掛上「probably」,不過大家自己讀過以後應該就會知道問題了...

目前開槍的應該就是 Fedora 了,Fedora 在 Nmap Public Source License (NPSL) Version 0.92 - devel-announce - Fedora Mailing-Lists 這邊決定把 NPSL 列為 bad license,並且在 Fedora 裡面禁用。

Debian 目前則是在「#972216 - nmap: New NPSL 0.92 license likely non-free - Debian Bug report logs」這邊也有類似的討論,不過目前看起來就還在討論,沒有動手。

Gentoo 跟情況跟 Debian 也類似,在「Add NPSL (nmap license) to MISC_FREE」這邊討論中。

看起來這幾天應該會有進展,沒意外的話應該是會被封殺,裡面的條款把 installer 之類的程式也都限制進去了,直接影響到 Linux 平台的各種工具 (像是 apt/dnf/yum)。

該拉個折凳,買個爆米花來等著看了...

Firefox 也打算淘汰 ESNI,改推 ECH

Firefox 也打算放棄 ESNI,改推 ECH 了:「Encrypted Client Hello: the future of ESNI in Firefox」。

目前的 85 版 (目前的 beta) 支援了 ECH draft-08,想要玩看看的人就可以測試了:

Firefox 85 replaces ESNI with ECH draft-08, and another update to draft-09 (which is targeted for wider interoperability testing and deployment) is forthcoming.

另外一個要看的當然就是 Google 家的 Chromium 了,不過這個協定對 Google 的誘因應該是超大,有機會直接穿入中國市場... 只是不知道會不會自己搞一套 protocol。

Visa 網站上面的 Opt-Out 功能被拿來玩 Timing Attack...

Hacker News Daily 上看到「Visa Advertising Solutions (VAS) Opt Out (visa.com)」這篇講 Visa 的 Visa Advertising Solutions (VAS) Opt Out,本來以為是在討論企業賣資料的問題 (下面的討論的確是有在討論這個),但最上面的討論居然是在討論 timing attack,像是這篇:

morpheuskafka 2 days ago [–]

Checked and the Mastercard one someone posted below doesn't seem to be vulnerable to this. My real card number and a dummy mastercard number with valid prefix and check digit both returned a 200 OK in around 1.01s. A random 16digit number without valid check digit returned 400 Bad Request in about 800ms. Decided to check that one since they have a completely useless machine-readable catchpa.

For Visa it was 835ms for valid, 762ms for dummy, prefix and check digit appears to be checked client side.

我印象中這類方式已經發展很久了 (透過網路反應時間的 timing attack),討論裡面有提到「Exploiting remote timing attacks」這篇,也是十多年前的資料了... 不過官方網站玩起來總是有中特別爽的感覺 XDDD

不過 Visa 的這個網站前面用了 Cloudflare,用機器人掃感覺很容易被擋,這又是另外一回事了...

Vault 裡 AppRole 的設計,以及怎麼解決 Secret Zero 問題

VaultHashiCorp 拿來管理各種敏感資訊的軟體,像是 API token 或是資料庫的帳號密碼。把這些資訊集中控管後就不需要把這些資訊放進 Git (超爽的?),而是在需要的時候由應用程式呼叫 Vault 取得。

而 Vault 的設計裡面要求應用程式需要「認證」後才能取得,結果這個「認證」又是一組敏感資訊,這就是 Secret Zero 問題,屬於雞蛋問題的一種。

找了一輪發現 HashiCorp 自家的說明解釋的最清楚,不過這篇是放在 blog 上的文章:「Tackling the Vault Secret Zero Problem by AppRole Authentication」。

Vault 在解決 Secret Zero 的方法是使用 AppRole,這邊的認證包括了 role_idsecret_id 的設計。比較特別的是一組 role_id 可以有多組 secret_id 對應。

在 AppRole 這樣的設計下,權限會綁在 role_id 上,而 secret_id 則可以在部屬時動態產生,像是官方提到的 TerraformChef,或是依照組織裡面使用的管理工具:

這樣就可以透過 role_id 管理權限,但不用在 Git 裡面寫死 Secret Zero 資訊,而且每台機器都有自己的 secret_id 可以提供稽核記錄,把幾個比較明顯的問題解了不少...

IdenTrust 願意再幫 Let's Encrypt 交叉簽三年

先前在「Let's Encrypt 在 Android 平台上遇到的問題」這邊提到了 IdenTrustLet's Encrypt 交叉簽名的有效日會在 2021 年的八月底左右到期,而這會導致比較舊的 Android 平台因為沒有內建 ISRG Root X1 這個憑證,造成 Let's Encrypt 簽出來的憑證在這些舊的 Android 裝置上都認不出來。

文章出來過了一個多月後,剛剛看到 Let's Encrypt 發佈消息,IdenTrust 願意再交叉簽名三年:「Extending Android Device Compatibility for Let's Encrypt Certificates」,當時猜測發文是要讓 IdenTrust 表態,看起來目的達成了...

話說中間跑出來的「ZeroSSL 也提供免費的 SSL Certificate (DV) 了」不知道後續會怎麼樣,之後可以看看 Certificate Transparency 的資料來看看到底有多少人用...

Amazon Route 53 支援 DNSSEC

也是個大家等蠻久的功能,AWS 總算在 Amazon Route 53 上推出 DNSSEC 了:「Announcing Amazon Route 53 support for DNSSEC」。

他需要掛 AWS KMS,這部份會有一些費用在裡面,不過應該是還好...

不過 web console 目前有個明顯的缺點:透過 Route 53 註冊的網域,又用 Route 53 自家服務的情況下,設定 DNSSEC 的整合沒有做的很好,不能直接快速設定。

現在得自己設定演算法,然後複製 public key 到另外一邊,當你有一堆網域要設定的時候就會覺得很煩了...

Cloudflare 改推 ECH 加密整個 TLS 的 ClientHello

Cloudflare 本來在推的 ESNI 現在變成 ECH 了:「Good-bye ESNI, hello ECH!」。

上面這張圖是 ESNI,下面這張是 ECH:

可以看出來 ECH 最主要的差異是把本來的 ClientHello 都加密包起來了,伺服器會先試著解內層的 ClientHelloInner,失敗的時候會用外層的 ClientHelloOuter:

The server completes the handshake with just one of these ClientHellos: if decryption succeeds, then it proceeds with the ClientHelloInner; otherwise, it proceeds with the ClientHelloOuter.

看得出來 ECH 的其中一個目標是讓他看起來跟一般的 TLS 連線一樣,這樣就能順便解掉 censorship 的問題...

其中一個原因應該也是因為之前中國與俄國的直接封掉 ESNI:

In August 2020, the Great Firewall of China started blocking ESNI traffic, while still allowing ECH traffic.

In October 2020, Russian ISPs such as Rostelecom and its mobile operator Tele2 started blocking ESNI traffic.

不過仍然還有分析 HTTPS pattern 的方式可以抓 (就是文章裡提的 traffic analysis),目前看起來只處理了 ClientHello 本身,現在還是有機會分析 handshake 過程來擋,必須繼續改善 ECH 的協定,讓整個流程看起來都跟一般的 TLS 一樣...

可以等著看,到時候在中國的效果如何了,會不會讓國外的各大服務直接打進去呢...

Canonical 與 Docker 合作,推出了一系列 LTS Docker Image

CanonicalDocker 合作,推出了一系列 LTS Docker Image:「Canonical publishes LTS Docker Image Portfolio on Docker Hub」。

這邊的 LTS 是十年:

Ten year maintenance commitment on app images provides secure cloud software supply chain

另外有提到這些 LTS Docker Image 將不受 per-user rate limit 限制:

Canonical and Docker will collaborate on Docker Official Images and LTS Docker Image Portfolio to bring the best of the two to the community and ecosystem. The entire LTS Docker Image Portfolio will be exempted from per-user rate limits.

發佈的 image 可以在 https://hub.docker.com/u/ubuntu 上面翻到,主要就是常見的 server 軟體,算是多一個選擇...