Category: Security

iPhone 5S 又拿到安全性更新了：iOS 12.5.7 (2023/01/23)

Apple 又針對 iOS 12 釋出安全性更新了：「About the security content of iOS 12.5.7」。

Available for: iPhone 5s, iPhone 6, iPhone 6 Plus, iPad Air, iPad mini 2, iPad mini 3, and iPod touch (6th generation)

Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited against versions of iOS released before iOS 15.1.

Description: A type confusion issue was addressed with improved state handling.

這次的更新是 backport 去年十二月在 Safari 16.2 上修正的 CVE-2022-42856：

A type confusion issue was addressed with improved state handling. This issue is fixed in Safari 16.2, tvOS 16.2, macOS Ventura 13.1, iOS 15.7.2 and iPadOS 15.7.2, iOS 16.1.2. Processing maliciously crafted web content may lead to arbitrary code execution.

所以這包跟上次一樣 (參考先前寫的 「iOS 12.5.6」這篇)，也是在修正 RCE 類的漏洞，這樣對於 iPhone 5S 等於是進入第九年的支援了。

之前在網路上有看到有人在猜是因為海外有很多異議人士拿這隻手機，所以美國政府「希望」Apple 能夠針對一些高危險性的安全漏洞提供更新？

Git 在 SHA-256 支援上遇到的問題

在 Hacker News 首頁上的「Whatever happened to SHA-256 support in Git?」這篇，大概半年前，今年六月的文章，在講 Git 在 SHA-256 支援上遇到的問題。

最大的問題還是沒有 transition plan：

Bjarmason pointed out that there is still no interoperability between SHA-1 and SHA-256 repositories, and that none of the Git hosting providers appear to be supporting SHA-256.

這點導致了目前場上看的到的服務與 open source 軟體都沒有支援的計畫，這點算是一個超級失敗的 transition plan。

另外乾脆請 OpenAI 的 ChatGPT 幫忙寫：

Git是一種源代碼管理系統，它使用散列函數將每個對象（例如文件的每個版本）和每個提交都轉換為一個數值，用於存儲該對象。散列函數的安全性是整個倉庫完整性的重要組成部分。如果攻擊者可以用具有相同散列值的另一個提交替換提交，他們可能會在不冒檢測風險的情況下將惡意代碼植入倉庫中。這種前景令任何依賴 Git 倉庫中代碼安全性的人感到擔心，也就是所有人。

Git 項目早已選擇 SHA-256 作為 SHA-1 的替代品。Git 最初是使用 SHA-1 寫成的，但是這些代碼已被重構，並且可以處理多種散列類型，其中 SHA-256 是第二種支持的類型。現在可以使用 SHA-256 創建 Git 倉庫（只需使用 --object-format=sha256 標誌），大多數本地操作都會正常工作。Git 中支持替代散列算法的基礎是2020年發布的2.29版本的一部分，並且似乎很穩定。

然而，自從2021年3月發布的2.31版本中出現了修復程序以來，2.29版本是最後一個在任何重大方面支持替代散列的版本。專

續寫前文，Git 專案在支持 SHA-256 之前一直使用 SHA-1 作為散列算法。然而，由於 SHA-1 的終極破解，Git 項目被迫尋找替代方案。Git 原本的代碼是深深地嵌入 SHA-1 的，但是這些代碼已經被重構，並且可以處理多種散列類型，其中 SHA-256 是第二種支持的類型。因此，現在可以使用 SHA-256 創建 Git 倉庫（只需使用 --object-format=sha256 標誌），大多數本地操作都會正常工作。

然而，目前尚不存在 SHA-1 和 SHA-256 倉庫之間的相互操作性，並且 Git 托管提供商似乎都不支持 SHA-256。這種支持（或缺乏支持）很重要，因為無法推送到 Git 熔爐的倉庫對許多人來說將是無用的。此外，使用 SHA-256 的較長散列可能會破壞 Git 項目以外開發的工具，這種風險也無法完全消除。整體而言，這是一種尚未準備好用於現實世界的功能。

雖然如此，值得注意的是，迄今為止完成大部分散列轉換工作的 brian m. carlson 對 Bjarmason 的評估持不同看法。在他看來，目前唯一“可以辯解

的”使用 SHA-1 的原因是與 Git 熔爐提供商的相互操作性。否則，他認為 SHA-1 已經過時，並且使用 SHA-256 的性能可能“大幅提升”。但是，他同意所需的相互操作性目前尚不存在，且沒有人表示它即將在短期內到來。

