Posted on
by

這篇文章是閱讀了 Kuon Ding 在 COSCUP 2016 發表的演講簡報「開源編譯器，如何實現系統安全最後一哩路」的一點想法。因為 COSCUP 一直待在場外聊天，未進入演講廳聽講，這些心得僅僅參考投影片的資訊。

私認為資訊安全沒有最後一哩路[1]，需要保持紀律的環環層層不停的造橋鋪路。

這場演講分享了開放原始碼編譯工具針對系統安全的發展，編譯工具的確是重要一環，以 Ubuntu 為例[2]， gcc 的 Stack Protector、built as PIE for exec ASLR、Fortify Source、Read-only relocation 都做額外的補釘加強安全性。然而 toolchain 不能提供獨立的安全保護，像是 Address Space Layout Randomization (ASLR) 必須是從 kernel 層做的。不管是融合桌面、手機環境的 Ubuntu 或是以手機為主的 Android 而言，安全性的發展都是盡可能的降低攻擊範圍(attack surface) 並層層疊加安全限制。

以最近發布的 Android 7[7][8] 為例子，針對系統面的保護改進用 SELinux 與 seccomp sandboxing 中減少 ioctl 的白名單呼叫範圍、 Library ASLR[3]、從 Grsecurity 學來的 CONFIG_DEBUG_RODATA 等等。這些都一步步的減少了攻擊暴露範圍。

舉例而言，文中提到了像是 2016/08 的 DEFCon 24 發布的 QuadRooter 相關漏洞[4]，許多都是來自 SoC 的程式碼設計缺陷所造成，而這些缺陷很難透過代碼審查的方式查出，特別是由於智慧產權的限制，很多有問題的驅動程式是以二進位檔散布的，作業系統廠商或終端硬體品牌商是拿不到原始碼的。這些只能透過系統安全機制[15]來防護。

如 QuadRooter 中提到的 CVE-2016-2059: Linux IPC router binding any port as a control port，這個攻擊的前提是系統關掉 kASLR[5]，然後才有機會做 Heap Spraying，但是要再拿到 root 還得關閉 SELinux 才行。而攻擊第一步 iocl 命令是可以透過 SELinux Policy 抑制的，例如 CVE-2016-0820 中，MediaTek 的 WiFi 驅動程式的 private ioctl 漏洞，可以關掉一般程式存取 device private commands[6].

編譯器未能防止類似的問題，必須依賴其他機制來保護系統。

編譯器[9]實踐的 KAsan (Kernel Address Sanitizer)[21] 功能可以查找 QuadRooter 中 CVE-2016-2503/CVE-2016-2504 等 use-after-free attack[22] 問題，但是一樣需要核心的支援[10]。而這個在 4.4 中的功能能夠發送到使用者手上尚須要一段時間[14]，不僅僅是更新 toolchain 重新編譯即可。

不是所有的理論技術都可以在安全、便利性、效能上帶來好處，作業系統往往必須做出取捨。

  • 例如啟動了投影片中[1]提到 vtable verification feature[27]，這個功能會讓一些重要的軟體如 Firefox 炸掉[11]，因為開發者會對 vtable 用一些奇計淫巧。
  • 例如前述的 Ubuntu 中的 built as PIE 在 i686 平台上會造成 5-10% 的效能損失[12]，只能挑某些重要的庫使用。到 16.10 才因為 64 bit 環境成熟而預設啟用。
  • 例如啟動了 Kernel Address Space Layout Randomisation (kASLR) 後，在 x86 上就無法讓電腦休眠[13] ，對沒電時需要緊急休眠的筆記型電腦使用者是無法接受的。

每項安全設計都不能只從單方面來看，需要全局的評估。有些無法在編譯器中實踐的功能，可以在 kernel 中完成，kenrel 的問題可以透過 app sandboxing 來補強。

而最近幾年的作業系統發展趨勢以 Isolation (Sandboxing) 為方向，像是 Android 使用 Selinux 的 Sandbox、ChoromeOS 中使用 Minijail[16]，Linux Desktop 上的 xdg-app/Flatpak[17][18]，以及 Ubuntu 使用 Snappy (Apparmor)[19][20] 等等技術。除了 Linux 以外，Apple OSX 基於 TrustedBSD Mandatory Access Control (MAC) Framework 的 Sandbox[23][24][25], 以及 Microsoft 的 Windows Runtime sandbox[26] 等等。這些系統的設計都是為了保護使用者的資料，除了防止惡意程式之外，如果程式遭到破解，所能造成的破壞也會被侷限在沙箱內。

