apt-get 的安全性漏洞

前幾天寫的「APT 不使用 HTTPS 的說明」的當下就已經有看到在講這個漏洞,但沒讀完就一直放著沒寫:「Remote Code Execution in apt/apt-get」。

漏洞出在實作上的問題,對於 HTTP 重導的程式碼沒有處理好外部字串,在還沒修正的機器上用這個指令關閉 redirect,避免在修正的過程反而被 RCE 打進去:

sudo apt update -o Acquire::http::AllowRedirect=false
sudo apt upgrade -o Acquire::http::AllowRedirect=false

但也不是 HTTPS 就能避免這個問題,因為 HTTPS 連線用的程式碼又是另外一份,裡面不知道有沒有問題 (像是之前經典的 Heartbleed),所以應該還是會繼續爭吵吧...

APT 不使用 HTTPS 的說明

居然有個獨立的網站在說明:「Why does APT not use HTTPS?」。主要是 HTTPS 沒有增加太多保護,但會使得維護的複雜度變高很多。

首先是被竄改的問題,APT 本身就有簽名機制 (參考「SecureApt」),即使 mirror site 被打下來也無法成功竄改內容,反而比起單純的 HTTPS 保護還好。

而對於隱私問題,由於內容是可以公開取得的,這代表可以看封包的大小與流動順序猜測是哪些 package 被下載 (也就是類似「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」這篇提到的方法),加上 APT 這邊還多了時間性的資訊 最近被更新的軟體被下載的機率比較高),所以隱私的保護上其實有限。

而針對攻擊者刻意提供舊版的問題 (某種形式的 replay attack),APT 降低風險的解法是把時間簽進去,當用戶端發現太久沒更新時,就當作過期失效而提出警告。

就以上來看,把所有的 APT 伺服器都加上 HTTPS 的工程太浩大,而得到的效益太小。所以願意提供 HTTPS 的站台就提供,但主要的保護還是從本來的 SecureApt 機制上提供。

Ubuntu 上的 Cron (Vixie Cron 與 Cronie...)

想用 CRON_TZ 這個變數但發現系統不支援 XD

找資料的時候發現一堆奇怪的文章,像是說可以在 Ubuntu 上用 apt install cronie 這種指令安裝 cronie 的,不知道他到底是用什麼系統... (參考「Debian -- Package Search Results -- cronie」與「Ubuntu – Package Search Results -- cronie」,應該是沒出現過?)

在 man cron 時可以看到 Ubuntu 還是用 Vixie Cron,而在 Launchpad 上可以看到,在 2009 年有人提案想要換成 cronie,但一直都沒有下文:「Replace (vixie) cron with cronie」,這麼久完全沒動靜,這大概沒救了 XD

還是乖乖的照 UTC 設吧,只是這樣 Trac 開票的時間好像不太好搞...

Debian 對 Reproducible Build 的討論

Debian 在討論 package 的可重製性:「debian-policy: Packages should be reproducible」。本來的討論其實還好,在 2017/08/12 的 DebConf17 後,看起來有一些人取得共識,於是討論熱了起來... 有興趣的人可以從 Message #107 開始看。

Debian 社群想做的事情是「給足夠的資訊以及 source code,就能產生出一模一樣的 binary package」,這樣就不需要盲目信任 Debian 官方。

Debian 官方的 Wiki 上有「ReproducibleBuilds Howto」可以參考,然後也看到「reproducible-builds.org」這個站。

Debian 的 CloudFront

剛剛看到 Debian Mirrors via CloudFront 這個,原來 AWS 幫忙付掉了:

This service is kindly hosted by and paid for by Amazon Web Services, and we thank them for their contribution to Debian.

翻了 mailing list 發現是在 2013 年五月的時候弄出來的:「Debian archive distribution via CloudFront CDN」。

debootstrap 可以把所有檔案都裝到 /usr 下了

從「You can now try merged /usr in Debian」這邊看到,早期因為硬碟空間比較小的關係,會切成 /bin/usr/lib 之類的目錄:

The original impetus for requiring these directories was due to space limitations in the first Unix implementations, developers favoring the change point out.