因此，目前看來，Git 專案在支持 SHA-256 方面的工作似乎已經停止。至於什麼原因導致了這種情況，目前還不清楚。但是，這並不意味著 Git 將永遠不會支持 SHA-256 或其他散列算法。相反，可能是因為尚未解決所有技術問題，或者可能是因為其他原因（例如技術資源有限）。無論原因是什麼，重要的是要記住，Git 項目的開發人員一直在努力使其更強大、更安全，並且將繼續努力。

Ruby 3.2.0 把 YJIT 列為穩定功能了

去年有寫過 Ruby 的 YJIT 帶來的效能提昇：「YJIT 帶給 Ruby 大量的效能提昇」。

在這次的 Ruby 3.2.0 發布就把 YJIT 列為穩定功能了：「Ruby 3.2.0」。

  • YJIT is no longer experimental
    • Has been tested on production workloads for over a year and proven to be quite stable.

另外就是支援的平台，看起來是多了 arm64 這邊的支援，所以馬上列表就多了一堆新機器：

  • YJIT now supports both x86-64 and arm64/aarch64 CPUs on Linux, MacOS, BSD and other UNIX platforms.
    • This release brings support for Apple M1/M2, AWS Graviton, Raspberry Pi 4 and more.

另外是每個程式語言幾乎都會遇到的 regexp 類的問題，這次 Ruby 3.2.0 利用 Memoization 的方式降低某些 regexp 的消耗：

# This match takes 10 sec. in Ruby 3.1, and 0.003 sec. in Ruby 3.2
/^a*b?a*$/ =~ "a" * 50000 + "x"

而另外一組 regexp 也可以看出類似的效果：

用一些記憶體空間換取效能，降低被 DoS 的一些機會。另外一方面，引入了 regexp timeout 的 workaround，緩解真的被打的時候的資源消耗上限：

The optimization above cannot be applied to some kind of regular expressions, such as those including advanced features (e.g., back-references or look-around), or with a huge fixed number of repetitions. As a fallback measure, a timeout feature for Regexp matches is also introduced.

LastPass 離職員工的爆料

這次 LastPass 出包搞的蠻大的，在官方的「Notice of Recent Security Incident」的裡面有提到這次的資料外洩包括了使用的 encrypted vault data 也被洩漏了：

The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.

官方一直強調這是 encrypted data，但離職員工爆料加密強度不足的問題：「1606428769731878913.html」，其中這段在講 legacy 版本的加密問題，居然曾經用過 ECB mode：

Lots of vault entries may be encrypted with ECB mode AES-256. I worked on supporting unauthenticated CBC mode. But re-encrypting a users vault entries requires having their master key.

這個如同 Hacker News 上的討論「I worked at LastPass as an engineer (twitter.com/ejcx_)」提到的，以 1980 年代的標準就已經知道 ECB mode 的問題了：

> Lots of vault entries may be encrypted with ECB mode AES-256.
Wtf wtf wtf. This would be considered wildly insecure even by the standards of the 80s

其他提到 PBKDF2 的強度是逐步增加，從早期的 5000 到現在預設的 100100，這點倒是可以理解。

要避免依賴廠商的資安，一種方式是用目前成熟的開源 Password Manager，並且使用檔案儲存 (像是 KeePassXC 這類工具)，再搭配 file sync 的工具跨機器使用 (像是 Syncthing 這樣獨立確認每個 device 身份的方式)，但方便性不會像這些商用方案這麼好用就是了...

這次故事好像還沒結束，遇到西方的長假，反應都比較慢...

FBI 建議用擋廣告軟體降低瀏覽時的風險

在「Even the FBI says you should use an ad blocker」這邊看到的新聞，FBI 的公告則是在「Cyber Criminals Impersonating Brands Using Search Engine Advertisement Services to Defraud Users」這邊可以看到。

起因是有很多網路犯罪行為會透過購買廣告，在搜尋引擎上曝光誘導使用者點擊：

Cyber criminals purchase advertisements that appear within internet search results using a domain that is similar to an actual business or service. When a user searches for that business or service, these advertisements appear at the very top of search results with minimum distinction between an advertisement and an actual search result. These advertisements link to a webpage that looks identical to the impersonated business’s official webpage.

