Slack 要拿使用者資料訓練 AI

在「Slack AI Training with Customer Data (slack.com)」這邊看到的,原公告在「Privacy Principles: Search, Learning and Artificial Intelligence」這邊。

預設會被丟進去訓練,Opt-out 無法直接設定,需要透過 e-mail 寫信找 feedback@slack.com (yeah,dark pattern):

Contact us to opt out. If you want to exclude your Customer Data from Slack global models, you can opt out. To opt out, please have your Org or Workspace Owners or Primary Owner contact our Customer Experience team at feedback@slack.com with your Workspace/Org URL and the subject line “Slack Global model opt-out request.” We will process your request and respond once the opt out has been completed.

拿企業資料來搞事嗎... 這應該已經不只是 privacy 議題而是 security 層面了,PR 層面鐵定很難看,來看後面會不會轉彎?

Amazon S3 改變 403 的收費方式

這算是一連串的故事,首先是四月底的時候「How an empty S3 bucket can make your AWS bill explode」這篇,提到了他一個晚上收到了 US$1,300 的帳單,因為有人 (沒有權限的人) 對他的 S3 bucket 狂打了 100M requests (一億筆),雖然都是 403 的 access denied,但還是得付 request 與頻寬的費用。

對於想要搞的人來說,us-east-1 的 Amazon S3 費用是 $0.005/1K requests (PUT, COPY, POST, LIST requests),換算大一點的單位是 $5/1M requests,拿個 ab 之類的工具超級簡單就可以打出破千 reqs/sec,如果是 k6 之類的工具,其實一台電腦就蠻容易打爆?

作者聯絡 AWS 客服後,客服回答你需要付這筆費用 (「這不是 bug,是 feature」):

Yes, S3 charges for unauthorized requests (4xx) as well[1]. That’s expected behavior.

然後這件事情就在社群傳開了,傳到 Jeff Barr 後直接公開提到他認為客戶不應該付 unauthorized request 的 cost (應該是先跟內部其他高層討論過了),等於是宣佈了會改掉:

不過這件事情之前應該就有人提過了,結果 Colin Percival 直接戳,他在 2006 年 Amazon S3 剛出來的時候就提過了:

Anyway,兩個禮拜過去後,剛剛看到宣佈收費方式修改:「Amazon S3 will no longer charge for several HTTP error codes」。

針對從不屬於自己帳號所產生的 403 不收費 (包括 request 與頻寬費用):

With this change, bucket owners will never incur request or bandwidth charges for requests that return an HTTP 403 (Access Denied) error response if initiated from outside their individual AWS account or AWS Organization.

然後多了一頁「Billing for Amazon S3 error responses」專門說明這件事情,這邊列的比較完整,除了 403 以外也包含了其他的 HTTP response code 是不收費的:

The current page shows a full list of HTTP 3XX and 4XX status codes that won't be billed.

補了一個 18 年的洞...

XZ 的後門事件,以及 OpenJS Foundations 也遇到類似的問題

XZ 的後門事件從暴發出來也已經一個多月了,大多數的證據也都分析的差不多了,是差不多可以回顧一下... 然後發現維基百科上面也已經有條目了:「XZ Utils backdoor」,中文版也有:「XZ实用程序后门」。

這次是 open source community 遇到社交工程 (social engineering) 的攻擊,攻擊者順利透過社交手法取得 maintainer & developer 的身份,接下來是慢慢埋 backdoor 的過程。

目前看起來後門是判斷特定的 SSH key 就放行,所以屬於 RCE 類的漏洞,CVSS 給了 10.0 的最高威脅分數。

另外隔壁棚 OpenJS Foundations 也遇到類似的問題:「Open Source Security (OpenSSF) and OpenJS Foundations Issue Alert for Social Engineering Takeovers of Open Source Projects」,在「Failed Credible Takeover Attempt」這段有提到因為 OpenJS Foundations 是因為 security working group 擋下這次的 social engineering。

這是 xz 因為是 backdoor,所以在 performance profiling 時異常而被抓出來,如果是 exploitable 的話就難抓了... 這次的 social engineering 之後有看到一些不同的討論,有些是技術上把 security auditing 拆出來一起做,另外一種是要確保參與的 maintainer & developer 的真實身份。

已經可以看到影響了...