最大的挑戰之一，或許是針對新的 security model 設計具備彈性 API，以及在多重限制的運行環境下仍可提供友善便利的使用者體驗吧。

[1] 開源編譯器，如何實現系統安全最後一哩路 by Funny Systems – https://speakerdeck.com/FunnySystems/kai-yuan-bian-yi-qi-ru-he-shi-xian-xi-tong-an-quan-zui-hou-li-lu
[2] https://wiki.ubuntu.com/Security/Features
[3] Implement Library Load Order Randomization – https://android.googlesource.com/platform/bionic/+/4f7a7ad3fed2ea90d454ec9f3cabfffb0deda8c4%5E%21/
[4] QuadRooter Research Report – https://www.checkpoint.com/downloads/resources/quadRooter-vulnerability-research-report.pdf
[5] Kernel address space layout randomization [LWN.net] – https://lwn.net/Articles/569635/
[6] Only allow shell user to access unprivileged socket ioctl commands. – https://android.googlesource.com/platform/external/sepolicy/+/57531ca%5E%21/
[7] Security | Android Open Source Project – https://source.android.com/security/
[8] Security Enhancements in Android 7.0 | Android Open Source Project – https://source.android.com/security/enhancements/enhancements70.html
[9] [ASan] Initial support for Kernel AddressSanitizer · llvm-mirror/llvm@e9149f4 – https://github.com/llvm-mirror/llvm/commit/e9149f4f8cd3b915ada134d80452c6eae7875ca4
[10] KASan support for arm64 – http://lkml.iu.edu/hypermail/linux/kernel/1511.0/02583.html
[11] Crash in mozJSComponentLoader::ModuleEntry::GetFactory when compiled with GCC 4.9.0 and VTV – https://bugzilla.mozilla.org/show_bug.cgi?id=1046600
[12] PIE has a large (5-10%) performance penalty on architectures with small numbers of general registers (e.g. x86) – https://wiki.ubuntu.com/Security/Features#pie
[13] Prefer kASLR over Hibernation – Patchwork – https://patchwork.kernel.org/patch/8765121/
[14] KASan support for arm64 – http://lkml.iu.edu/hypermail/linux/kernel/1511.0/02583.html
[15] Google Online Security Blog: Protecting Android with more Linux kernel defenses – https://security.googleblog.com/2016/07/protecting-android-with-more-linux.html
[16] Chromium OS Sandboxing – The Chromium Projects – https://www.chromium.org/chromium-os/developer-guide/chromium-os-sandboxing#h.l7ou90opzirq
[17] Projects/SandboxedApps – GNOME Wiki! – https://wiki.gnome.org/Projects/SandboxedApps
[18] Sandbox · flatpak/flatpak Wiki – https://github.com/flatpak/flatpak/wiki/Sandbox
[19] snapcraft – Snaps are universal Linux packages – http://snapcraft.io/
[20] Snappy Interfaces | Labix Blog – http://blog.labix.org/2016/04/22/snappy-interfaces
[21] Kernel Address Sanitizer – https://github.com/google/kasan/wiki
[22] Four new Android privilege escalations [LWN.net] – https://lwn.net/Articles/696716/
[23] The Apple Sandbox https://media.blackhat.com/bh-dc-11/Blazakis/BlackHat_DC_2011_Blazakis_Apple%20Sandbox-Slides.pdf
[24] The Apple Sandbox https://media.blackhat.com/bh-dc-11/Blazakis/BlackHat_DC_2011_Blazakis_Apple_Sandbox-wp.pdf
[25] SandBlaster: Reversing the Apple Sandbox – https://arxiv.org/pdf/1608.04303.pdf
[26] WinRT: The Metro-politan Museum of Security https://conference.hitb.org/hitbsecconf2012ams/materials/D1T2%20-%20Sebastien%20Renaud%20and%20Kevin%20Szkudlapski%20-%20WinRT.pdf
[27] Improving Function Pointer Security for Virtual Method Dispatches https://gcc.gnu.org/wiki/cauldron2012?action=AttachFile&do=get&target=cmtice.pdf