其中一種方式是，使用者輸入關鍵字想要下載某些特定的軟體，這時候網路犯罪者就會透過下廣告的方式，誘導使用者到假的網站下載有後門木馬的軟體：

In instances where a user is searching for a program to download, the fraudulent webpage has a link to download software that is actually malware. The download page looks legitimate and the download itself is named after the program the user intended to download.

這個方式讓我想到之前北韓政府對 PuTTY 的攻擊：「Trojanized versions of PuTTY utility being used to spread backdoor」。

而 FBI 建議個人的保護方式包括了 ad blocking extension，這算是減少被攻擊的管道：

Use an ad blocking extension when performing internet searches. Most internet browsers allow a user to add extensions, including extensions that block advertisements. These ad blockers can be turned on and off within a browser to permit advertisements on certain websites while blocking advertisements on others.

然後建議擋廣告軟體就是用 uBlock Origin，無論是 Chromium 系列的瀏覽器 (包括 Google Chrome)，或是 Firefox 都有支援。

Let's Encrypt 支援 ACME-CAA，可以再進一步限縮可以申請的使用人

前幾天在 Hacker News 上看到 Let's Encrypt 支援 ACME-CAA 的新聞：「Let's Encrypt now supports ACME-CAA: closing the DV loophole (devever.net)」，原文在「Let's Encrypt now supports ACME-CAA: closing the DV loophole」。

先前的「RFC 6844 - DNS Certification Authority Authorization (CAA) Resource Record」已經先定義了 DNS 上 CAA record 的規範，另外在 CA/Browser Forum 的 Baseline Requirements 裡面也要求了 CA 簽發單位必須遵守 CAA 設定。

但這邊還是有一些風險，像是當網站被其他人控制後 (或是中間有 BGP hijacking 的方式取得 TCP 層的控制權)，控制人就可以透過 http-01 的方式通過認證申請到 SSL certificate。而這次 Let's Encrypt 實做的 ACME-CAA 則是試著降低這個風險。

第一個是 accounturi 參數，可以指定只有某個 CA 裡的某個帳號可以申請，像是這樣：

example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://some/lets-encrypt/account-id"

第二個是限制 validationmethods 參數，限制只有某些方式可以申請，像是這邊限制只能透過 dns-01 申請：

example.com. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01"

不過支援 http-01 的不只 Let's Encrypt，至少也還有 ZeroSSL 與 Buypass，後續可以看看其他家會不會跟上，以及會不會放到 Baseline Requirements 裡面...

讓 Windows 2000/XP/Vista 與 Server 2003/2008 能夠更新的軟體

在 Hacker News 上看到「Legacy Update」這個網站：

Legacy Update: Fix Windows Update on Windows XP, Vista, Server 2008, 2003, and 2000

對於已經沒辦法跑 Windows Update 的作業系統，至少有個工具可以把現有手上的 patch 都裝進去？

不過網站本身最低只支援 TLS 1.0，所以對於新安裝的 IE6 得手動開 TLS 1.0 後才能連上 (預設是關閉的)，但看起來至少是個比較方便的工具了。

如果是跑在虛擬機裡面的話可以先用 host OS 下載下來再透過其他方式丟進去，不過我試著下載檔案，點了半天一直被重導到首頁... GitHub 上面看起來是有檔案，但 GitHub 對於老 OS 來說是無法連線的對象...

另外看了一下 WHOIS 資料，是今年七月才成立的網站，不是那種已經出來好幾年的網站，上面的東西的可信度可以自己斟酌...

GitHub 的 2FA 新計畫

GitHub 決定擴大強制使用 2FA 的範圍：「Raising the bar for software security: next steps for GitHub.com 2FA」。

本來的 2FA policy 是在「Software security starts with the developer: Securing developer accounts with 2FA」這邊提到的，所有的使用者預定在 2023 年年底強制使用 2FA：

GitHub will require all users who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA) by the end of 2023.

另外針對 npm 熱門套件的維護者，則是在三月 (top 100) 與五月 (top 500) 就強制要使用了：

In February we enrolled all maintainers of the top-100 packages on the npm registry in mandatory 2FA, and in March we enrolled all npm accounts in enhanced login verification. On May 31, we will be enrolling all maintainers of the top-500 packages in mandatory 2FA.

