ruby-lang.org、クラックの詳細を公開 37
ストーリー by Acanthopanax
失敗から学ぶ 部門より
失敗から学ぶ 部門より
Anonymous Coward曰く、"今年の5月にクラックされてしまったhelium.ruby-lang.org (WWW、FTP、CVS)だが、その後の調査の詳細が公開されている。侵害の詳細、ソースコードを含めた各コンテンツに対する改竄の検証方法と結果などについて記述されており、ruby-lang.org管理グループの努力がよくわかる。chroot環境のCVSを更新しなかったために侵入を許してしまったことは痛いミスだったと思うが、その後の対応やその詳細を公開したことには好感を持てる。Rubyファンの一人として、ruby-lang.org管理グループの方へ感謝の念をささげたい。"
chroot (スコア:3, 興味深い)
せっかくのpkgシステムなんだからchroot用のコピーもちゃんとフォローできる仕組みがあるといいですね。
# rm -rf ./.
Re:chroot (スコア:1)
Re:chroot (スコア:2, 興味深い)
%triggerin/%triggerunでは私の言う事が実現できません。
chrootコピーするときはダミーパッケージを作れ、ということかもしれませんが、いささか乱暴ですよね。
rpm -[ieU] cvsしたときのトリガースクリプトを後付けする方法、です。
もちろん、rpm本体のスクリプトをいじって作ればいいのはわかりますが、Distribution側で採用しないことにはあまり意味がありませんよね。
# rm -rf ./.
Re:chroot (スコア:1, 参考になる)
このへんにDebian(のユーザ)の急所を見た思いがします。
一度Debianをいじっていたとき、apt-get で追加したアプリケーションが
デスクトップのメニューに自動で追加されるのに気づきました。
これは便利だ！と感心したのですが、/etcの下のメニューが更新されてる
だけなので、自分でいじりたくなって ~/.* を読み込むように設定すると、
当然自動更新はされなくなりました。
(昨年試してすぐ消しちゃったので、間違ってたらツッコんで下さい)
要するに自分で(パッケージの想定外な)カスタマイズすると、管理、更
新が非常に面倒(=落し穴ができやすい)になってしまう、と思われます。
# Debian/GNU Linux に限った話でもなさそうだけど。
chroot破り? (スコア:2, 興味深い)
検索してFix chroot(2) vulnerability of linux 2.2 [luky.org]とか見ると昔そういうセキュリティホールはあったみたいですが、今回のheliumの状況でchroot破る手段があったと考えられるのでしょうか？
Re:chroot破り? (スコア:5, 参考になる)
chroot jailから脱出できると書いてあるぞ。
他にも勝手にカーネルモジュールをブチ込んで以下略
とか出来るから特権を取得されたら危険だと考えるべき。
capabilityで特権ユーザの権限を制限しておけば
特権を取られてもchroot jailからの脱出や危険な
カーネルモジュールの挿入は防げるようになる。
Linuxケーパビリティ [linux.com]
Manpage of CAPABILITIES [homepages.cwi.nl]
Re:chroot破り? (スコア:0)
# クーラーつけたらブレーカーが落ちたのでAC
Re:chroot破り? (スコア:5, 参考になる)
- Linuxのchroot(2)にあるchroot jailからの脱出法 (#587014のリンク先と原理は同じ) は、chroot(2)の中でchdir相当をする実装 (NetBSD、OpenBSDなど) では無効です
- #587014の、「mknodしてmountしなおす」は、一般的には不可能です。chroot jailの中では、jailの外側のファイルシステムをumountすることはできないからです。ただし、Linuxでは1つのファイルシステムを複数回 (別なmount pointに) mountできてしまうので、mountしなおす、というよりはjailの中にあらたにmountして以下略、ということも可能だと思われます
- #587092 にあるように、root権限があるとカーネル空間、他のユーザー空間などいくらでも書換え放題ですが、*BSDのsecurity levelによる保護のように、/dev/mem、/dev/kmemへの書き込みを禁止することができる実装も存在します (security levelによる保護は、Xサーバを動かすためなどの理由で無効にしていることもあるでしょうが、サーバ用マシンでは有効にすべきです)
- もちろん、chroot jailを過信するのは危険であることは言うまでもありません
# FreeBSDのjail(2)のことをよく知らないのでAC
Re:chroot破り実演 (スコア:1, 参考になる)
よく分からないので追試してみますた。(kernel2.4.26)
大体こんな感じです。
# mkdir -p /home/chroot/newmount && cd /home/chroot
# cp -a /bin /sbin /lib /etc .
# mkdir -p /home/chroot/dev && cd /home/chroot/dev
# mknod hda1 b 3 1
# chroot /home/chroot /bin/bash
# mount -t ext3 /dev/hda1 /newmount
// exitしても umount されませんから注意して！
Re:chroot破り実演(重要な補足) (スコア:1, 参考になる)
・chroot環境下でもmknod動きます。
・chroot環境で既存のパーテーションをmountされても、その外側からは
わかりにくいようです。
(外でmountコマンド叩いても表示されないし、mountを記録している
/var/log/messagesにも出なかった...)
何されても気づかない...かどうかまでは追試しきれてないですが。
# あな恐ろしやchroot
Re:chroot破り? (スコア:4, 参考になる)
Re:chroot破り? (スコア:2, 興味深い)
Re:chroot破り? (スコア:0)
なんてセキュリティ機構が *BSD にも Linux もありますが、
あれも手間暇かければ何とでもできるんですか?
Re:chroot破り? (スコア:0)
カーネルモジュールのロードなどのインタフェースを禁止すれば ユーザプロセスからカーネル空間には手は出せません。
Re:chroot破り? (スコア:1, 参考になる)
Re:chroot破り? (スコア:0)
まさかメモリファイルデバイスを無効化する方法を御存じないとか?
Re:chroot破り? (スコア:0)
もっとも今回は昇格がなされていないようなのでchroot外のファイルの改竄はない という結論のようです。
Re:chroot破り? (スコア:0)
chroot されてないユーザ? chroot ってプロセスごとに設定されるもんじゃないんですか?
三菱自動車の (スコア:1, すばらしい洞察)
あいだみつおじゃないけど人間だから間違いを犯すことはある。
でも、その後の対応になぜこうも差が出るのか？
改めてオプンソースプロジェクトに係わっておられる方々の素晴らしさに感動しました。
Re:三菱自動車の (スコア:1, おもしろおかしい)
会社もいろいろ
オープンソースプロジェクトもいろいろですよ
ここの537から [2ch.net]のプロジェクトとか
Re:三菱自動車だけですか？ (スコア:1, 参考になる)
yahooとかACCSとか北海道警（データはネットから削除した！）とか
Re:１２０人のアドレス誤送信 民主党、警察不祥事情 (スコア:0, オフトピック)
新聞に載らないのは参院選中だからじゃないですかね．もちろん，それがいいとは言いません．選挙戦中だからこそ報道すべきという考え方もあるでしょう．選挙が終われば終わったで，選挙結果報道でどっかに吹っ飛んでしまうかもしれませんし．
Re:１２０人のアドレス誤送信(オフとぴごめん) (スコア:0)
ええ、大抵は一度痛い目に遭わないと区別しないのが普通みたいっす
「友達の友達は、みな友達」...とは限らないぞオイ
好感？ (スコア:0)
そうかな？ 昨今では割と普通の対応になっていると思うけれど
一部の酷すぎる例に比べれば段違いに良いが
この程度で 好感が持てる というのは悲観的過ぎないかな
Re:好感？ (スコア:3, 興味深い)
だって・・・ボランティアなんでしょ？
こういう人たちって、普段何やっている人なの？
サラリーマン？大学職員？
だったらすごすぎ・・・
Re:好感？ (スコア:1)
なんかけっこう深いところを突いた指摘のような気がする．
ただ，ボランティアかどうかは関係ないのではないでしょうか．彼らに「これは自分たちのプロジェクトだ」という意識があって，また彼ら自身が責任のとり方を決められたから，技術者としての落とし前をきっちりつけられたということなんじゃないか，と思います．
もちろん，そういう場合にいつでもきちんとした責任の取り方がなされるわけではないのは，たとえば浅田農産のケースを見れば明らかなんですが．
これが企業や官公庁などの（大きな）組織だとなかなかねぇ……エラい人たちには「自分たちがやってしまったこと」というよりも「下のバカどもがやったミス」に見えるんでしょうし（社員がちゃんと働かないのがいけない！），下の方に心ある人たちがいたとしても，彼らに責任のとり方の決定権があるわけではない．いや，そういう問題だけじゃないのかな？ うーん．
# 考えがまとまらなくてすみません……
# このへん，社会学や（社会）心理学で分析されてそうですね
Re:好感？ (スコア:1, 参考になる)
そうなんでしょうね、「ボランティアなのによく頑張り
ました。」っていったら、馬鹿にしたことになるんでし
ょうね。
うまくいっていることを、声高に喧伝する人はいるだろ
うけど、事故のレポートをこんなにきちんと作るなんて。
私などは、自分の仕事だけで、いっぱいいっぱいなのに、
世の中には志の高い人がいらっしゃるんですね。
Re:好感？ (スコア:1, 参考になる)
再発を防ぐために企業でもこういった作業は重要ですが、
オープンソースのプロジェクトにとってはよりプライオ
リティの高いものになっていると思います。
Re:好感？ (スコア:3, 参考になる)
ように思います。
1: ユーザ数の増加による問題
1-1: 開発者の相対的な減少
1-2: 開発者の時間がユーザサポートに割かれるようになってしまった
1-3: 開発者にとって「楽しいハック」と違う部分でのスキルや労力が必要になる
(例としてセキュリティのような)
1-4: 新規ユーザは、開発者に対して「文句は言うが評価はしない」傾向にある
これらだけで、本文にある以下の要素は低減する。
・ 贈与経済としてのハッカー文化
・ ハッキングのよろこび
他に、
2: 社会的責任の変化
2-1: 牧歌的開発時代の終焉-ミスが許されない-それは「ハック」ではない。
(しかも速やかな対応が求められる→決して楽しい作業ではない)
2-2: 組織運営の難しさ
大規模になればなるほど、中心人物は楽しい作業ができない
そのくせユーザは文句ばっかり言う
(使ってるくせに開発ヤメロなんて言う奴までいる始末だ)
「ハック」ってのは、「作りは雑だけど、とにかく動くもの」というニュアンスがあります。
しかし、今の時代「ハック」自体が許容されなくなってきています。
「動くこと」ではなくて「品質」を要求されるのは「ハック」ではなくて「プロダクト」ですね。
「プロダクト」は、普通はカネ払って入手するものだと思います。
私は、「ノウアスアフィアの開墾」がダメな文献というつもりはありません。
優れたドキュメントですが、もう現状とは合致しなくなりつつあるのです。
旧来のバザール開発モデル自身がOSSの弱点になる前に、開発からユーザサポートまで
含む総括的な開発・サポートモデルを作らないといけないのじゃないかと思います。
# 怖い人のツッコミが怖いのでAC
# (本来は恐れなくてもいいはずだが、それを恐れないといけないのが悲しい)
開発者・テスタ・文書書きだけでは足りない。 (スコア:0)
自分が今まで出会ったことのある人たちという狭い範囲での印象ですが、本職とは違う部分でフリーソフトやオープンソースのプロジェクトにかかわっている人って、本当に大変そうでした。
サイトやプロジェクトの運営にかかわると、それに時間も気力も消費され続けて、コードを見て書いて楽
Re:好感？ (スコア:1)
Re:好感？ (スコア:0)
NaClのサポートは非常に大きなものではありますが、別にrubyの開発主体じゃありません。
Re:好感？ (スコア:0)
Re:好感？ (スコア:0)
元に戻して知らんぷり、良くて「緊急メンテナンスを行いました」
が殆どでしょう。
そして、抜本的対策もせずにコンテンツだけ戻してるので再度…というのがかなりの数あるというのが現状です。