GitHubに脆弱性、第三者が権限のないリポジトリへのアクセス権を取得可能 30
ストーリー by hylom
Railsユーザーはご注意を 部門より
Railsユーザーはご注意を 部門より
insiderman 曰く、
3月4日、GitHubに脆弱性が発見された（GitHubのブログ）。同日中に問題は修正され、現在これによる影響をチェックしているとのこと。
この問題は、GitHubが使っているRuby on Railsに含まれていたMass assignmentという脆弱性を使ったもので、実例としてこれを用いて不正な日付でIssueを登録したり、本来なら登録する権限がないSSH公開鍵の登録が行われていた模様。これはRuby on Railsの問題であり、Issueで議論が行われている。
Ruby on Rails側の問題ということで、Ruby on Railsを使っているほかのサイトでも同様の問題が発生する可能性があるようだ。
脆弱性の日本語解説 (スコア:5, 参考になる)
日本語情報はこれがピカイチですね。
http://blog.sorah.jp/2012/03/05/mass-assignment-vulnerability-in-github [sorah.jp]
ようするにregister_globalsか (スコア:0)
これだからRubiestは(ｷﾘｯ
今後の予測 (スコア:1)
どうせ恥も外聞もないRubyist達は、「対策したからこれ使ってね」と、またもや過去との互換性が希薄な3.3的なRailsを出して
「最新版では対策した、移行しないおまえらが悪い」と、それ以外のバージョンのRailsについては完全にスルーするに10000ペリカ
そう、Rails3がRedmineを切り捨てた時のように…
そして「Rubyも1.9しか面倒見ねえ、1.8とか古いの使うなら自分らで勝手にやれや」宣言した時のように…
あいつらは、いつもそう
そうか…
これで名実共にRedmineはオワコンになったわけだ…
感慨深いね…
Re: (スコア:0)
Ruby界隈の事は良く知らんのだけど、Redmineを1.9に対応させようという動きは無いの？
Re:今後の予測 (スコア:1)
Redmine 1.4.0 で対応予定らしい。
Re: (スコア:0)
恥も外聞もないより、厚顔無恥が適当じゃないか
Re: (スコア:0)
必要ならてめぇらで対応しろよ。
オープンソースなんだから。
何故やらん？
Re: (スコア:0)
本気か皮肉かわからんけど
似たようなもの使えばいいんじゃない。
本当にRedmineが要る人（作りたい人？）は勝手に対応されたし。
Re:今後の予測 (スコア:2)
ほい、対応済みのやつ https://www.chiliproject.org/ [chiliproject.org]
Re: (スコア:0)
どうしてこう、消費者根性が抜けない輩が跋扈するんだろう？
直接の知り合いでもない開発者に履かせてもらったオムツが汚れても泣き喚くことしか出来ないくせに、訳知り顔のヒョーロンカ口調で難詰するなんざ、並の神経じゃできないな
Re: (スコア:0)
開発者連中が成果とともに害も巻き散らしているから
Re: (スコア:0)
「成果とともに害も巻き散らしている」っていう二律背反に書いてる最中に気づかないもんかね？
どちらを選択するかはあなたの判断次第じゃないの？
Re: (スコア:0)
同感。
お客様はオープンソース物を使うんじゃないよ。迷惑だから。
Re: (スコア:0)
(OSIの定義する)オープンソースでは、誰々は使うなといった差別的なライセンスは禁止されてるんだよ
知らねえでやんの(笑)
Re:今後の予測 (スコア:1)
OSS のことですかー？
Re: (スコア:0)
無知ですみませんでした。
使うのは許すけど、消費者根性でクレームつけるのは許さないっていうライセンスだったんですね。
Re: (スコア:0)
開発者を非難するのはどうかと思うが、例えば Linux 上ではオープンソース物以外はほとんど生き残れないと思う。
変化が激しすぎて開発リソースを割けないから。
という現実を理解した上で意図して変化させてるなら、まあいいんじゃないの。
Linux ではどんどん変化させると公言してたしね。
Re: (スコア:0)
パッチを提案したのに「そんなものはアプリの開発者が当然気をつけることだ」とかほざいてrejectしまくったのはどこの誰だよ。
Re: (スコア:0)
なんだただの私怨か
補足 (スコア:1)
Mass assignmentは機能の名前です。Rails自身の脆弱性というわけではありません。
不用意な使い方をしたアプリに脆弱性が生まれます。
とはいえ、ふつうにRailsを使うと紛れ込む可能性は高いのでRailsの問題ではあります。
Re: (スコア:0)
perlのopen 関数みたいな物か。 [ipa.go.jp]
便利ではあるが、注意深く使わないと危険な目に合う。
しかも、あんまり意識されてなかったので、初心者がついやってしまう落とし穴と。
Re: (スコア:0)
Rubyは読み書きできないんで、憶測でものを言うけど、結局fool proofがしっかりしてるかどうかってことでしょ？デフォルト設定で危ないんだったら、その辺は直した方がいいんじゃないかな。
Cの標準ライブラリもバージョン管理して、strcpy()は禁止できればよかったのにな。
Re:補足 (スコア:1)
C11ではgetsがなくなりましたね。strcpyは依然として存在しますが。
バージョン管理と言えば、GCCだと-stdオプションで似たようなことが実現できていると言えないでしょうか。CではなくC++ですが、-std=c++11などを指定せずにC++11で追加された新しいヘッダをインクルードすると「このヘッダはC++11用だ」とコンパイルエラー（正確にはプリプロセッサ、たしか#error使っているので）になります。
Re: (スコア:0)
register_globals みたいなものか。
attr_accessible とかいうので保護すれば大丈夫らしいけど、
それを知らなきゃ即脆弱性に繋がる、脆弱性の温床というわけですね。
脆弱性そのものじゃないけど、これを有用なものであるかのように「機能」と呼ぶのもおこがましい。
他に何かいい呼び方はあったかな。「問題」っていうのもいまいち深刻さが弱いし。
ちゃんと記事を読みましょう。これはRailsの脆弱性ではありません。 (スコア:0)
この問題はActiveRecordのモデルに適切にサニタイズされていないHTTPパラメータを渡すことで発生するもので、
要するにXSSやSQL Injectionと同じです。
Railsの脆弱性ではありませんし、本質的にRails固有のものは何もありません。
いつもの通り、「ユーザから渡されたパラメータを信用しない」という基本的なルールを墨守することが大切で、
GitHubがそれをやっていなかったというだけのことです。
ここぞとばかりにRuby叩きが発生していますが、register_globalsとは全然レベルが違います。
Railsのインターフェイスデザインにまずいところはなにもありません。
逆に言えば、完全な解決策もありません。attr_accessibleは助けになりますが、
これは、例えるならば、「XSS対策のために、デフォルトでHTMLへの埋め込み文字列をエスケープする」というのに近く、
ユーザパラメータのサニタイズが不要になるものではありません。
繰り返しになりますが、ActiveRecordのモデルに対するメソッド呼び出しは最終的にデータベースクエリになるということを頭において、
「ユーザから渡されたパラメータを引数にするときはサニタイズする」ことを忘れないことです。
これは他のWebフレームワークでもまったく同じです。
Re: (スコア:0)
サニタイズいうなキャンペーンどこいった
ところで。
多くの人が間違いを犯すシステムは脆弱なシステムです。
基本ルールを守るというのは重要ですが、守りやすい、わかりやすいシステムであるというのも重要です。
驚きは最小限に。でしたっけ？
Re: (スコア:0)
驚き最小の法則ってのは、昔の Ruby の開発ポリシーでしたね。
Rails とは全然関係ないし、確か今の Ruby でもその方針はとくに重要視していない。
PoLS (スコア:1)
間違えてる人が時々いるけど、「驚き最小の法則」がRubyの開発ポリシーだったことはないよ。
RubyのMLで言い出した人間がいるというだけ。