但到 2023 年年底才有動作會有點久，所以這次宣佈在 2023 年三月會插入一個新階段，強制這些人要有 2FA 才能進行變更類的操作：

  • Users who published GitHub or OAuth apps or packages
  • Users who created a release
  • Users who are Enterprise and Organization administrators
  • Users who contributed code to repositories deemed critical by npm, OpenSSF, PyPI, or RubyGems
  • Users who contributed code to the approximate top four million public and private repositories

以 developer 為主的 GitHub 大力在推 2FA，其他的服務不知道之後會不會有類似動作...

NIST 更新了 SHA-1 的淘汰計畫

NIST 對 SHA-1 的新的淘汰計畫出來了：「NIST Retires SHA-1 Cryptographic Algorithm」。

先前 NIST 在 2004 年時是計畫在 2010 年淘汰掉 SHA-1，在「NIST Brief Comments on Recent Cryptanalytic Attacks on Secure Hashing Functions and the Continued Security Provided by SHA-1」這邊可以看到當時的宣佈：

The results presented so far on SHA-1 do not call its security into question. However, due to advances in technology, NIST plans to phase out of SHA-1 in favor of the larger and stronger hash functions (SHA-224, SHA-256, SHA-384 and SHA-512) by 2010.

但看起來當時沒有強制性，所以事情就是一直拖一直延期，中間經過了 2017 年 Google 與 CWI Amsterdam 展示的 SHA-1 collision：「Google 與 CWI Amsterdam 合作，找到 SHA-1 第一個 collision」。

以及 2020 年時的進展與分析，發現 chosen-prefix collision 已經是可行等級了：「SHA-1 的 chosen-prefix collision 低於 2^64 了...」。

然後 NIST 總算是想起來要更新 phase out 的計畫，現在最新的計畫是在 2030 年年底淘汰掉 SHA-1：

As today’s increasingly powerful computers are able to attack the algorithm, NIST is announcing that SHA-1 should be phased out by Dec. 31, 2030, in favor of the more secure SHA-2 and SHA-3 groups of algorithms.

這次就有一些強制的規範了，包括採購的部份：

“Modules that still use SHA-1 after 2030 will not be permitted for purchase by the federal government,” Celi said.

但 2030 年聽起來還是有點慢...

AWS 推出加速 Lambda 啟動速度的 Lambda SnapStart

今年 AWS 的 re:Invent 又開始了，這一個禮拜會冒出蠻多新功能的，挑自己覺得比較有興趣得來寫。

AWS 針對 Lambda 推出 Lambda SnapStart，改善冷啟動的速度：「New – Accelerate Your Lambda Functions with Lambda SnapStart」。

他拿了一個比較明顯的例子，Java 的 Spring Boot，範例在「Serverless Spring Boot 2 example」這邊，冷啟動的速度可以從 6 秒降到 200ms：

SnapStart has reduced the cold start duration from over 6 seconds to less than 200 ms.

方法就是把 initialization 的程式完成後的記憶體打一份 snapshot 存起來，之後的冷啟動第一動變成是 restore 而非再 initialize：

With SnapStart, the initialization phase (represented by the Init duration that I showed you earlier) happens when I publish a new version of the function. When I invoke a function that has SnapStart enabled, Lambda restores the snapshot (represented by the Restore duration) before invoking the function handler. As a result, the total cold invoke with SnapStart is now Restore duration + Duration.

不過不是所有的應用程式都可以直接套用，有些要注意的地方，比較好理解的是連線 (像是對後端資料庫的預連線) 以及暫存檔的部份 (像是預先算好某些資料後寫到暫存檔) 都需要重新建立。

比較特別的是亂數產生器需要重新 initialize，不然會有機率產生出一樣的 random data，這個是一般開發者會忽略掉的：

When using SnapStart, any unique content that used to be generated during the initialization must now be generated after initialization in order to maintain uniqueness.

所以 AWS 有針對 SnapStart 下的 OpenSSL 修正，另外外他們也確認過 Java 的 java.security.SecureRandom 本身就沒問題：

We have updated OpenSSL’s RAND_Bytes to ensure randomness when used in conjunction with SnapStart, and we have verified that java.security.SecureRandom is already snap-resilient.

另外 AWS 也推薦可以直接讀系統的 /dev/random 或是 /dev/urandom，這樣就很自然的不會因為 snapshot 而固定，當然也就沒問題：

Amazon Linux’s /dev/random and /dev/urandom are also snap-resilient.

這個功能說不用另外收費，看起來對 Java 族群還不錯？