Tag: security

CloudFront 宣佈支援 ECDSA 的 Certificate

Amazon CloudFront 宣佈支援 ECDSA 的 certificate：「Amazon CloudFront now supports ECDSA certificates for HTTPS connections to viewers」。

用主要是讓 certificate 更小，讓 HTTPS 建立時的過程更快 (包括了傳輸的速度與計算的速度)：

As a result, conducting TLS handshakes with ECDSA certificates requires less networking and computing resources making them a good option for IoT devices that have limited storage and processing capabilities.

很久以前好像有看到資料說 256 bits 的 EC 運算量跟 768～1024 bits 的 RSA 差不多，但一時間找不到資料...

目前 CloudFront 只支援 NIST P-256 (secp256r1，或稱作 prime256v1)：

Starting today, you can use Elliptic Curve Digital Signature Algorithm (ECDSA) P256 certificates to negotiate HTTPS connections between your viewers and Amazon CloudFront.

但 NIST P-256 一直為人詬病，在「SafeCurves: choosing safe curves for elliptic-curve cryptography」這邊可以看到 NIST 宣稱的效率設計實際上都不是真的：

Subsequent research (and to some extent previous research) showed that essentially all of these efficiency-related decisions were suboptimal, that many of them actively damaged efficiency, and that some of them were bad for security.

但目前標準是往 NIST P-256、NIST P-384 與 NIST P-521 靠攏 (主要是受到 CA/Browser Forum 的限制)，要其他 curve 的 certificate 也沒辦法生，目前可能還是繼續觀望...

Kaspersky Password Manager 的漏洞

在 Hacker News Daily 上看到「Kaspersky Password Manager: All your passwords are belong to us」這篇，講 Kaspersky Password Manager (KPM) 嚴重的安全漏洞，另外在 Hacker News 上的討論「Kaspersky Password Manager: All your passwords are belong to us (ledger.com)」也有提到一些有趣的東西。

標題的 All your passwords are belong to us 是出自「All your base are belong to us」這個梗的變形。

這包安全問題主要的原因是因為 KPM 沒有使用 CSPRNG，而且也沒有正確 seed，所以極為容易被猜出密碼本身。

KPM 的 Web 版使用了 Math.random()，在各家瀏覽器主要是用 xorshift128+ 實做 Math.random()，作者沒有針對這塊再花時間研究，但很明顯的 Math.random() 不是個 CSPRNG：

The underlying PRNG used by Chrome, Firefox and Safari for Math.random() is xorshift128+. It is very fast, but not suitable to generate cryptographic material. The security consequences in KPM has not been studied, but we advised Kaspersky to replace it with window.crypto.getRandomValues(), as recommended by the Mozilla documentation page previously mentioned.

Note: Math.random() does not provide cryptographically secure random numbers. Do not use them for anything related to security. Use the Web Crypto API instead, and more precisely the window.crypto.getRandomValues() method.

而桌機版則是用了 MT19937，理論上取得 624 bytes 的輸出後就可以重建整個 PRNG 的內部狀態 (於是就可以預測後續的 output)，但這代表你要知道其他網站的密碼，這點其實有點困難。

但作者發現 KPM 在產生 MT19937 的 seed 只跟時間有關，超級容易被預測：

So the seed used to generate every password is the current system time, in seconds. It means every instance of Kaspersky Password Manager in the world will generate the exact same password at a given second.

於是可以直接暴力解出所有的可能性：

The consequences are obviously bad: every password could be bruteforced. For example, there are 315619200 seconds between 2010 and 2021, so KPM could generate at most 315619200 passwords for a given charset. Bruteforcing them takes a few minutes.

Hacker News 上有不少陰謀論的討論，像是：

Getting some DUAL_EC prng vibes.

Insert Kaspersky owned by Russia intelligence conspiracy here...

另外 Kaspersky 跟俄羅斯軍方的關係也是很知名，這些東西大概要到十來年後才會知道...

GitHub Copilot 產生出來程式的安全性問題

看到「Encoding data for POST requests」這篇大家才回頭注意到 GitHub Copilot 首頁的範例本身就有安全漏洞：

async function isPositive(text: string): Promise<boolean> {
  const response = await fetch(`http://text-processing.com/api/sentiment/`, {
    method: "POST",
    body: `text=${text}`,
    headers: {
      "Content-Type": "application/x-www-form-urlencoded",
    },
  });
  const json = await response.json();
  return json.label === "pos";
}

其中 text=${text} 是一個 injection 類的漏洞，首頁的範例應該是被挑過的，但仍然出現了這個嚴重的問題，從這邊可以看出 GitHub 與 OpenAI 在這條線上的問題...

又再次看到了 Spectre Mitigation 的效能損失...

Hacker News 首頁上看到的文章，講 Spectre Mitigation 的效能損失：「Spectre Mitigations Murder *Userspace* Performance In The Presence Of Frequent Syscalls」，對應的討論串在「Spectre Mitigations Murder Userspace Performance (ocallahan.org)」。

看起來作者是在調校 rr 時遇到的問題，幾年前有提到過 rr：「Microsoft 的 TTD 與 Mozilla 的 RR」。

對此作者對 rr 上了一個 patch，減少了 mitigation code 會在 syscall 時清掉 cache 與 TLB，這個 patch 讓執行的速度大幅提昇：「Cache access() calls to avoid syscalls」。