Route 53 Resolver DNS Firewall 的 chain 處理

在「Stop the CNAME chain struggle: Simplified management with Route 53 Resolver DNS Firewall」這邊看到的新功能。

說實話... 我早就忘記 Route 53 Resolver DNS Firewall 這個產品了,我查資料才發現我在 2021 年的時候寫過:「AWS 推出 Amazon Route 53 Resolver DNS Firewall」。

這個產品的用途是避免透過 DNS 將敏感資訊打出去,不過先前的產品的條件很死,遇到 CNAME 或是 DNAME 的情況,你必須事先把可能後續的 record 也放進白名單才行,所以如果遇到類似於 X (Twitter) 用的 pbs.twimg.com 的情況就很麻煩了:

;; ANSWER SECTION:
pbs.twimg.com.          300     IN      CNAME   cs196.wac.edgecastcdn.net.
cs196.wac.edgecastcdn.net. 3409 IN      CNAME   cs2-wac.apr-8315.edgecastdns.net.
cs2-wac.apr-8315.edgecastdns.net. 110 IN CNAME  cs2-wac-us.8315.ecdns.net.
cs2-wac-us.8315.ecdns.net. 110  IN      CNAME   cs45.wac.edgecastcdn.net.
cs45.wac.edgecastcdn.net. 725   IN      A       117.18.237.70

理想上是你放行 pbs.twimg.com 就好,但因為 CNAME 的關係,你可能會需要多放行 *.edgecastcdn.net 以及 *.ecdns.net

可是這是第三方的服務,你無法控制對方怎麼切換 (沒有 API contract 的概念),像是有時候他會跳到 Fastly

;; ANSWER SECTION:
pbs.twimg.com.          290     IN      CNAME   dualstack.twimg.twitter.map.fastly.net.
dualstack.twimg.twitter.map.fastly.net. 290 IN A 151.101.40.159

如果之後又跑出 Akamai 或是 CloudFront 的話就沒完沒了。

另外一種常見的情況是第三方的 API endpoint,對方有可能有多個不同的點做 DR 切換,有可能 CNAME 到 AWSELB 或是 GCPCloud Load balancing 上。

所以為了「保險」,這個方式通常都是開整個 CDN 的服務,但這麼一來攻擊者可以透過租用這些服務 (像是 *.cloudfront.net),搭配一些其他比較鬆的 rule 鑽出來。

這次的這個功能有點 stateful firewall 的概念,第一個啟動的 record 是被放行的,那 CNAME 或是 DNAME 延伸出來的 record 也跟著放行,這樣算是補強了這個問題...

Ubuntu 的 LTS 從 10 年變成 12 年

積了一個多月的東西,Canonical 宣佈 UbuntuLTS 從 10 年變成 12 年 (付費版本):「Canonical expands Long Term Support to 12 years starting with Ubuntu 14.04 LTS」,這個改變會包括 (三月當時) 快要滿十年的 14.04 (trusty) 以及之後的版本:

Today, Canonical announced the general availability of Legacy Support, an Ubuntu Pro add-on that expands security and support coverage for Ubuntu LTS releases to 12 years. The add-on will be available for Ubuntu 14.04 LTS onwards.

應該是被不少既有客戶要求後發現有市場,所以就決定先延個兩年看看?

寫這篇才意外注意到 Ubuntu 14.04 到現在也已經十年了,這幾天在看 Travis CI 的資料,發現這個平台支援一堆古董,可以看到 Ubuntu 12.04 (precise) 的 image,而且最新也才支援到 Ubuntu 20.04 (focal):「Build Environment Overview」。

OpenSSL 決定把 release site 改到 GitHub 上

OpenSSL 宣佈了之後會以 GitHub 為主要發佈平台:「Releases Distribution Changes」。

舊的 ftp & rsync 以及 git protocol (9418/tcp 的協定) 都打算淘汰掉:

We’re no longer using our old ftp, rsync, and git links for distributing OpenSSL. These were great in their day, but it’s time to move on to something better and safer.

其中 FTP 與 rsync 都已經停掉了,接下來是今年六月要停掉 ftp.openssl.org 的 HTTPS 介面以及 git.openssl.org 的 git protocol:

