Apple 對 PNG 解碼的 bug

前幾天的 Hacker News Daily 上看到「PNG Parser Differential」這個,對應的討論在「PNG Parser Differential (vidbuchanan.co.uk)」這邊可以看到。

作者想要利用 threading 加速處理 PNG 格式,結果寫出了 bug,但意外發現 Apple 的 PNG decoder 也犯了一樣的問題:「Ambiguous Decodes #3」。

作者做了一個特別的 PNG 放在網站上,在非 Safari 的情況下會是:

而拿 iPhone 的 Safari 讀的話,可以看到:

應該是 implementation bug,還蠻有趣的 bug...

法院認為 Apple 必須在 12 月 9 日前開放行動平台上的第三方支付

大標題是「Judge orders Apple to allow external payment options for App Store by December 9th, denying stay」,小標題是「And Apple announces it will appeal」。

本來 Apple 想要繼續拖延,但法院直接打槍,然後 Apple 決定要再上訴到第九巡迴庭,基本上我們就是在旁邊坐著等看戲...

另外前陣子 Google 宣佈在南韓會開放其他付款機制 (參考「Google 在南韓開放 app 裡面使用其他付款機制了」),就沒看到 Apple 這邊的動作,找了一下新聞只看到 Apple 在南韓的頭決定不幹了:「Apple's top exec in South Korea departs amid dispute over App Store」,也許之後再找看看...

在非 4K 的螢幕上跑 HiDPI

前幾天看到 BetterDummy 這個專案,作者在 M1 上面外接 24" 1440p 的螢幕,但沒辦法啟用 HiDPI,於是就寫了一個軟體來解:

M1 macs tend to have issues with custom resolutions. Notoriously they don't allow sub-4K resolution displays to have HiDPI ("Retina") resolutions even though (for example) a 24" QHD 1440p display would greatly benefit from having an 1920x1080 HiDPI "Retina" mode.

在這之前的解法都有些麻煩,一種是買個 dummy dongle 去騙 macOS,另外是用 mirror 的方式使用:

To fix this issue, some resort to buying a 4K HDMI dummy dongle to fool macOS into thinking that a 4K display is connected and then mirror the contents of this dummy display to their actual monitor in order to have HiDPI resolutions available. Others use the built in screens of their MacBooks to mirror to the external display. These approaches have obvious drawbacks and cannot solve all problems.

作者提供的軟體可以先建立 Dummy Monitor,然後再透過 mirror 掛到實際螢幕上:

不確定用起來如何,但如果之後有需要的話好像可以測試看看...

在 Linux (Ubuntu) 上跑透過 QEMU 跑 Windows/Mac/Linux 的工具

Hacker News Daily 上看到的工具:「Quickly create and run optimised Windows, macOS and Linux desktop virtual machines.」,對應的討論在「Quickemu: Quickly create and run optimised Win-10,11/macOS/Linux on Linux (github.com/wimpysworld)」這邊可以看到,可以減少自己要設定一堆 QEMU 參數。

雖然專案是支援多系統,但其實 Microsoft WindowsLinux 的部份在其他虛擬軟體都很簡單 (像是用 VirtaulBox),大家馬上會注意到的重點還是 macOS 的部份,如果有自己弄過就會知道這東西有夠難裝的,而且跨版本有不同的安裝方式...

目前 Quickemu 支援四個版本:

Supported macOS releases:

  • High Sierra
  • Mojave
  • Catalina (Recommended)
  • Big Sur

然後可以看到幾乎所有目前能支援的功能都有設定上去了,包括 VirtIO 與 USB 的部份。

然後一些經典的問題,像是 Big Sur 的音源問題還是沒解:

Full Duplex audio works on macOS High Sierra, Mojave and Catalina.

  • macOS Big Sur has no audio at all.

在 Hacker News 的討論串裡面有提到有很多地方沒有檢查,這會是風險:

While I appreciate the effort, and the code is very readable. I just want to give a friendly warning that these shell scripts just download random stuff from the internet and run this random stuff without checking any integrity/signature.

下面的討論另外看到個冷知識,關於蘋果故意走 HTTP 下載 recovery image 是因為 HTTPS 太複雜,在 UEFI firmware 裡面實做容易產生被攻擊的點,所以決定自己透過其他機制確認正確性:

Apple Internet recoveryOS images are served over plain http, on purpose. The macrecovery.py script used by Quickemu uses http¹, though the server supports https.

https://support.apple.com/guide/security/recoveryos-and-diagnostics-environments-sec2512a0c09/web

> When the internet recovery and diagnostic modes were added to Mac computers in 2011, it was decided that it would be better to use the simpler HTTP transport, and handle content authentication using the chunklist mechanism, rather than implement the more complicated HTTPS functionality in the UEFI firmware, and thus increase the firmwareʼs attack surface.