另外作者提到了他的硬體是 Intel 的 Skylake，他又再跑一次 pre-patch 與 post-patch 的速度，可以看到在 pre-patch 前，mitigation 會讓系統慢超多 (從 2m5.776s 到 3m19.648s)，而 post-patch 後大幅降低 syscall 的使用，就不會影響那麼多 (從 0m33.422s 到 0m36.160s)。

就目前知道的 mitigation 方式來說，這個猜測應該是對的...

Google Meet 可以走 443/tcp 了

Work from home 期間開會基本上就是幾個視訊軟體換來換去，Zoom 的話公司有買，自己開免費版的時候是 40mins 限制，另外 Slack 的畫面品質不怎麼樣，而 Google Meet 在疫情期間不限制時間，拿來聊天還蠻好用的。

看到「TLS support for Google Meet」這篇，文章裡面提到先前 Google Meet 是用 443/udp 跑 SRTP，這對很多公司的 firewall 需要另外開 (看到這個 UDP port 想到 QUIC 好像也是走這個 UDP port)，在家裡的話應該還好，對於公司的電腦就會麻煩一些。

文章裡提到，這次支援了 TLS (over 443/tcp)：

Some network setups do not work with SRTP over 443 which was preventing Meet calls from connecting. Meet now encapsulates SRTP in TLS which increases overall compatibility. This change will initially be available on the web, and will be available for mobile soon. We’ll announce it on the Google Workspace Updates blog when it’s available.

可以 fallback 回 443/tcp 走 TLS 的話穿透力應該就更好了，不過不知道免費版的有沒有也一起上，這邊只題到了 G Suite 系列會上：

Available to all Google Workspace customers, as well as G Suite Basic and Business customers

上次用 Google Meet 是在雲端聚餐聊天...

AWS KMS 推出 Multi-region keys

這應該是 AWS 被許多大客戶敲碗許久的功能之一，AWS KMS 支援 global key：「Encrypt global data client-side with AWS KMS multi-Region keys」。

以前不支援這個功能時，在加密儲存跨區域的資料會有兩種作法，以 us-east-1 與 ap-northeast-1 為例子來說：

第一種是透過 replication 的概念，檔案內容從 us-east-1 解開後，透過 TLS 傳到 ap-northeast-1 再加密，所以不同區的密文內容是不同的。

第二種是自己抽象一層 AES key，檔案內容都用這把 AES key 加解密，而這把 AES key 則透過不同區的 AWS KMS 保護，但這樣做又要自己搞 key rotation，另外還可能會有 auditing 的問題...

現在 AWS KMS 直接支援就省事很多了：

文章裡面是拿 DynamoDB 當範例，不過其他只要能夠用 AWS KMS 應用應該也能用。

SSH 對傳入參數的 quoting

昨天在 Hacker News 首頁上看到「SSH quoting」這個，看得出來作者被 OpenSSH 玩弄到不要不要的樣子...

先簡單的整理一下：

$ ssh example.com 'cd /tmp; pwd'
/tmp
$ ssh example.com 'bash -l -c "cd /tmp; pwd"'
/tmp
$ ssh example.com bash -l -c "cd /tmp; pwd"  
/home/gslin

第三個指令發生的「預期外的行為」，但寫習慣的人會把指令全部包成一個字串，就很自然的避開這個問題了。當然 OpenSSH 的設計 (讓你不用加 quote 也會動) 的確也是容易中獎的點啦...

Google Web Store 裡的黑暗交易

標題只寫了 Google Web Store，主要是因為瀏覽器市占率的問題，其實是包含 Firefox 的 Add-Ons。

這是在 Hacker News 首頁上看到的：「Many temptations of an open-source chrome extension developer」，講一直會有人來接觸，可以付費給開發者，想要在這些專案裡面放一些「東西」，可能是蒐集資料，可能是強制導到特定的 search engine，也有可能更邪惡...

另外是老規矩，在 Hacker News 上的討論也可以翻一翻，還蠻有趣的：「Many temptations of an open-source Chrome extension developer (github.com/extesy)」。

先大概看一下 Hover Zoom+ 這個套件在 Google Web Store 的安裝數量，大約 30 萬人：「Hover Zoom+」，作者公佈的信件內容裡面有一些包括價錢與目的...

話說回來，Brave 上的 CRX Viewer 還是沒修好啊：「Stopped working with Brave」，要裝新的套件都得另外再拉 crx 檔下來看，麻煩不少...

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

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

從調校 HTTP Server 的文章中學各種奇技淫巧

在「Extreme HTTP Performance Tuning: 1.2M API req/s on a 4 vCPU EC2 Instance」這篇文章裡面，作者在示範各種奇技淫巧調教校 HTTP server。

在 Hacker News 上的討論也蠻有趣的：「Extreme HTTP Performance Tuning (talawah.io)」。

雖然是在講 HTTP server，但裡面有很多東西可以拿出來獨立用。

想特地拿出來聊的大項目是「Speculative Execution Mitigations」這段，作者有些說明，除非你真的知道你在做什麼，不然不應該關掉這些安全相關的修正：

You should probably leave the mitigations enabled for that system.

而作者是考慮到 AWS 有推出 AWS Nitro Enclaves 的前提下決定關掉，但我會建議在 *.metal 的機器上才這樣做，這樣可以避免這台機器上有其他 AWS 帳號的程式在跑。

測試中關了一卡車 mitigation，得到了 28% 的效能提昇：

Disabling these mitigations gives us a performance boost of around 28%.

這其實比預期中多了不少，這對於自己擁有實體機房跑 Intel 平台的使用者來說，很吸引人啊...