ftp://ftp.openssl.org and rsync://rsync.openssl.org are not available anymore. As of June 1, 2024, we’re also going to shut down https://ftp.openssl.org and git://git.openssl.org/openssl.git mirrors.

然後主力轉戰到 GitHub 上面:

GitHub is becoming the main distributor of the OpenSSL releases.

算是省事的作法,畢竟自己弄 infrastructure 不算太輕鬆

另外 OpenSSL 畢竟是個歷史頗久的軟體了,有「遵循古法」所以 release 都會有 PGP/GPG sign,這部分如果還是獨立於 GitHub 平台的話就沒什麼問題,代表還是有非 HTTPS 的 integrity 方法可以確認檔案沒被抽換過。

(但如果綁進 CI/CD 流程的話就廢了?)

Chrome 124 啟用了 X25519Kyber768

在「Google Chrome's new post-quantum cryptography may break TLS connections」這邊看到的,出自「Q1 2024 Summary from Chrome Security」這邊的公告。

Chrome 124 預設啟用 X25519Kyber768 了:

After several months of experimentation for compatibility and performance impacts, we’re launching a hybrid postquantum TLS key exchange to desktop platforms in Chrome 124. This protects users’ traffic from so-called “store now decrypt later” attacks, in which a future quantum computer could decrypt encrypted traffic recorded today.

如果遇到問題的話可以在 chrome://flags 裡面的 #enable-tls13-kyber 關閉後重開瀏覽器... 不過應該是還好,大多數的 HTTPS server 應該都沒有實作 X25519Kyber768,就算是 Cloudflare 應該預設也是關的。

WordPress 要放掉 PHP 7.0 與 PHP 7.1 的支援了

WordPress 說要放掉舊版的 PHP,本來看到標題在想是 PHP 8.0 與 PHP 8.1,仔細看才發現是 PHP 7.0 與 PHP 7.1:「Dropping support for PHP 7.0 and 7.1」。

從「PHP 7 ChangeLog」這邊可以看到 PHP 7.0.0 與 7.1.0 分別是 2015 年十二月與 2016 年十二月的事情了... 印象中這是 PHP 效能飛越性提升的年代,從 7.0、7.1、7.2、7.3 到 7.4 都有顯著的改善:「PHP Benchmarks 7.4 vs 7.3 vs 7.2 vs 7.1 vs 7.0 (php-fpm)」。

Internet Archive 上面的「Supported Versions」可以看到 7.0 與 7.1 分別在 2019 年初與 2019 年年底終止維護,離現在差不多是 5 年與 4 年了。

沒注意到 WordPress 還有支援這麼舊的版本,大概是為了一些八百年沒更新的 PHP hosting...

jQuery 官方鼓勵大家記得使用新版的 jQuery...

的確是很多人掛完 jQuery 後就沒動過了:「Upgrading jQuery: Working Towards a Healthy Web」。

jQuery 官方提供的三個切入點都是安全性的問題,Security Vulnerabilities、Security Best Practices 以及 Compliance Requirements。

相容性是 jQuery 的強項,有些 deprecated 的功能,官方還是有提供 jQuery Migrate 讓這些功能先補回來繼續用。

目前 jQuery 3.x 支援的瀏覽器環境,以今天的角度來看其實還是很誇張:「Browser Support」,桌機上有 IE9+ (在 Windows Vista SP2 以及之後的版本),而行動裝置上 Android 是 4.0+ (2011 年),Safari 是 iOS 7+ (iPhone 4,CDMA 版 2011 年)。

即使是 jQuery 4 (目前是 beta,參考「jQuery 4.0.0 BETA!」) 也還是支援 IE11 (Windows 7 SP1),算是對於舊系統照顧的很好的 javascript library。

Python 2.7 的延伸支援

Python 2 在大約四年前 2020/04/18 推出了最後一版 Python 2.7.18 後,後續的安全性更新就變成要找第三方支援了。

在 2023/09 出的 Trac 1.6 總算是換到 Python 3 後,手上就沒有遇到要用 Python 2.7 的東西了...

剛剛在「PyPy v7.3.16: release of python 2.7, 3.9, and 3.10」這邊看到跟 Python 2.7 有關的消息,一時興起翻了翻有哪些延長的商業支援可以買,看起來有兩個:

真的遇到的話再來寫信問問看好了...