アカウント名:
パスワード:
> LinuxカーネルはGitを使用して開発されているため、不正な改ざんなどが行われてもそれを把握するのは容易であることも付け加えられている。
これ、どういうこと?変なコードをGit使って普通にコミットしたなら履歴でバレるだろうけど、Git使わずに直接書いたりGitのデータベースを改竄したりってできないの?
# どっちにせよ、信用できる人で、クラック直前あたりのソースを持ってる人がいりゃ、差分取ればすぐバレそうだけど。
Git は署名付きのタグを打てます (例: v3.0.4 [kernel.org])
git filter-branch 使えば履歴の書き換えは簡単にできる [progit.org]でしょうが、コミットの SHA-1 ハッシュの値が変わります。コミットのハッシュはコミット自体の内容から一意に決まるので、実質的にバレずに改竄は不可能なんじゃないでしょうか。
それぞれの開発者が持っているリポジトリには完全な履歴がありますし、改竄された物から pull してきたとき、マージが発生して気が付くんじゃないでしょうか。(同じコミットメッセージのコミットが複数存在するような奇妙な履歴ができるはず）
ですね。しかも、あるコミットのオブジェクトはその親（マージコミットの場合は複数親）のコミットのハッシュ値を含んでいるので、途中の履歴だけを改ざんするのも不可能。ある2つのコミットのハッシュ値が同じであれば先祖代々のコミットにわたって同じであることが保証されます。
それってハッシュの衝突が起きない限りの保障では？
「侵入には不正なユーザ証明書が使われた」って事は、不正な証明書を作るだけの演算リソースを攻撃側が持っていた可能性があるって解釈も可能だと思います。とすれば、予め混入用にハッシュの衝突したコミットを捏造してから侵入・改竄していた可能性も否定は出来ません。コミット単位のハッシュだと撹乱用のゴミを埋められている可能性も否定できませんし、十分なサイズの有るファイルであればファイル単位のハッシュも信用しきれません。
ハッシュを使った通常手順では力不足で、バックアップ＋各自のローカルリポジトリと完全比較を行わなければならない状況のはずです。
この比較がやり易いからこその「不正な改竄を把握するのが容易」であって、ハッシュは時間稼ぎにしかならないかと思います。# その時間稼ぎにしたって莫大ではあるけれど、攻撃者が提供したコードがカーネルに含まれていれば誕生日攻撃も可能なわけで。
ハッシュ関数の「衝突耐性が破られた」って表現は無作為な探査よりも効率的に衝突を発見する方法が見つかった場合に使われる表現だと思うのですが(違ったらごめんなさい)、Linuxカーネルを改竄する価値を考えたら正面突破がありえないとは言い切れない気がします。それに、事前に作成した攻撃コードのペアとなる無害なコードを攻撃者がコミットしておくことができれば、強衝突耐性を突破するだけで攻撃可能です。
絶対に安全とは言い切れない以上チェックして損はないと思います。
考えすぎなのはわかっていますが。# それだけの資源を持った攻撃者なら、こうもあっさり露見する手段を取るとは思えない。
ハッシュ値で、改ざんの検出はできるけど、コミットオブジェクトのファイルのSHA1直接書き換えちゃうと、エラーなしにFetchはできちゃうよね。git cloneするたびに、全部のコミットのSHA1チェックするわけじゃないし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
改竄。 (スコア:1)
> LinuxカーネルはGitを使用して開発されているため、不正な改ざんなどが行われてもそれを把握するのは容易であることも付け加えられている。
これ、どういうこと?
変なコードをGit使って普通にコミットしたなら履歴でバレるだろうけど、Git使わずに直接書いたりGitのデータベースを改竄したりってできないの?
# どっちにせよ、信用できる人で、クラック直前あたりのソースを持ってる人がいりゃ、差分取ればすぐバレそうだけど。
1を聞いて0を知れ!
Re:改竄。 (スコア:5, 参考になる)
Git は署名付きのタグを打てます (例: v3.0.4 [kernel.org])
git filter-branch 使えば履歴の書き換えは簡単にできる [progit.org]でしょうが、コミットの SHA-1 ハッシュの値が変わります。コミットのハッシュはコミット自体の内容から一意に決まるので、実質的にバレずに改竄は不可能なんじゃないでしょうか。
それぞれの開発者が持っているリポジトリには完全な履歴がありますし、改竄された物から pull してきたとき、マージが発生して気が付くんじゃないでしょうか。
(同じコミットメッセージのコミットが複数存在するような奇妙な履歴ができるはず）
Re:改竄。 (スコア:4, 参考になる)
git filter-branch 使えば履歴の書き換えは簡単にできる [progit.org]でしょうが、コミットの SHA-1 ハッシュの値が変わります。コミットのハッシュはコミット自体の内容から一意に決まるので、実質的にバレずに改竄は不可能なんじゃないでしょうか。
ですね。しかも、あるコミットのオブジェクトはその親（マージコミットの場合は複数親）のコミットのハッシュ値を含んでいるので、途中の履歴だけを改ざんするのも不可能。ある2つのコミットのハッシュ値が同じであれば先祖代々のコミットにわたって同じであることが保証されます。
Re:改竄。 (スコア:1)
それってハッシュの衝突が起きない限りの保障では？
「侵入には不正なユーザ証明書が使われた」って事は、不正な証明書を作るだけの演算リソースを攻撃側が持っていた可能性があるって解釈も可能だと思います。
とすれば、予め混入用にハッシュの衝突したコミットを捏造してから侵入・改竄していた可能性も否定は出来ません。
コミット単位のハッシュだと撹乱用のゴミを埋められている可能性も否定できませんし、十分なサイズの有るファイルであればファイル単位のハッシュも信用しきれません。
ハッシュを使った通常手順では力不足で、バックアップ＋各自のローカルリポジトリと完全比較を行わなければならない状況のはずです。
この比較がやり易いからこその「不正な改竄を把握するのが容易」であって、ハッシュは時間稼ぎにしかならないかと思います。
# その時間稼ぎにしたって莫大ではあるけれど、攻撃者が提供したコードがカーネルに含まれていれば誕生日攻撃も可能なわけで。
Re:改竄。 (スコア:1)
Re:改竄。 (スコア:1)
ハッシュ関数の「衝突耐性が破られた」って表現は無作為な探査よりも効率的に衝突を発見する方法が見つかった場合に使われる表現だと思うのですが(違ったらごめんなさい)、Linuxカーネルを改竄する価値を考えたら正面突破がありえないとは言い切れない気がします。
それに、事前に作成した攻撃コードのペアとなる無害なコードを攻撃者がコミットしておくことができれば、強衝突耐性を突破するだけで攻撃可能です。
絶対に安全とは言い切れない以上チェックして損はないと思います。
考えすぎなのはわかっていますが。
# それだけの資源を持った攻撃者なら、こうもあっさり露見する手段を取るとは思えない。
Re: (スコア:0)
ハッシュ値で、改ざんの検出はできるけど、コミットオブジェクトのファイルのSHA1直接書き換えちゃうと、
エラーなしにFetchはできちゃうよね。git cloneするたびに、全部のコミットのSHA1チェックするわけじゃないし。
Re:改竄。 (スコア:1)
イマイチ状況がわからず。
SHA1値はオブジェクトの内容をデータベースから取り出す際のキーとして使われるので、SHA1値書き換えちゃうとオブジェクト自体取り出せなくなるよ。
どこかのオブジェクト内部に記録されたSHA1値を書き換えるという話なら、その書き換えられたオブジェクト自身の名前とオブジェクトの内容から生成できるSHA1が食い違ってしまうし（これはfetch時にエラーになる)
全部のコミットのチェックをするかどうかはわからないが、少なくともpack単位ではチェックしてそう。