パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Kernel.org、侵入される」記事へのコメント

  • by greentea (17971) on 2011年09月02日 18時22分 (#2013561) 日記

    > LinuxカーネルはGitを使用して開発されているため、不正な改ざんなどが行われてもそれを把握するのは容易であることも付け加えられている。

    これ、どういうこと?
    変なコードをGit使って普通にコミットしたなら履歴でバレるだろうけど、Git使わずに直接書いたりGitのデータベースを改竄したりってできないの?

    # どっちにせよ、信用できる人で、クラック直前あたりのソースを持ってる人がいりゃ、差分取ればすぐバレそうだけど。

    --
    1を聞いて0を知れ!
    • Re:改竄。 (スコア:5, 参考になる)

      by Ryu-TK (1420) on 2011年09月02日 19時06分 (#2013592)

      Git は署名付きのタグを打てます (例: v3.0.4 [kernel.org])

      git filter-branch 使えば履歴の書き換えは簡単にできる [progit.org]でしょうが、コミットの SHA-1 ハッシュの値が変わります。コミットのハッシュはコミット自体の内容から一意に決まるので、実質的にバレずに改竄は不可能なんじゃないでしょうか。

      それぞれの開発者が持っているリポジトリには完全な履歴がありますし、改竄された物から pull してきたとき、マージが発生して気が付くんじゃないでしょうか。
      (同じコミットメッセージのコミットが複数存在するような奇妙な履歴ができるはず)

      親コメント
      • Re:改竄。 (スコア:4, 参考になる)

        by espelette (42945) on 2011年09月02日 22時22分 (#2013654)

        git filter-branch 使えば履歴の書き換えは簡単にできる [progit.org]でしょうが、コミットの SHA-1 ハッシュの値が変わります。コミットのハッシュはコミット自体の内容から一意に決まるので、実質的にバレずに改竄は不可能なんじゃないでしょうか。

        ですね。しかも、あるコミットのオブジェクトはその親(マージコミットの場合は複数親)のコミットのハッシュ値を含んでいるので、途中の履歴だけを改ざんするのも不可能。ある2つのコミットのハッシュ値が同じであれば先祖代々のコミットにわたって同じであることが保証されます。

        親コメント
        • by fs0x7f (39059) on 2011年09月03日 1時08分 (#2013696) 日記

          それってハッシュの衝突が起きない限りの保障では?

          「侵入には不正なユーザ証明書が使われた」って事は、不正な証明書を作るだけの演算リソースを攻撃側が持っていた可能性があるって解釈も可能だと思います。
          とすれば、予め混入用にハッシュの衝突したコミットを捏造してから侵入・改竄していた可能性も否定は出来ません。
          コミット単位のハッシュだと撹乱用のゴミを埋められている可能性も否定できませんし、十分なサイズの有るファイルであればファイル単位のハッシュも信用しきれません。

          ハッシュを使った通常手順では力不足で、バックアップ+各自のローカルリポジトリと完全比較を行わなければならない状況のはずです。

          この比較がやり易いからこその「不正な改竄を把握するのが容易」であって、ハッシュは時間稼ぎにしかならないかと思います。
          # その時間稼ぎにしたって莫大ではあるけれど、攻撃者が提供したコードがカーネルに含まれていれば誕生日攻撃も可能なわけで。

          親コメント
          • by espelette (42945) on 2011年09月03日 14時04分 (#2013812)
            SHA1の弱衝突耐性が破られたという話は聞かないので大丈夫ではないでしょうか。
            親コメント
            • by fs0x7f (39059) on 2011年09月03日 21時59分 (#2013974) 日記

              ハッシュ関数の「衝突耐性が破られた」って表現は無作為な探査よりも効率的に衝突を発見する方法が見つかった場合に使われる表現だと思うのですが(違ったらごめんなさい)、Linuxカーネルを改竄する価値を考えたら正面突破がありえないとは言い切れない気がします。
              それに、事前に作成した攻撃コードのペアとなる無害なコードを攻撃者がコミットしておくことができれば、強衝突耐性を突破するだけで攻撃可能です。

              絶対に安全とは言い切れない以上チェックして損はないと思います。

              考えすぎなのはわかっていますが。
              # それだけの資源を持った攻撃者なら、こうもあっさり露見する手段を取るとは思えない。

              親コメント
        • by Anonymous Coward

          ハッシュ値で、改ざんの検出はできるけど、コミットオブジェクトのファイルのSHA1直接書き換えちゃうと、
          エラーなしにFetchはできちゃうよね。git cloneするたびに、全部のコミットのSHA1チェックするわけじゃないし。

          • by espelette (42945) on 2011年09月03日 14時00分 (#2013809)
            <quote><p>コミットオブジェクトのファイルのSHA1直接書き換えちゃうと、</p></quote>

            イマイチ状況がわからず。
            SHA1値はオブジェクトの内容をデータベースから取り出す際のキーとして使われるので、SHA1値書き換えちゃうとオブジェクト自体取り出せなくなるよ。
            どこかのオブジェクト内部に記録されたSHA1値を書き換えるという話なら、その書き換えられたオブジェクト自身の名前とオブジェクトの内容から生成できるSHA1が食い違ってしまうし(これはfetch時にエラーになる)

            全部のコミットのチェックをするかどうかはわからないが、少なくともpack単位ではチェックしてそう。
            親コメント
    • by Anonymous Coward

      Gitは開発者がそれぞれにリポジトリを持ってるから、それらすべてが標的にならない限り異変に気づきやすいんじゃない?

      ====
      クラッキングでソースコードが盗まれ、Linuxカーネルがより普及したよ。
      クラッカーさんありがとう!

    • by Anonymous Coward
      開発者以外にとっては、PGP/GPGのlinux-*.bz2.signの署名が不正に署名されたものなのかどうか、その秘密鍵(とパスフレーズ)まで漏れてしまったのかどうかが気になるわけですが、大丈夫でしょうか。

      その昔、1.1か1.2のころ、改竄されたカーネルがftpミラーサイトに蔓延してバージョンアップを余儀なくされた事件があったような記憶があるけど思い違いかな...

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー

処理中...