¹https://github.com/acidanthera/OpenCorePkg/blob/4a740c3f256e285c66ca3b65e42b60af6826d343/Utilities/macrecovery/macrecovery.py#L123

[edit] Added macrecovery.py info

另外為了避免直接在 shell script 裡面出現「神秘字串」,可以看到特別的寫法 XDDD

Took a little while to find the magic words in there: https://github.com/wimpysworld/quickemu/blob/af26f41440d63a069045660fad860c797011310a/quickemu#L351

可以想到一些用途,像是在機房裡面跑 CI 的 worker,但要注意這個搞法不符合蘋果的 EULA,現在不抓不代表以後也不會有事,請自己謹慎評估...

然後往 ARM-based 架構後應該門檻就更高了,現在還有 Intel-based 的環境可以用加減用...

南韓對 Apple 與 Google 的 In-App 付款機制的提案

WSJ 上看到南韓對 AppleGoogle 的 in-app 付款機制提案,強制 Apple 與 Google 讓 app 的開發者 (或是開發商) 使用第三方支付平台:「Google, Apple Hit by First Law Threatening Dominance Over App-Store Payments」。

看不到 WSJ 內文的可以看「Apple and Google must allow developers to use other payment systems, new Korean law declares」這篇,裡面有引用韓國的媒體報導 (英文版):「S. Korea looks set for legislation to curb Google, Apple's in-app billing system」。

要注意這還沒有通過,目前過委員會而已 (parliamentary committee),接下來要表決才會成為正式法律。

先前美國亞利桑那州的法案被擋下來,然後參議院提的法案也還在進行中,看起來還有很硬的仗要打:「由美國參議院提出的 Open App Markets Act」。

先繼續等後續發展,可以想見 Apple 與 Google 一定會想辦法抵制...

由美國參議院提出的 Open App Markets Act

以為之前有寫過亞利桑那州的法律,結果沒找到... (有可能寫一寫就刪掉了)

三月初的時候亞利桑那州推動修正法案,強制夠大的 OS 必須開放其他的 App Store 以及 Payment 系統 (以當時,或是現在來看,應該只有 AppleiOSGoogleAndroid 這兩個系統):「Arizona advances bill forcing Apple and Google to allow Fortnite-style alternative payment options」,不過這個法案在同月月底的時候就被沒收了:「It’s game over for Arizona’s controversial App Store bill」。

這次則是由美國參議院 (上議院) 跨黨派的三位參議員提出來的 Open App Markets Act 也是類似的事情,只是拉到全國的層級:「Blumenthal, Blackburn & Klobuchar Introduce Bipartisan Antitrust Legislation to Promote App Store Competition」。在 Hacker News 上有討論:「Senators introduce bipartisan antitrust bill to promote app store competition (senate.gov)」。

第一關應該是要先讓參議院通過,在這個階段 Apple 與 Google 兩家應該就會有各種檯面上的遊說與檯面下的動作,另外像是 EpicSpotify 這些公司應該也會進去推一把...

居然在安全性漏洞的 PoC 上面看到拿 Bad Apple!! 當作範例

人在日本的資安專家 Hector Martin 找到了 Apple M1 的安全漏洞,可以不用透過 macOS Big Sur 提供的界面,直接透過 M1 的漏洞跨使用者權限傳輸資料,這可以用在突破 sandbox 的限制。而也如同目前的流行,他取了一個好記的名字:「M1RACLES: M1ssing Register Access Controls Leak EL0 State」,對應的 CVECVE-2021-30747

先講比較特別的點,PoC 的影片放在 YouTube 上,作者拿 Bad Apple!! 當作示範,這很明顯是個雙關的點:

這應該是當年的影繪版本,看了好懷念啊... 當年看到的時候有種「浪費才能」的感覺,但不得不說是個經典。

Hacker News 上有討論可以翻翻:「M1racles: An Apple M1 covert channel vulnerability (m1racles.com)」。

依照作者的說明,Apple A14 因為架構類似,也有類似的問題,不過作者沒有 iPhone,沒辦法實際測試:

Are other Apple CPUs affected?

Maybe, but I don't have an iPhone or a DTK to test it. Feel free to report back if you try it. The A14 has been confirmed as also affected, which is expected, as it is a close relative of the M1.

另外作者覺得這個安全漏洞在 macOS 上還好,主要是你系統都已經被打穿可以操控 s3_5_c15_c10_1 register 了,應該會有更好的方式可以用:

So you're telling me I shouldn't worry?

Yes.

What, really?

Really, nobody's going to actually find a nefarious use for this flaw in practical circumstances. Besides, there are already a million side channels you can use for cooperative cross-process communication (e.g. cache stuff), on every system. Covert channels can't leak data from uncooperative apps or systems.

Actually, that one's worth repeating: Covert channels are completely useless unless your system is already compromised.

比較明顯的問題應該是 iOS 這邊的 privacy issue,不過 iOS 上的 app store 有基本的保護機制:(不過想到作者可以故意寫成 RCE 漏洞...)

What about iOS?

iOS is affected, like all other OSes. There are unique privacy implications to this vulnerability on iOS, as it could be used to bypass some of its stricter privacy protections. For example, keyboard apps are not allowed to access the internet, for privacy reasons. A malicious keyboard app could use this vulnerability to send text that the user types to another malicious app, which could then send it to the internet.

However, since iOS apps distributed through the App Store are not allowed to build code at runtime (JIT), Apple can automatically scan them at submission time and reliably detect any attempts to exploit this vulnerability using static analysis (which they already use). We do not have further information on whether Apple is planning to deploy these checks (or whether they have already done so), but they are aware of the potential issue and it would be reasonable to expect they will. It is even possible that the existing automated analysis already rejects any attempts to use system registers directly.

Apple 與 Amazon 都要推出無損版的音樂串流服務了

首先是 Apple 宣佈了無損的音樂串流服務,不另外加價:「Apple Music Launching Spatial Audio With Dolby Atmos and Lossless Audio in June at No Extra Cost」,官方新聞稿在「Apple Music announces Spatial Audio with Dolby Atmos; will bring Lossless Audio to entire catalog」。

再來是 Amazon 也宣佈跟上,本來就有提供無損的 Amazon Music HD 下放到 Amazon Music Unlimited 方案也可以聽了:「Amazon Music Matching Apple by Offering Hi-Fi Tier at No Extra Cost」。

這對 Spotify 的壓力應該不小,畢竟已經先宣佈會推出無損版,但卻反而先被競爭對手出招先行制定價錢了...

跨瀏覽器追蹤的方式

看到「Exploiting custom protocol handlers for cross-browser tracking in Tor, Safari, Chrome and Firefox」這個方式,跨瀏覽器收集 fingerprint 追蹤。

這次用的方式是透過 handler 追:

The scheme flooding vulnerability allows an attacker to determine which applications you have installed. In order to generate a 32-bit cross-browser device identifier, a website can test a list of 32 popular applications and check if each is installed or not. On average, the identification process takes a few seconds and works across desktop Windows, Mac and Linux operating systems.

最近大家比較常使用到的應該就是 Zoom 從網頁把應用程式帶起來的方式:

而要怎麼偵測的部份,用到了不同瀏覽器的 side channel。

Chromium 系列的部份對應的 ticket 在「Issue 1096610: External Protocol handler anti-flood protection is ineffective and flaky」這邊有被提出來。主要用到的方法是,在遇到有 handler 時,連打兩次時會被擋下:

被擋下後再打都會失敗,所以需要一個方式重設 flag,而內建的 Chrome PDF Viewer 剛好可以重設 flag:

The built-in Chrome PDF Viewer is an extension, so every time your browser opens a PDF file it resets the scheme flood protection flag. Opening a PDF file before opening a custom URL makes the exploit functional.

Firefox 的 side channel 則是可以透過 same-origin policy 測試當作 side channel,對應的 ticket 在「Scheme flooding technique for reliable cross-browser fingerprinting」這邊:

Every time you navigate to an unknown URL scheme, Firefox will show you an internal page with an error. This internal page has a different origin than any other website, so it is impossible to access it because of the Same-origin policy limitation. On the other hand, a known custom URL scheme will be opened as about:blank, whose origin will be accessible from the current website.

Safari 上的問題與 Firefox 一樣,不過沒登入看不到 ticket (也懶的註冊了):

You are not authorized to access bug #225769. To see this bug, you must first log in to an account with the appropriate permissions.

另外,雖然 Tor Browser 底層是 Firefox,但因為有改變預設值,所以攻擊者也得換方法:

Tor Browser is based on the Firefox source code, so the Same-origin policy trick was used here as well. But because Tor Browser does not show pop-ups, we used the same-origin policy trick with iframe elements instead.

這個方法還蠻暴力的...

Dropbox 也要搞自己的密碼管理器

Dropbox 也要搞自己的密碼管理器 Dropbox Passwords:「Dropbox Passwords coming soon for all users」。

看起來只要是 Dropbox 的付費方案就可以無限使用,而免費版的則是 50 組。從下載頁看起來目前在 PC 上只支援 Microsoft WindowsmacOS,不支援 Linux

Come back to this page on a PC with Windows 10 or a Mac with at least macOS Sierra 10.12 to get the Passwords desktop app.

而行動平台就是 iOSAndroid

How do I use the Android and iPhone password manager?

Once you sign in to the Passwords app, it automatically fills in your usernames and passwords so you can access frequently used apps and websites on your mobile device.

從示意圖看起來有整合瀏覽器,而加密技術的部份沒有講太多,只說是 zero-knowledge encryption,先觀望看看...