這個理由很明顯已經消失了,所以 Debian 就規劃要整併起來...

Debian 提供 Tor Hidden Service 更新 Apt

DebianTor Project 都宣佈了這個消息,兩邊的稿子都一樣:「Debian and Tor Services available as Onion Services」、「Debian and Tor Services available as Onion Services」。

站台列表在 https://onion.debian.org/ 這邊可以看到,當你有安裝 apt-transport-tor 時,可以透過 Tor 更新:

deb tor+http://vwakviie2ienjx6t.onion/debian jessie main
deb tor+http://vwakviie2ienjx6t.onion/debian jessie-updates main
deb tor+http://sgvtcaew4bxjd7ln.onion/debian-security jessie/updates main

Tor Hidden Service 本身就有一定的安全強度,而透過 APT 抓 Debian 套件的安全性還有 GnuPG 驗證把關,這樣看起來頗不賴...

讓 Tor 的流量變大也是讓 Tor 的隱私性變得更好的一種方法 (因為目前看到新的攻擊都是靠分析 traffic pattern,所以流量變大有機會讓雜訊變多一些)。

不知道 Ubuntu 有沒有機會也上一份...

Mozilla 的人提出討論,把 Debian 上的 Iceweasel 改名回 Firefox

2006 年時因為 Mozilla 的人認為 Debian 改了太多東西 (以及其他原因),不應該使用 Mozilla Firefox 這個帶有商標的名稱,要求 Debian 改名 (事情的經過可以參考維基百科上的「Mozilla software rebranded by Debian」條目)。

而在九年後,最近 Mozilla 的人在 Debian 上開了一個 bug report,討論是否還需要維持 Iceweasel 這個名字:「#815006 - Renaming Iceweasel to Firefox」。

Debian 這邊的人也提出了很多不一樣的意見 (尤其是對 Mozilla 的商標使用規範),目前還在爭論...

Google Chrome 將在明年三月停止 32bits Linux 版本支援

在「Google ends 32-bit Linux support for Chrome」這邊看到新聞,引用自「Updates to Google Chrome Linux support」這邊的消息:

To provide the best experience for the most-used Linux versions, we will end support for Google Chrome on 32-bit Linux, Ubuntu Precise (12.04), and Debian 7 (wheezy) in early March, 2016. Chrome will continue to function on these platforms but will no longer receive updates and security fixes.

We intend to continue supporting the 32-bit build configurations on Linux to support building Chromium. If you are using Precise, we’d recommend that you to upgrade to Trusty.

既然還是會支援 32bits 的情況 (透過 Chromium),到時候應該會有 PPA 出來頂著讓大家用?

對 GitHub 的 Public Key 分析

Hacker News Daily 上看到有人針對 GitHub 上的 Public Key 分析:「Auditing GitHub users’ SSH key quality」。

這個分析主要用的是 GitHub 的 .keys 功能取得:

A little known feature of GitHub is the ability to look at the public SSH keys that other users have set to be authorised on their account (for example https://github.com/torvalds.keys)

作者從去年 2014 年 12 月 27 日跑到今年 2015 年 1 月 9 日,共取得了 1376262 把 public key,然後就針對這些 key 分析。

「The Debian bug bites again」這一段講的是 CVE-2008-0166 (可以參考「該換 ssh keys 了」這篇的說明),發現即使是七年後的現在,也還是有問題。

另外還有 256 bits 與 512 bits 的 RSA key,作者自己建立了一把測試,用 i5-2400 只要 25 分鐘就可以解出 256 bits 的 private key:

This risk isn’t only real if someone had gathered together top of the line mathematicians or supercomputers worth of power, the 256 bit key I factored was factored on a i5-2400 in 25 mins.

NSA 應該都摸透了...

作者提供的時間線:

[27th December 2014] Key Crawl Started
[28th Feb 2015] Disclosed low bits issue to a peer at GitHub
[1st March 2015] Discovered the weak Debian Keys (and disclosed)
[5th May 2015] Debian keys revoked, emails sent out
[1st June 2015] Weak and low quality keys revoked