在 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,先觀望看看...

Google 釋出網頁版的 Spectre 攻擊 PoC,包括 Apple M1 在內

在大約三年前 (2018 年年初) 的時候,在讀完 Spectre 之後寫下了一些記錄:「讀書時間:Spectre 的攻擊方式」,結果在 Bruce Schneier 這邊看到消息,Google 前幾天把把 PoC 放出來了:「Exploiting Spectre Over the Internet」,在 Hacker News 上也有討論:「A Spectre proof-of-concept for a Spectre-proof web (googleblog.com)」。

首先是這個攻擊方法在目前的瀏覽器都還有用,而且包括 Apple M1 上都可以跑:

The demonstration website can leak data at a speed of 1kB/s when running on Chrome 88 on an Intel Skylake CPU. Note that the code will likely require minor modifications to apply to other CPUs or browser versions; however, in our tests the attack was successful on several other processors, including the Apple M1 ARM CPU, without any major changes.

即使目前的瀏覽器都已經把 performance.now() 改為 1ms 的精度,也還是可以達到 60 bytes/sec 的速度:

While experimenting, we also developed other PoCs with different properties. Some examples include:

  • A PoC which can leak 8kB/s of data at a cost of reduced stability using performance.now() as a timer with 5μs precision.
  • A PoC which leaks data at 60B/s using timers with a precision of 1ms or worse.

比較苦的消息是 Google 已經確認在軟體層沒辦法解乾淨,目前在瀏覽器上只能靠各種 isolation 降低風險,像是將不同站台跑在不同的 process 裡面:

In 2019, the team responsible for V8, Chrome’s JavaScript engine, published a blog post and whitepaper concluding that such attacks can’t be reliably mitigated at the software level. Instead, robust solutions to these issues require security boundaries in applications such as web browsers to be aligned with low-level primitives, for example process-based isolation.

Apple M1 也中這件事情讓人比較意外一點,看起來是當初開發的時候沒評估?目前傳言的 M1x 與 M2 不知道會怎樣...

Cloudflare 再次嘗試 ARM 伺服器

2018 年的時候寫過一篇 Cloudflare 在嘗試 ARM 伺服器的進展:「Cloudflare 用 ARM 當伺服器的進展...」,後來就沒有太多公開的消息,直到這幾天看到「ARMs Race: Ampere Altra takes on the AWS Graviton2」才看到原因:

By the time we completed porting our software stack to be compatible with ARM, Qualcomm decided to exit the server business.

所以是都測差不多,也都把 Cloudflare 自家的軟體搬上去了,但 Qualcomm 也決定收手,沒機器可以用...

這次再次踏入 ARM 領域讓人想到前陣子 AppleM1,讓大家看到 ARM 踏入桌機與筆電領域可以是什麼樣貌...

這次 Cloudflare 選擇了 Ampere Altra,這是基於 Neoverse N1 的平台,而這個平台的另外一個知名公司就是 AWSGraviton2,所以就拿來比較:

可以看到 Ampere Altra 的核心數多了 25% (64 vs. 80),運作頻率多了 20% (2.5Ghz vs. 3.0Ghz)。測試的結果也都有高有低,落在 10%~40% 都有。

不過其中比較特別的是 Brotli - 9 的測試特別差 (而且是 8 與 10 都正常的情況下):

依照 Cloudflare 的說法,他們其實不會用到 Brotli - 7 以及更高的等級,不過畢竟有測出來,還是花了時間找一下根本原因:

Although we do not use Brotli level 7 and above when performing dynamic compression, we decided to investigate further.

反追問題後發現跟 Page Faults 以及 Pipeline Backend Stalls 有關,不過是可以改寫避開,在避開後可以達到跟 Graviton2 類似的水準:

By analyzing our dataset further, we found the common underlying cause appeared to be the high number of page faults incurred at level 9. Ampere has demonstrated that by increasing the page size from 4K to 64K bytes, we can alleviate the bottleneck and bring the Ampere Altra at parity with the AWS Graviton2. We plan to experiment with large page sizes in the future as we continue to evaluate Altra.

但目前看起來應該都還算正向,看起來供貨如果穩定的話,應該有機會換過去?畢竟 ARM 平台可以省下來的電力太多了,現在因為 M1 對 ARM 的公關效果太驚人的關係,解釋起來會更輕鬆...

Apple 推出讓 iCloud 可以複製到 Google Photos 上的服務

Apple 推出了從 iCloud 的內容複製到 Google Photos 上的服務:「Apple Launches Service for Transferring iCloud Photos and Videos to Google Photos」。

我登入進去 iCloud 沒看到,後來才看到:

Apple's transfer service is available to customers in Australia, Canada, the European Union, Iceland, Liechtenstein, New Zealand, Norway, Switzerland, the United Kingdom, and the United States at this time.

服務的區域主要是歐洲北美紐西蘭,台灣暫時還沒辦法用,只能先看一下 screenshot 了:

既然是 Google Photos,能搬過去的就只有 Google Photos 有支援的類型,包括了大部分的圖片與影片格式:

Smart Albums, Live Photos, photo stream content, some metadata, and some RAW photos are not able to be transferred, but formats including .jpg, .png, .webp, .gif, some RAW files, .mpg, .mod, .mmv, .tod, .wmv, .asf, .avi, .divx, .mov, .m4v, .3gp, .3g2, .mp4, .m2t, .m2ts, .mts, and .mkv are compatible.

不知道推出這個功能後面的意義是什麼...