以下斜め読んだ内容

pseudo translation of useful posts, book reviews, remarks,etc. twitter: feeddict

Adam Langley「CRIME attackの件」

ImperialViolet 2012.9.21のエントリ

ImperialViolet - CRIME

CRIME attackについて

  • 現時点での対応
  • fxと若干違う対応してる点
  • 今後のchromeでの対応プラン

chromeチームのエンジニアがざっくり書いてる
spdy/4で完全対応なんだろうが、それまでのプランの具体的なところを知れてよかった

以下斜め読んだ内容
  • 前から気になってた問題
    • spdyではsensitiveなデータをzlib使って圧縮するのが安全かどうか
    • 掘り下げて検証する暇がなかった
    • 自分と同じ心配をしてた研究者が他にもいた。ありがたい
    • FirefoxチームとChromeチームにDuongとRizzoは事前に教えてくれた
  • chromeチームが今回作ったパッチの話
  • その前にspdyがヘッダを圧縮する仕組みをおさらい
  • zlibのやってることは一言でいうと
    • このリテラルバイトを出力
    • xバイトに戻ってこいつ(=xバイト)からyバイトを複製
  • 圧縮の仕組みの参考になる図を用意した
    • 下線ついた文字列=コピーされるテキスト
    • 濃い青の下線部分
      • ダイアグラムの中にオリジナルが存在するテキスト
      • 灰色線の先にオリジナルのテキストの場所が指示されてる
    • 薄い青の下線部分
      • 辞書に用意されてる文字列にオリジナルを持つテキスト
      • spdyでは共有テキストが定義されてる
      • 共有テキストにはヘッダにあると予想される文字列が入ってる
      • この共有テキストをzlibが利用する
      • 辞書が圧縮のときに有効利用されてる
  • CRIMEが光を当てた問題
    • cookieのようなsentiveなデータと攻撃者が使う制御用のpathが同じコンテキストで圧縮されてる
    • 上のダイアグラムの場合、赤色で圧縮されてないバイト列がクッキーに相当する
    • あるpathにcookieの一部が含まれるとヘッダはより小さく圧縮できる
      • zlibはcookieを構成するバイト列をそのまま出力しないでpathを後方参照することができるから
    • cookiebase64エンコードされてて、1バイトずつ調べる気があればcookieの中身を1バイトずつ徐々に特定できる
  • zlib使って保護された情報を解読していく手法の詳細はDuongとRizzoのプレゼンが詳しい
  • ネットワークトラフィックを監視でき、自在にhttpリクエストを出せる
    • この条件をクリアすれば攻撃者はCRIME attackを実行できる
    • jsをページに仕込むとかして、ターゲットのセッションを読んで、解読とかできる
  • CRIME attackの話を聞いた時のchromeチームの状況
    • spdy/4に搭載する圧縮の仕組みを設計してる真っ最中
    • この新搭載の圧縮の仕組自体はCRIME attackを回避できる仕組みでもあった
    • プロダクトに同梱済みのspdy/2やspdy/3については色々やり残しがある状態
  • CRIME attackへの対応
    • chrome21,firefox15でspdyのヘッダ圧縮をオフにして対応
    • 最小限の修正した。backportを簡単にするため
    • chromeは更にtls圧縮もオフに変更した
      • tls圧縮もCRIME attackが有効なため
  • chrome22以降でspdyのヘッダ圧縮を復活させたい
    • ヘッダ圧縮というspdyの機能は捨てがたい
    • 転送データ削減につながるから
    • spdy/4はまだリリースできる段階にないのでシンプルな解決はできない
    • chrome22,23では複雑なやり方で解決させるつもり
      • データ圧縮を独立させ、後方互換性も維持していく
      • cookieの複製は全面的に他のcookieデータとは独立させる
      • 個々のcookieはそれぞれが単独でHuffmanグループを持つようにする
      • Huffman符号化はzlibのコア部分に相当するが割愛
      • 他のヘッダにsensitiveなデータが含まれるときに(xhrリクエストが発行された時とか)
      • 後方参照をしないで、それぞれ独自のhuffmanグループで圧縮される

以上はあくまでざっくりした説明

  • ここで説明したことに対応するコード、脆弱性のないzlibストリームを生成するコード
    • クリーンなパッチではない
    • spdy/4が準備できたら捨てる代物
    • だが、ヘッダ圧縮を復活させれるのはメリット
  • 縮小してるがダイアグラムの別のサンプルを載せた
    • 赤い部分がリテラル
    • 青い部分が複製されたバイト列
    • 赤い部分の多いほうがCRIME対応以後のヘッダ圧縮
    • 赤い部分の多さは、windowサイズの上限も関係してる
      • compression windowは2048バイトが上限
        • サーバ側で必要になるメモリ量を抑えるため
      • どのcookieもこのwindowサイズに収まらないといけない
      • spdy/4までは圧縮は不効率になる
      • メモリ制限緩めれば改善するがそこはトレードオフ