カーゴカルト・セキュリティ KASLR

a guest Oct 19th, 2013 359 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  3. KASLR: An Exercise in Cargo Cult Security
  4. KASLR: カーゴカルト・セキュリティの実践
  6. by spender ≫ Wed Mar 20, 2013 6:46 pm
  8. Since this post about Kernel Address Space Layout Randomization (KASLR) extends beyond a critique of the feature itself and into a commentary on the state of commercial defensive security and how it is evaluated both by the security community and by end-users, I asked the PaX Team to contribute some valuable context to the discussion. As the creator of ASLR in 2001, he shares below some history and motivations for ASLR at the time. His exploit vector classification and ASLR analysis cover important nuances and fundamental truths lost in the barrage of "bypasses" in the industry. I continue later in more depth under the heading "Why KASLR is a Failure".
  9. 今回の Kernel Address Space Layout Randomization (KASLR) に関する記事は、機能そのものに対する批評を超えて、商業的なセキュリティ防御のありさまを解説し、セキュリティ・コミュニティおよびエンドユーザ双方からの評価にまで展開するものなので、まずは PaX Team に頼んで議論の背景について役立つ情報をいくらか提供してもらった。PaX Team は 2001 年に ASLR を造り出した張本人としての立場から、ASLR の歴史の一部と、当時 ASLR が必要とされた理由を以下に説明してくれている。そこに示された攻撃ベクタの分類や ASLR の分析には、産業界では「手抜き」の連発で見えなくなっている重要なニュアンスや基礎的な真理が包含されている。続いて私 (spender) が、「KASLR がコケる理由」という見出しのもとで、より深く掘り下げる。
  11. Before talking about KASLR it seems high time that we revisited a little history regarding ASLR itself. About 12 years ago PaX had already proved that there was in fact a practical way to prevent code injection attacks, the prevalent exploit technique against memory corruption bugs at the time (and even today thanks to the widespread use of JIT compiler engines). It was also clear that the next step for both sides would be to focus on executing already existing code, albeit in an order not intended by the programmer of the exploited application (the market word for this is ROP/JOP/etc). Much less relevant back then but there was always the possibility to exploit these bugs by merely changing data and without disturbing the program logic directly (data only attacks, [1] [2]). Foreseeing these future developments in practical exploit techniques made me think whether there was perhaps some general way to prevent them or at least reduce their effectiveness until specific reliable and practical defenses could be developed against the remaining exploit techniques (it was clear that such defenses wouldn't come by as easily as non-executable pages, and alas, in 2013AD nobody has still much to show). In other words, ASLR was always meant to be a temporary measure and its survival for this long speaks much less to its usefulness than our inability to get our collective acts together and develop/deploy actual defenses against the remaining exploit techniques.
  12. KASLR について語る前に、カーネルに限らない ASLR 自体の歴史を振り返っておくのが良いだろう。およそ 12 年前、PaX はすでにコード・インジェクション攻撃を防ぐ実用的な手法が存在することを証明していた。コード・インジェクション (挿入) は、メモリ破壊バグを標的とする、当時よく見られた (そして今も JIT コンパイラ・エンジンの普及により広く見られる) 攻撃テクニックだ。それで攻守どちらの側も、次は既存コードを本来の意図に反した順序で実行することに焦点を当てるのが自然な流れだった (業界用語ではこれを ROP とか JOP などという)。今よりずっと非現実的だったとはいえ、プログラムのロジックを直接に乱すことなく、データを変更するだけでメモリ破壊バグを悪用できてしまう可能性は、当時も常に存在していた (データオンリー攻撃 [1][2])。実用的な攻撃テクニックが将来開発されるであろうことを予想していた私は、それを完全に防御する方法がないだろうか、あるいはせめて、攻撃テクニックに対して具体的で確実かつ実用的な防御が開発されるまで攻撃の効率を悪くしておく方法がないだろうか、と考えざるを得なかった (そうした防御法は、非実行属性ページのように簡単には思いつかないだろうと思われていたが、なんと 2013 年の今なお誰も、たいした案を出していない)。言いかえると、ASLR は「その場凌ぎ」のつもりであって、それがここまで長く生き残っているというのは、それだけ有用だったというのでは全然なくて、むしろ我々が力を合わせて攻撃テクニックへの現実的な対抗策を開発・実施できなかったことを物語っている。
  14. In any case, thus was the concept of ASLR born which was originally called (for a whole week maybe ;)) ASR for Address Space Randomization (the first proof of concept implementation did in fact randomize every single mmap call as it was the simplest implementation).
  15. いずれにせよ、こうして ASLR の概念が誕生した。ただし、もともとは Address Space Randomization (最初のデモ実装は本当に mmap を呼ぶたび毎回ランダマイズするという単純なものだった) から ASR と呼ばれていたのだが (一週間はそう呼ばれていたんじゃないかな……)。
  17. The concept was really simple: by randomizing memory addresses on a per process basis we would turn every otherwise reliable exploit needing hardcoded addresses into a probabilistic one where the chances of success were partially controlled by the defense side. While simple in concept and implementation, ASLR doesn't come without conditions, let's look at the them briefly. For ASLR to be an effective prevention measure the following must hold:
  18. その概念は実に単純だ: プロセスごとにメモリアドレスをランダマイズすることによって、それまではハードコードのアドレスで 100% だった攻撃の成功率を、ある程度、防御側から制御できるようにするのだ。ただ、ASLR は概念も実装も単純なのだが、無条件で成立するわけではない。ざっと見てみよう。ASLR が効果的な防御手段となるためには:
  20. 1. the exploit must have to know addresses from the exploited process (there's a little shade of grey here in that, depending on the situation, knowledge of partial addresses may be enough (think partial or unaligned overwrites, heap spraying), 'address' is meant to cover both the 'full' and 'partial' conditions),
  21. 1. 攻撃がその対象プロセスからアドレスを手に入れることになっている必要があり (ここには、状況によりアドレスの一部だけで足りる (partial overwrite 攻撃や unaligned overwrite 攻撃、ヒープスプレー攻撃を考えるとよい) という曖昧な部分があるが)、
  23. 2. the exploit must not be able to discover such addresses (either by having the exploited application leak them or brute force enumeration of all possible addresses)
  24. 2. そのアドレスを (対象アプリケーションからリークさせたり、アドレス全体をブルートフォースしたりして) 見つけ出すことは不可能である必要がある。
  26. These are conditions that are not trivially true or false for specific situations, but in practice we can go with a few heuristics:
  27. これらは簡単に「真」や「偽」と言えるような条件ではないが、経験に基づいていくつか推測することはできる。
  29. 1. remote attacks: this is the primary protection domain of ASLR by design because if an exploit needs addresses at all, this gives an attacker the least amount of a priori information. It also puts a premium on infoleaking bugs on the attack side and info leak and brute force prevention mechanisms on the defense side.
  30. 1. リモート攻撃: これが設計上 ASLR の主要な防御分野である。というのも、ある攻撃にアドレスが必要だとすれば、ASLR こそ攻撃者に渡す事前情報を最小限にするものだからだ。攻撃側は情報リーク型バグに、防御側は情報リークとブルートフォースの防止機構に焦点を移すことにもなる。
  32. 2. local attacks: defense relying on ASLR here faces several challenges:
  33. 2. ローカル攻撃: この場合 ASLR に頼った防御にはいくつか問題がある:
  35. - kernel bugs: instead of attacking userland it is often better to attack the kernel (the widespread use of sandboxes often makes this the path of least resistance) where userland ASLR plays a secondary role only. In particular it presents a challenge only if exploiting the kernel bug requires the participation of userland memory, a technique whose lifetime is much reduced now that Intel (Haswell) and ARM (v6+) CPUs allow efficient userland/kernel address space separation.
  36. - カーネルのバグ: ユーザランドを攻めるよりもカーネルを攻めたほうが良いことがしばしばある (サンドボックスの利用が広まって、ここが最も楽な経路になることが増えている) ので、そういった場面でユーザランド ASLR は副次的な役割しか担っていない。具体的には、カーネルのバグを悪用するためにユーザランドのメモリ関与が必要という場合にしか妨害にならないが、そうした攻撃テクニックの寿命は、Intel (Haswell) や ARM (v6以降) の CPU がユーザランドとカーネルのアドレス空間分離を実現している今、風前のともしびだ。
  38. - information leaks: the sad fact of life is that contemporary operating systems have all by design features that provide address information that an exploit needs and it's almost a whack-a-mole game to try to find and eliminate them. Even with such intentional leaks fixed or at least worked around there's still kernel bugs left that leak either kernel or userland addresses back to the attacker. Eliminating these didn't receive much research yet, the state-of-the-art being grsecurity but there is still much more work in this area to be done.
  39. - 情報リーク: 世界は残酷だ。現代の OS にはすべて最初から (攻撃に必要な) アドレス情報を提供する機能が備わっており、それを駆逐するのはモグラたたきみたいなものだ。そうした意図的なリークに修正が、せめて回避策ができたとしても、それでもカーネルのバグが残っていて、カーネルやユーザランドのアドレスを攻撃者にリークしてしまう。こうしたリークの殲滅については研究がまだ十分なされておらず、最先端の grsecurity といえども、この分野にはまだ宿題がたくさん残っている。
  41. So how does KASLR relate to all this? First of all, the name itself is a bit unfortunate since what is being randomized is not exactly what happens in userland. For one, userland ASLR leaves no stone unturned so to speak. That is, a proper ASLR implementation would randomize all memory areas and would do so for every new process differently. There is no equivalent of this mechanism for a kernel since once booted, the kernel image does not change its location in memory nor is it practically feasible to re-randomize it on every syscall or some other more coarse-grained boundary. In other words, it's as if in userland we applied ASLR to a single process and kept running it indefinitely in the hope that nothing bad would happen to it. At this rate we could call the long existing relocatable kernel feature in Linux KASLR as well since it's trivial to specify a new randomly chosen load address at boot time there.
  42. では KASLR は、このすべてとどう関係してくるのか? まず第一に、名前そのものが少々不適切だ。ランダマイズされるものがカーネルとユーザランドで完全に一致するわけではないからだ。たとえばユーザランド ASLR は、やれることを全部やる。つまり適切な ASLR 実装であれば、メモリ全体をランダマイズするし、新しいプロセスごと別々にそうする。しかしカーネルにはそれに相当する仕組みがなく、いったん起動するとメモリ内におけるカーネルイメージの位置は変わらないし、システムコールごと、あるいはもっと粗挽きの区切りごとに再ランダマイズするというのも実用上は無理な話だ。言いかえると、まるでユーザランドで単一プロセスに ASLR を適用してそのまま、「何事も起こりませんように」と願いながら永久に実行し続けるようなものだ。こんな調子では、ずっと前からある Linux の relocatable kernel 機能でさえも KASLR と呼べることになる。起動時に新しくランダムなロードアドレスを指定するのは簡単なことだからだ。
  44. Second, the amount of randomization that can be applied to the base address of the kernel image is rather small due to address space size and memory management hardware constraints, a good userland ASLR implementation provides at least twice the entropy of what we can see in KASLR implementations. To balance this deficiency there's usually already some form of inadvertent brute force prevention present in that most kernels usually don't recover from the side effects of failed exploit attempts (Linux and its oops mechanisms being an exception here).
  45. 第二に、カーネルイメージのベースアドレスに適用できるランダマイズ量は、アドレス空間やメモリ管理ハードウェアの制約により、かなり小さい。ちゃんとしたユーザランド ASLR の実装は KASLR の二倍以上のエントロピーを提供する。この不足を埋め合わせるため、たいていは何らかの「うっかりブルートフォース」防止機能がすでにあるが、そのせいで多くのカーネルは、攻撃が失敗したときの副作用から立ち直れない (Linux とその oops 機構は例外である)。
  47. Third and probably the biggest issue for KASLR is its sensitivity to even the smallest amounts of information leaks, the sheer amount of information leaking bugs present in all kernels and the almost complete lack of prevention mechanisms against such leaks.
  48. 第三の、そしておそらく KASLR 最大の問題は、ほんの少しの情報リークで無意味になってしまうこと、そしてカーネルすべてに膨大な数の情報リーク・バグがあることと、そうしたリークを防ぐ仕組みがほとんどまったく存在しないことだ。
  50. This situation came about because historically there was no interest until very recently in finding such bugs let alone systematically eliminating them or preventing their effects (except on hardened systems such as grsecurity, recognizing this fact early is the reason why we've been working on this problem space for many years now). Based on our experience with Linux, this will be a long drawn out uphill battle until such bugs are found or at least their effects neutralized in KASLR based kernels.
  51. こんなことになってしまったのは、ごく最近まで、こういうバグを体系的に駆逐したり無効化したりはもちろんのこと、探すことにさえ関心が払われていなかったという歴史があるからだ (grsecurity のような hardened systems はそれと異なり、早くから問題を認識していたので、着手してもう何年にもなる)。Linux における我々の経験からすると、こういったバグを見つけたり、せめて KASLR カーネルに効果が出ないようにしたりするまでの戦いは、長く苦しいものになるだろう。
  53. Why KASLR is a Failure
  54. KASLR がコケる理由
  56. Continuing where the PaX Team left off, it should begin to become clear that ASLR has been taken out of the context of its original design and held on a pedestal as something much more than what it was originally intended as: a temporary fix until more effective measures could be implemented (which have much less to do with difficulty than the lack of resources on our side).
  57. PaX Team に続いては、ASLR が設計当時の文脈から切り離されて、本来意図されていたものよりずっと大きな台座に据えられていることをハッキリさせることから始めよう。本来の意図とは、より効果的な手法が実装されるまでの一時凌ぎだ (この齟齬は、問題の難しさというよりは我々の側のリソース不足によるところがずっと大きい)。
  59. Information leakage comes in various forms. For our purposes here we'll consider two types of leakage: addresses and content, the former being a subset of the latter. The leaks can have spatial locality (say by leaking a string whose null terminator has been overwritten), be constrained in some other way (say due to an incomplete bounds check), or be completely arbitrary. They can also be active (by creating a leak) or passive (e.g. uninitialized struct fields). Fermin J. Serna's 2012 talk, "The info leak era on software exploitation" [3] covers lots of background information and common vulnerabilities and techniques as they pertain to userland.
  60. 情報リークは色々なかたちをとる。今回の記事に合わせて、ここでは二種類のリークを検討しよう: アドレスとコンテンツ、前者は後者のサブセットだ。リークは局所性があったり (たとえば終端文字を上書きされた文字列をリークした場合)、ほかの制約があったり (たとえば境界チェックが不完全な場合)、まったく任意だったりする。また、能動的 (リークを引き起こす) だったり受動的 (未初期化の構造体フィールドなど) だったりする。Fermin J. Serna の 2012 年の講演「ソフトウェア攻撃による情報リーク時代」[3] は、数々の背景情報やよくある脆弱性および攻撃手法を、ユーザランドに関して網羅している。
  62. The KASLR implementations of Microsoft and Apple operate in an environment where the kernel is a known entity whose contents can be obtained in a variety of ways. While on a custom-compiled Linux kernel set up properly, both the content and addresses of the kernel image are secret, for Microsoft and Apple the contents of the kernel image are known. To use "ROP" against the kernel, one needs to know not only the address of what one is returning to, but also what exists at that address. So the only "secret" in KASLR is the kernel's base address. It follows from this that any known pointer to the kernel image reveals its base address.
  63. Microsoft と Apple の KASLR 実装は、カーネルが既知、すなわちそのコンテンツを種々の方法で入手できる、という環境で動作することになる。カスタムコンパイルされた Linux カーネルでは、適切にセットアップしてあればカーネルイメージのコンテンツもアドレスも秘匿されているのだが、Microsoft と Apple ではカーネルイメージのコンテンツが知られてしまっているのだ。カーネルに ROP を使うには、戻り先アドレスだけでなく、そのアドレスに存在するものについても知っている必要がある。そして KASLR が秘匿するのはカーネルのベースアドレスだけだ。ここから、カーネルイメージを指す既知のポインタがひとつでもあればベースアドレスが判明してしまうことがわかる。
  65. Due to operational constraints, however, the situation is even more dire. iOS KASLR for instance uses only a small 8 bits of entropy. If this weren't enough, the model is even further weakened from what we discussed above as not even a known pointer is needed to reveal the kernel base address. Any pointer to the kernel will reveal its base address via the upper 11 bits (the uppermost three bits are a given). The kernel is mapped aligned to a 2MB boundary. In Stefan Esser's recent iOS presentation [4] he called this 2MB alignment "arbitrary" wondering why there was no smaller alignment. This alignment is not arbitrary at all and is in fact a platform and performance-based constraint on ARM. "Sections," the ARM equivalent of large pages on x86, are implemented in the short mode descriptor format as 2MB first-level page table entries. This is why the iOS kernel as mapped in memory is composed of one 2MB "text" region and one 2MB "data" region -- because a page table entry is needed for each region to express their different memory protections. The kernel is mapped using sections as opposed to normal 4kB pages because it doesn't pollute the TLB with many entries (and potentially other reasons). Don't expect this alignment at the page table level to change. Inside the kernel, leaks will exist in the fixed-address vector mapping until it is relocated via TrustZone extensions.
  66. しかしながら、動作上の制約により、状況はさらに悲惨なことになっている。たとえば iOS の KASLR は、たった 8 ビットのエントロピーしか利用しない。おまけに、カーネルのベースアドレスを解明するには既知のポインタすら必要ない。カーネルを指すポインタなら何でも、上位 11 ビットによってベースアドレスを知らせてしまうのだ (最上位 3 ビットは固定)。カーネルは 2MB にアラインしてマップされる。Stefan Esser による最近の iOS プレゼン [4] で、彼はこの 2MB アラインメントを「適当」と言い、どうしてもっと小さくアラインしなかったのかと不思議がっていたが、これは適当などではなく、実は ARM のプラットフォームおよびパフォーマンス上の制約なのだ。「セクション」という、x86 で言うラージページと同じものが、ARM では 2MB の第一レベルのページ・テーブル・エントリによる短いモード・デスクリプタ・フォーマットで実装されている /* XXX ぜんぜんわからん FIXME */。これこそ、メモリにマップされた iOS カーネルが 2MB の text 領域と 2MB の data 領域で構成されている理由だ。すなわち、それぞれに異なるメモリ保護を表現するため、ひとつの領域にひとつずつのページ・テーブル・エントリが必要だからだ。カーネルは多数のエントリで TLB を汚さないので (その他にも理由はあるかもしれないが)、通常の 4kB ページとは対照的に、セクションを使ってマップされる。このページ・テーブル・レベルのアラインメントが変化することは期待できない。カーネル内部では、TrustZone 拡張で再配置されるようになるまでは固定アドレスのベクトル・マッピングにリークが存在しているだろう。/* XXX この段落すべて、俺にはマジ意味不明ッス FIXME */
  68. KASLR has likewise been praised [5] out of context on OS X. Though the latest version of OS X supports SMEP on Ivy Bridge processors (the latest generation of Intel Core architecture), no processors are available yet that support SMAP. OS X running with a 64bit kernel does not have the userland/kernel memory separation people have been used to in years past. Though similar memory separation is possible without SMEP/SMAP on the 64bit kernel from the "no_shared_cr3" boot argument (thanks to Tarjei Mandt for pointing me to this), it is unlikely that anyone is running in this mode as it imposes a severe performance hit (upwards of 30%+ with today's TLB architectures and sizes). Since cr3 is swapped on changing between a kernel-only and shared address space, cr3 modifications (and thus implied TLB flushes) occur on kernel entry, kernel exit, and before and after every copy to/from userland. Therefore, without SMEP, arbitrary code execution is trivially done in userland. Without SMAP, crafted data for sensitive APIs or ROP payloads can be easily stored in userland, removing any need for reliable storage addresses in the kernel.
  69. KASLR は OS X でも文脈にそぐわない賞賛を受けている [5]。最新バージョンの OS X は Ivy Bridge プロセッサ (Intel Core アーキテクチャの最新世代) の SMEP (スーパバイザモード実行防止) をサポートしているものの、SMAP (同アクセス防止) をサポートするプロセッサはまだない。64 ビット・カーネルを実行する OS X には、みんなが慣れ親しんできたユーザランド/カーネルのメモリ分離がない。SMEP/SMAP なしでも no_shared_cr3 ブート引数から似たようなメモリ分離が可能である (教えてくれた Tarjei Mandt に感謝) とはいえ、ひどいパフォーマンス低下 (今日の TLB のアーキテクチャおよびサイズで 30% 以上) を強いるので、このモードで動かしている人がいるとは思えない。カーネルオンリーのアドレス空間と共有アドレスとの間で切り換える際には cr3 がスワップされるので、cr3 の変更 (と、それに伴う TLB flush) はカーネルに入るときも出るときも発生するし、またユーザランドにコピーしたりユーザランドからコピーしたりするときの前後にも毎回発生するからだ。というわけで、SMEP がなければユーザランドで任意のコード実行が容易にできてしまう。SMAP がなければ、弱い API に合わせて細工したデータや ROP ペイロードをユーザランドに簡単に格納できてしまう。カーネル内の格納アドレスを確保する必要がまったく消えてしまうのだ。/* XXX よくわからん FIXME */
  71. Information leaks are the critical weakness of ASLR, and KASLR amplifies this weakness. Bases are only randomized once at boot, and (at least OS X/iOS's) heap/stack randomization is weak and irrelevant over time. For every usable privilege escalation vulnerability found, at least one usable infoleak will exist. Obvious infoleaks will be fixed by Apple and Microsoft (e.g. NtQuerySystemInformation), but other infoleak sources will prove more difficult to eradicate. Uninitialized structure fields can very easily creep into code (as we've seen time and again in Linux). Improper use of certain string routines like snprintf() can cause infoleaks. Pointers get used as unique IDs [6], pointers are printed. Structure padding often introduces infoleaks, especially on 64bit architectures. An OS that had 32bit kernels only until very recently switching to 64bit might find many infoleaks suddenly appearing due to this structure padding if one were to look. Linux has been struggling with infoleaks for years and even still they're readily found. Mathias Krause found 21 of them recently in the Linux kernel [7], and "3" more even more recently [8]. I say "3" because if you look at the first commit, for instance, you'll see 8 infoleaks being fixed in a single file. 13 infoleaks rolled up into one CVE -- tidy. During the writing of this article, even, I discovered a new infoleak in the Linux kernel that would have evaded any kind of manual code analysis. An unsanitized field that turned into a limited local ASLR infoleak was found via PaX's size_overflow plugin recently as well that evaded manual inspection by the "many eyes" for years [9]. This vulnerability goes back to Linux 1.3.0 (yes you read that correctly, from 1995 -- 18 years).
  72. 情報リークは ASLR の致命的な弱点であり、KASLR ではさらにそう言える。ベースは起動時に一度ランダマイズされるのみだし、(少なくとも OS X/iOS の) ヒープ/スタックのランダマイズは貧弱で、時とともに意味を失なっている。実用的な特権上昇の脆弱性ひとつにつき、少なくともひとつ実用的な情報リークが存在するだろう。あからさまな情報リークは Apple も Microsoft も修正する (NtQuerySystemInformation とか) だろうが、そうでない情報リーク源を根絶やしにするのはもっと困難に違いない。未初期化の構造体フィールドはコードにすぐ入りこんでくる (Linux で幾度となく繰り返されているように)。snprintf() のような文字列処理ルーチンの不適切な使用も情報リークを起こしうる。ポインタはユニーク ID として使われたり [6]、表示される。構造体のパディングも情報リークを引き起こすことがよくあり、64 ビット・アーキテクチャでは特にそうだ。最近まで 32 ビット・カーネルしかなかった OS は、64 ビットに切り換えて突然、この構造体パディングのせいで多数の情報リークが出現したことに気づくかもしれない (探そうとすればの話だが)。Linux はもう何年も情報リークとの苦闘を続けているが、今なお続々と発見される。Mathias Krause は最近 Linux カーネルに 21 個のリークを発見し [7]、さらに最近もう「3 個」発見した [8]。カギ括弧で「3 個」にしているのは、たとえば最初のコミットを見れば、ひとつのファイルで 8 個の情報リークが修正されていることがわかるからだ。13 個の情報リークがひとつの CVE にまとめられるんだから、収納上手だ。この記事を書いている最中にさえ、筆者は Linux カーネルに新種の情報リークを見つけた。これは人力でどんなコード分析をしてもかいくぐってきたであろうと思う。また最近 PaX の size_overflow プラグインによって、サニタイズされていないフィールドが制限つきのローカル ASLR 情報リークになるというケースも発見されたが、これも長年にわたって衆目のもとでの人力調査をかいくぐっていた [9]。この脆弱性は Linux 1.3.0 にまで遡るのだ (見間違いではなく、本当に 1995 年から、18 年間だ)。
  74. Of important note is that large infoleaks via these bugs are rare (and we've taken many steps in grsecurity to further reduce the possibility of leaks through approved copying interfaces). What is not rare are small leaks, large enough to leak pointers. The leaks are often local to the source of the bug. An uninitialized heap struct might leak pointers, but it will never directly leak code from the kernel image. Uninitialized stack entries can be coerced into providing desired pointers from previous syscalls. All these things mean it's much more likely to leak addresses that would reveal all useful "secrets". These secrets are the translations between addresses and known content, and their discovery enables full scale ROP. It's much less likely that content itself will be leaked in quantities sufficient enough for the same kind of attack. While Halvar's famous quote "you do not find info leaks... you create them" rings true for much userland exploitation, in the kernel you will come to know that it is much easier (and safer) to find info leaks than create them.
  75. 大事な注意点は、こうしたバグで大きな情報リークにつながることはあまりないということだ (それに我々は、承認されたコピー・インタフェースを通してリークする可能性をもっと減らすべく grsecurity で何段階もの方策を講じている)。よくあるのは小さなリーク、しかしポインタをリークするには十分な大きさのものだ。その影響はバグの発生源にとどまることが多い。未初期化のヒープ構造はポインタをリークするが、カーネルイメージから直接コードをリークすることはないように。しかし未初期化のスタック・エントリは、それまでのシステムコールから好きなポインタを提供するようにさせられかねない /* XXX */。こうした事柄すべてからすると、大事な「秘匿情報」すべてを明らかにするようなアドレスをリークすることのほうが、ずっと可能性が高いと言える。この秘匿情報とは、アドレスと既知コンテンツとの変換のことで、これが見つかってしまうと、フルスケール ROP が可能になってしまう。同種の攻撃を成立させるのに十分な量のコンテンツがリークされる可能性はずっと低い。Halvar の名言「情報リークは見つけるんじゃない、作り出すんだ」は、ユーザランド攻撃ではまさに真実だが、カーネルにおいては作り出すより見つけるほうがずっと簡単 (しかも安全) ということがわかるだろう。/* XXX うーむ論理わからん FIXME */
  77. We've seen this kind of cargo cult security before [10] [11], of copying techniques into a different environment and via a kind of post hoc, ergo propter hoc logic fallacy, assuming the technique in its new environment will provide the same security. The kptr_restrict sysctl currently exists in the upstream Linux kernel and in most modern distros. It was derived from my GRKERNSEC_HIDESYM feature and submitted upstream by Dan Rosenberg [12]. The intent of the feature was to not leak kernel pointers to userland via /proc interfaces, symbol lists, etc. While the configuration help for GRKERNSEC_HIDESYM mentioned explicitly three things that needed to hold true for the feature to be useful at all, among them being that the kernel was not compiled by a distribution and that the kernel and associated modules, etc on disk are not visible to unprivileged users, you'll note that nowhere in the commit message or the in-kernel documentation for kptr_restrict is any kind of qualification for its efficacy mentioned. So what do we see as a result of this? Take Ubuntu [13]:
  78. 前にもこんなカーゴカルト・セキュリティを見たことがある [10][11]。カーゴカルト、つまり「A のあとに B が起きたのだから A すれば B になる」という前後即因果の誤謬によって、以前と異なる環境にそのまま同じテクニックをコピーして、同じセキュリティ効果を得られると思いこむのだ。kptr_restrict という sysctl が本家 Linux カーネルにも新しめのディストリビューションのほとんどにも存在している。これは筆者の GRKERNSEC_HIDESYM 機能に由来するもので、本家にコミットしたのは Dan Rosenberg だ [12]。この機能の目的は、カーネルポインタを /proc やシンボルリストなど経由でユーザランドにリークしないようにすることだ。GRKERNSEC_HIDESYM に関する設定ヘルプには、この機能が意味を持つために必要な三つの条件が明示されており、その中には「カーネルがディストリビューションによってコンパイルされていないこと」「カーネルや付属モジュールなどがディスク上で非特権ユーザに可視でないこと」が含まれているのだが、kptr_restrict のコミットメッセージやカーネル内の文書には一切その効能にただし書きがないことに注目してほしい。その結果として我々が目にするものは? Ubuntu の Wiki を例にとると [13]:
  80. When attackers try to develop "run anywhere" exploits for kernel vulnerabilities, they frequently need to know the location of internal kernel structures. By treating kernel addresses as sensitive information, those locations are not visible to regular local users. Starting with Ubuntu 11.04, /proc/sys/kernel/kptr_restrict is set to "1" to block the reporting of known kernel address leaks. Additionally, various files and directories were made readable only by the root user: /boot/vmlinuz*, /boot/*
  81. 「攻撃者がカーネルの脆弱性に『全メーカ対応』の手法を開発しようとするとき、しばしばカーネル内部の構造体の位置を知る必要がでてきます。カーネルアドレスを機密扱いすることで、そうした位置は一般ローカルユーザに見えなくなります。Ubuntu 11.04 からは /proc/sys/kernel/kptr_restrict が 1 に設定され、既知のカーネルアドレスのリーク提供を遮断します。加えて、次の各種ファイルやディレクトリが root ユーザにしか読めないようになりました: /boot/vmlinuz*, /boot/*」
  83. All of it utterly useless as every one of these files is publicly available to anyone, including the attacker. And so the false security spreads.
  84. そのすべてはまったく無意味だ。隠したファイルはどれも公開されていて、だれでも、つまり攻撃者も入手できるのだから。こうしてデタラメなセキュリティが広まるわけだ。
  86. KASLR is an easy to understand metaphor. Even non-technical users can make sense of the concept of a moving target being harder to attack. But in this obsession with an acronym outside of any context and consideration of its limitations, we lose sight of the fact that this moving target only moves once and is pretty easy to spot. We forget that the appeal of ASLR was in its cost/benefit ratio, not because of its high benefit, but because of its low cost. A cost which becomes not so low when we consider all the weaknesses (including the side-channel attacks mentioned in the paper that triggered this whole debate [14] which have not been covered in this article for various reasons, mostly because I don't want to sway the many optimists that popped up away from their firmly held beliefs that these are the only problems of this kind that can and will be fixed [15]). KASLR is more of a marketing tool (much like the focus of the rest of the industry) than a serious addition to defense. Many other strategies exist to deal with the problem KASLR claims to deal with. To use some wording from the PaX Team, the line of reasoning is: we need to do something. KASLR is something. Let's do KASLR. "Make attacks harder" is not a valid description of a defense. Nor is "it's better than nothing" an acceptable excuse in the realm of security. If it is, then we need to give up the facade and admit that these kinds of fundamentally broken pseudo-mitigations are nothing more than obfuscation, designed to give the public presence of security while ensuring the various exploit dealers can still turn a profit off the many weaknesses.
  87. KASLR には理解しやすい比喩がある。専門家でないユーザでも、標的が動いていれば攻撃しにくいという概念はわかる。しかし文脈や前提条件を一切無視してとにかく頭文字を並べなくてはならないという強迫観念のせいで、我々は、この標的が一度しか動かず簡単に狙えることを見失ってしまった。ASLR の長所はそのコストパフォーマンスにあるが、それは効果が高いからではなく、コストが安いからだということを忘れてしまった。あらゆる弱点を検討すると、さほど安くなくなってしまうコストだ (そうした弱点には、この議論のきっかけとなった論文 [14] で言及されたサイドチャネル攻撃も含まれるが、この記事では色々な理由で取り上げなかった。最大の理由は、その種の攻撃こそ唯一の修正可能かつ修正すべき弱点だと固く信じている楽観的な寝た子をわざわざ起こしたくないからだ [15])。KASLR は本気の多層防御というよりは (いかにも他の業界から注目されそうな) マーケティングの道具にすぎない。KASLR が解決すると主張する問題には他にも数多くの戦略が存在しているのだ。PaX Team の言葉を借りれば、こういう思考を辿っているらしい: ナニカをしなきゃ。KASLR はナニカだ。じゃあ KASLR をしよう。 しかし「攻撃をしづらくする」というのは防御の正しいありかたとは言えない。「何もしないよりマシだ」というのもセキュリティの言い訳として受け入れられない。であれば、建前なんて捨てて認める必要がある。こんな根本的に間違ったエセ軽減策は弱点を「見えにくく」するだけで、一般大衆には「セキュリティしてますよ」という印象を与えながらも、脆弱性の密売人たちは数ある弱点から利益を上げ続けられるようにできているのだと。
  89. The details matter.
  90. 神は細部に宿るという。
  92. Consider this our "I told you so" that we hope you'll remember in the coming years as KASLR is "broken" time and again. Then again, in this offensive-driven industry, that's where the money is, isn't it?
  93. この「だから言ったろ」という捨てゼリフ的な記事をよく考え、これから何度も KASLR が「突破」される日々に思い出してほしい。とはいえ、この攻撃中心の業界では、それが飯のタネなのだね。
  95. [1] ... n/chen.pdf
  96. [2]
  97. [3] ... Slides.pdf
  98. [4] ... 0dayslater
  99. [5]
  100. [6] ... 00012.html
  101. [7]
  102. [8]
  103. [9] viewtopic.php?f=7&t=2521
  104. [10] viewtopic.php?f=7&t=2574
  105. [11]
  106. [12]
  107. [13]
  108. [14] ...
  109. [15] 3a5f33b4af2ffbc27530087979802613fae8ed3ce0ae10e41c44c2877a76605b
  111. spender
  113. Posts: 1846
  114. Joined: Wed Feb 20, 2002 8:00 pm
  115. Location: VA, USA
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand