パスワードを忘れた? アカウント作成
782455 story
Linux

Kernel.org、侵入される 36

ストーリー by hylom
コードの暗黒面に落ちたのだ 部門より
あるAnonymous Coward 曰く、

「Linuxファンの皆さんはご存知の通りだが、ハッカーには良いヤツと悪いヤツがいる...」との書き出しで始まるのはPCWorld の Hackers Break Into Linux Source Code Site という記事。「良いハッカーのたまり場こと kernel.org に、悪いハッカーであるところのクラッカーが侵入した」そうだ(japan.internet.com本家/.)。

クラッカーはroot権限を奪っており、ファイル改ざんやユーザー情報取得などの悪行を働いた模様。撃を受けたのがよりによってLinux kernelを管理するkernel.orgであったため関連各所への影響が懸念されている。しかしkernel.orgが8/28に出した記事によれば、管理されているソースコードに悪質なコードを気づかれずに忍び込ませるのは非常に困難とのこと。同様のことはFedoraやSourceForgeで侵入事件が発生したときにも言われている。

また、cheez 曰く

侵入者らはHeraサーバにルート権限でアクセスしていたとのこと。侵入には不正なユーザ証明書が使われたとみられるという。スタートアップスクリプトにトロイの木馬起動ファイルがくわえられたり、ssh関連のファイルの改ざんなどが行われたことなどが分かっているとのこと。

kernel.org曰くソースコードレポジトリは変更されていないと考えられるが、現在これを検証中だそうだ。また、LinuxカーネルはGitを使用して開発されているため、不正な改ざんなどが行われてもそれを把握するのは容易であることも付け加えられている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by iwakuralain (33086) on 2011年09月02日 17時50分 (#2013546)

    ちくしょう・・・ここも汚染されちまってる・・・
    汚染されていないKernelなんてもうないのかもしれんな

    とか言う日がきたりして。

    ネットに繋がっている以上は避けられないわけですが、こういう広く使われているものに疑いがかけられるとなかなか大変かも。
    今回はたいした事にならなかったみたいだけど、今後も大丈夫とは言い切れないので。

  • 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ミラーサイトに蔓延してバージョンアップを余儀なくされた事件があったような記憶があるけど思い違いかな...
  • by Anonymous Coward on 2011年09月03日 10時59分 (#2013752)

    だからWindows Server使っとけっていったのに。

    • by Anonymous Coward

      例えば中国がスパコンで証明書偽造していたとして
      ウィンドウズサーバならそれをしても問題ないだけの
      暗号強度を保証しているんですか

      • by Anonymous Coward

        問題なく解読できる程度の暗号強度が保証されております。

        # さらに論点をずらす

    • by Anonymous Coward

      Windows鯖とか、侵襲されても個人では対処できん。
      全てMicro$oft任せになって、その間にすべての機能が停止する。
      Micro$oftのことだから、いつになっても修正されないだろうけど。

      • by Anonymous Coward

        でもなあ、俺はLinuxカーネルの修正なんてできないし、誰かがパッチを書いてくれるのを待つしかないというのは、WindowsでもLinuxでも(あるいはさらに他のOSでも)同じなんだよなあ……。

        • by Anonymous Coward

          あなたの場合は知りませんが今回のkernel.orgの場合はカーネルを修正できる人たちがたくさんいると思いますが

          • by Anonymous Coward

            Microsoft にはいないのでしょうか?

  • 励めと? (スコア:0, おもしろおかしい)

    by Anonymous Coward on 2011年09月02日 17時52分 (#2013547)

    。撃を受けたのがよりによってLinux kernelを管理するkernel.orgであったため関連各所への影響が懸念されている。

    • by Anonymous Coward

      それは檄では?

      • by Anonymous Coward

        マジレスありがとう

        # typo指摘に編集が面白おかしく返してくれないかなぁと思ってたのにぃ

      • by Anonymous Coward

        しかも誤用
        本当は檄に激励のような意味はない

        • by Anonymous Coward

          誤用だったのか・・・しらなかった。
          本来の意味で、クラッカーの主張や考え(檄)を受け入れたって読むと結局アレだけど。
          # 知らなかったのでAC

  • by Anonymous Coward on 2011年09月03日 9時26分 (#2013738)

    違うと思うぞ。
    何か腹に一物かかえた、何か利権目当てみたいのも
    結構群がっている様な気がします。
    内部のものの手引きという線は無いだろうか?

  • で、今度は侵入したその人が管理する「当番」ということにして。
    逆に侵入されたらサイトのオーナーから多額の慰謝料を請求されるというシステムにしたらいいんじゃないか?。

typodupeerror

人生の大半の問題はスルー力で解決する -- スルー力研究専門家

読み込み中...