CVSサーバーに複数の脆弱性 41
ストーリー by Acanthopanax
手当ては早めに 部門より
手当ては早めに 部門より
ferrocyan曰く、"FreeBSDのセキュリティアドバイザリ（FreeBSD-SA-05:05.cvs）によると、バージョン管理システムCVSのサーバーに、複数の脆弱性が発見されました。他のOSでの状況などはCAN-2005-0753で見ることができます。問題は、可変長文字列を固定長文字列にコピーするときに適切なチェックが行われていないなどの、プログラミング上のミスがあるというものです。この結果、CVSサーバーでバッファオーバーフローを起こしたり、Denial of Service状態に陥ったりする危険性があります。回避策はないので、対策済みの最新バージョンへのアップグレードが推奨されています。なお、CVSクライアントには影響ないということです。"
追加情報 (スコア:2, 参考になる)
本家のアナウンス [cvshome.org](1.12.12と1.11.20がリリースされてます)。
IT Pro [nikkeibp.co.jp]によれば、SUSEやGentooはアップデートパッケージが公開されているとのこと(Gentooにはバイナリはないと思うけど…)
debian [debian.org]， Vine [vinelinux.org]，Turbo [turbolinux.co.jp]，Plamo [linet.gr.jp]は今のところサイト上には情報はありません。
これに関連して、Ruby [ruby-lang.org]のAnonymous CVSサービスが停止しています。
Re:追加情報 (スコア:1, 参考になる)
Subversionは (スコア:1)
１年前の脆弱性 [itmedia.co.jp]はCVSもSVNもでしたから。
どなたか知っておられる方、お願いします。
まだJavaにしてねーのか(^^; (スコア:1)
煽りにしかならないんですが(^^;、
まあそれはあくまで一具体例に過ぎなくて、
要は、
インフラ(?)レベルでメモリ管理やってくれるようなVMとかを使って
CVSなりなんなりといった重要なサーバソフトを実装する(しなおす)ことは
そろそろ考えたほうが良い時期なんじゃないか？と思っています。
それをやると、もちろん処理効率は若干(??)落ちますが、
せっかくの近年のCPUパワーは、そういうところに(も)活かすってことで。
MSが.NETなんぞを出した理由のひとつも、
それだったりしないのかなあ？
つまり「脆弱だ」という汚名を(見かけじゃなく本当に)そそぐために。
今我々の手元にはこうしてFreeなOSの定番(Linuxとか…)が存在する
のと同じように、アプリ開発用のFreeなVMが存在してくれると
いいのでしょうね。
あ。べつにJava(JVM)とか.NETとかと互換である必要は無いと思います。
新設計でもOK。
----
あと、J2EE(あくまで一例ですよ一例)とかの上に
CVS(やSubversion)みたいなものを実装した人って、
まだ居ないのかなあ？
クライアント側は既に存在してるようですが。
Eclipseのプラグインみたいに。
＃CVS(と、あとdiff)のruby実装が欲しいと思ったことが何度か有るのでG7
＃まあ動機は、rubyで書かれたWikiエンジンの「中」で
＃コンテンツのバージョン管理が完結するといいなぁってなところなんだけど。
脚光をあびる優れたSCM(マテ (スコア:3, 参考になる)
- Java…SourceJammer [sourceforge.net], Superversion [superversion.org]
- Haskell…Darcs [darcs.net]
- Python…Bazaar-NG(bzr) [bazaar-ng.org]
特に最後の二つはGNU Archと並んで注目を集めていますね。ちなみにRubyだとRSCM [rubyforge.org]というのがあるんですが、これはSCMそのものではなく既存のSCMのwrapperのようです。Re: 脚光をあびる優れたSCM(マテ (スコア:2, 参考になる)
Codeville [codeville.org]
ただしWindowsでCryptoAPIを呼ぶCソースが1本だけあります。
BitTorrentで有名なBram Cohenらが作ってるだけあって、当然のように分散リポジトリ型です。
Re:まだJavaにしてねーのか(^^; (スコア:1, 参考になる)
ruby-cvs [ruby-lang.org]
algorithm-diff [ruby-lang.org]
Re:まだJavaにしてねーのか(^^; (スコア:1, すばらしい洞察)
VM で動く時代がやって来たと仮定してみる。
VM 自身は OS なりハードウェアなりと直接やりとりしないといけないわけで、
そこに脆弱性があったらどうしましょう・・・。
Re:まだJavaにしてねーのか(^^; (スコア:1, すばらしい洞察)
もし、各アプリで対処しなければならないところを一箇所に集中できるのであれば、効率的でしょう。
ただ、その反面、VMに依存しきってしまうことになるので、脆弱性があった場合の影響が計り知れません。その意味でG７氏の見解は視野が狭いでしょう。今回の場合、CVSを使ってないのなら関係ありませんが、ほとんどのアプリが単一のVMに依存している状況はかなり危険でしょう。
今後はCPU側に何らかの仕組みを用意するのが主流になるでしょうが、そのときでも数社のCPUが選べるといいですね。intel AMDだけでなくもう一社ぐらい欲しいところ・・・。
Re:まだJavaにしてねーのか(^^; (スコア:1)
原理的にはそうなんでしょうけど、
１つのvmにすることを警戒した結果として
みんなが独自にCでコードを書きまくる、という状況を我々(現状)が選択したのだとすると
(まあ実際にそこまで考えたかどうかは怪しいですが、結果的に現状はそうなってますよね)、
その割には、Cベースのプログラムについての
現状のセキュリティホールの事例が
「多すぎる」
んじゃないか？と思うんです。
一方、たとえばjavaのvm自体の脆弱性の話って、
頻度的には遥かに少い件数しか聞かないですよね。
というわけで、vm化は
「現実問題としてうまくいく」んじゃないかと
予想してたりもするんですが、どうでしょう？
Re:まだJavaにしてねーのか(^^; (スコア:2, すばらしい洞察)
> 頻度的には遥かに少い件数しか聞かないですよね。
シェアとの比で考えないと意味が無い。
例えば、CVSサーバとjava vm上で動くサーバの種類や稼働数は考慮に入れてますか？
# 個人的には、javaなんて業界全体からみればシェアなんてゼロにも等しいような
# 代物をクリティカルな業務で使うのは関心しませんが。
そうでなくても、安全を手に入れる為に技術に頼るというのは非常に違和感があります。
不具合や脆弱性はどこまでいっても決してゼロにはなりませんから、
それを無くす方向で極端な手段を取ってもおそらく逆効果で、
目指すべきは3点。
1) 問題を早く検出する事
2) 問題を早く解消する事
3) 問題が表面化した時の危険を最小限に抑える為の防火壁を設ける
いちおういっておくと、vmは3の解決策にはなり得ません。
なぜならvmが落とされればその下が全滅する事を考えれば明らか
だからで、むしろ個々のアプリケーションがまったく相互乗り入れの
不可能なバラバラの環境を使ってなくてはいけないくらいだと思います。
不具合がゼロである事の保証されたvmというものが存在し得ない
以上、vmの目指すべきは1の問題検出の分野で期待したい所。
Re:まだJavaにしてねーのか(^^; (スコア:2, 参考になる)
別の人も言っていますが、地味に多いと思いますよ、Javaな鯖は。
CVSだの何だのみたいな著名物はまだ少ないかも知れませんが、
無名の有象無象(ごめんね(^^;＞作ってる諸兄)は
それこそ無数にあるのではないかと。
＃世の中には一品もののソフトウェアは多いですからね。
＃そしてPaulGraham「普通の奴らの上を行け」に近い意味で、
＃特に鯖には一品ものが多いだろうなあ。
そういった無数の一品もののソフトを個別に開発する場合の
開発コストというかリスクは、
それこそメモリ管理とかの足回りの支援度の違いのせいで、
やっぱりCで書くよりJavaで書くほうが有利でしょうね。
まあ数年前だと「プロ」とか称する人々による意固地な開発プロジェクトは
多かったかも知れませんが、
＃CつーかPro*Cで泣いたのでG7。あんなのJava+JDBCで書いたほうが
＃何倍メンテしやすいソースになることやら…)
さすがに近年はそういうのも減ってることをお祈り申し上げております。
それこそ「趣味でやってんじゃねー」んだから、
有利なほうを選ぶほうがいいに決まってます。
>安全を手に入れる為に技術に頼るというのは非常に違和感があります。
え？技術こそが安全を入手するための有力(かつ唯一とまでは言わないが希少)な手段では？
＃安心なら別の手段でも入手可能ですけどね。
道具に支援してもらって危険の可能性を減らすのは、当然のことだと思います。
シートベルトという技術に頼らず運転者の注意力だけで(運転者の)生命を守るという作戦
のほうが、あなたにとってはシックリくるわけでしょうか？
>極端な手段を取ってもおそらく逆効果で、
べつに、メモリ管理を全自動化するのくらい、
いまどき「極端」でもなんでもないです。
40年前(Lisp勢曰く)から有る手法ですし、
GCが「危険を伴う極端な手法」だというなら、
40年前の時点でとっくに破綻していたのではないかと？？
そりゃOSカーネルとかを書けと言われたら
厳しいのかも知れません(俺はよく知りませんが)が、
いわゆる普通の(よって大半の)アプリつーかユーザランドは、
GCで話が丸く収まると思いますよ。
>vmの目指すべきは1の問題検出の分野で期待したい所。
>vmは3の解決策にはなり得ません。
1って、開発ツールの一環として
メモリリークだのなんだののチェッカというジャンルのソフトがありますが、
それが既にカバーしている領域だったりしませんか？
で、それだけで本当に足りるなら、
vmつーかメモリを抽象化したプログラミング環境なんて
誰も有り難がらないはずなのですが…？
3は、そりゃ最悪ケースでは全滅しますが、
そうでないケースではCより効果的に防火してくれます。
で、それってOSと同じことだと思いませんか？
vm(自体の開発)も結局は、慎重さを要するという意味で正にOSなんですよね。
結局は、LinuxなりWindows:-)なりを信じるのと、定性的には同じレベルで、
特定銘柄のvmを信じる、ということになるのだと思います。
そして定量的には各vmを実績とかに基づいて信じることになりますが、
例えばsun jvmは結構やれてるのではないかと…？
Re:まだJavaにしてねーのか(^^; (スコア:0)
Re:まだJavaにしてねーのか(^^; (スコア:0)
各文はまともだけど、一連の文どおしのつながりはなく、自動生成みたいで論点がばらばら。
> 1) 問題を早く検出する事
> 2) 問題を早く解消する事
> 3) 問題が表面化した時の危険を最小限に抑える為の防火壁を設ける
>
> いちおういっておくと、vmは3の解決策にはなり得ません。
> なぜならvmが落とされればその下が全滅する事を考えれば明らか
> だからで、むしろ個々のアプリケーションがまったく相互乗り
Re:まだJavaにしてねーのか(^^; (スコア:0)
ここが問題なんでしょ。
そのためのオープンソース。
メモリアクセスのライブラリを自分で書きまくるなよ...ってVMつくるのと変わらないのか？
そうなると、結果的にはVMがはやるより先に、メモリアクセスの教科書的なライブラリがでてくるほうがみんなのためでは。
Re:まだJavaにしてねーのか(^^; (スコア:1)
メモリアクセスを扱うのは、それが必要なときだけでいい。メモリチェックをするためにオープンソースがあるわけではない。
Re:まだJavaにしてねーのか(^^; (スコア:1)
まあCな人もVM(をCで作る)人もいっぺんに幸せにする、という意味では
それはTRUEなんですが、その点はさておき。
Cの場合、ライブラリレベルじゃメモリアクセスの「全て」を
カバーというか隠蔽するのは事実上無理ですよね。
メモリアクセスが全部関数経由として記述されたCソースなんて…Cじゃないやい(^^;
(そういう意味では、「VMつくるのと変わらない」はTRUEではありません。)
だからどうしても、自力で書くか、
あるいはそれよりは少々マシな線として
既存の実装パターン(イディオム)やデザインパターン(?)を
流用して書く、という箇所が生じます。
でもそれって、どっちにせよ自分で書くから、やっぱりミスが入り得るわけです。
あと、ミスというよりも、チェックとかを「面倒だから略した」コードってのも
書いてしまいがちだったりしないかな…？
つまりパターン励行度が100%を下回ってしまうケースね。
で、ミスが入り得るってのは単に可能性だけの問題じゃなく、
実際何度も何度も世間で起きている問題なわけですよね。
結局はそれがCによるプログラムの現状における実態なのだと思います。
Re:まだJavaにしてねーのか(^^; (スコア:0)
Re:まだJavaにしてねーのか(^^; (スコア:0)
とsubversionの作者(の一人)が申しておりました。
Re:まだJavaにしてねーのか(^^; (スコア:0)
Re:まだJavaにしてねーのか(^^; (スコア:1)
要るのはvmであってjvmではないと思います。
流行ってくれりゃなんでもいい。(もちろん設計レベルで使いものになる品質でないと困りますが。)
ちょうどSolarisでもBSDでもなくLinux、みたいな感じで。
むしろ下手にjava本家との距離を気にする義務(^^;を負ってしまうという点が心配なので、
javaとは無関係なもののほうが良いかとも思います。
Re:まだJavaにしてねーのか(^^; (スコア:0)
>CVSなりなんなりといった重要なサーバソフトを実装する(しなおす)ことは
>そろそろ考えたほうが良い時期なんじゃないか？と思っています。
もう個々のソフトを実装し直すのではなく、OSやハードウェアレベルでの
仮想化が時代の流れだと思うけどね。
Re:まだJavaにしてねーのか(^^; (スコア:0)
＞仮想化が時代の流れだと思うけどね。
それは「仮想」ってキーワードが同じだけの
別のレイヤの話で、どっちかを選ばなきゃダメっていう
二者択一の話じゃないでしょ。
理解していない知識を中途半端に使わないこと！
Re:まだJavaにしてねーのか(^^; (スコア:0)
こういうことを言う奴も知ったかにしか見えない罠
なんだか (スコア:0)
とりあえずOpenCVS [opencvs.org]に期待しとけばいいのか？
Re:なんだか (スコア:1, 参考になる)
そこまでひどくはないよ。
サービスの特性上、pserver 立てない限り、
ポート開きっぱなしということもないし。
Re:クライアントは無問題？ (スコア:1)
Web サーバーがクラックされて HTML の内容が改ざんされたりしたら、
それを引っ張ってきて表示する
ブラウザを動かしてる側も、簡単に掌握できる。
という事ですね。
Re:クライアントは無問題？ (スコア:1, おもしろおかしい)
俺のIPアドレスは127.0.0.1だ。
Re:クライアントは無問題？ (スコア:1)
しかし敵も応戦してきたな
一段と負荷が増してきた
Re:クライアントは無問題？ (スコア:0)
Re:クライアントは無問題？ (スコア:1)
まぁ、あんたがオレのアドレス(192.168.0.1)を使ってなければ
別にいいんだけどな。
# ってヤツだよな、それは？
Re:クライアントは無問題？ (スコア:1)
奇跡? それとも誕生日の一致みたいに案外よくあることとか?
# /.Jer全員が同じIPだったらすごいのになぁ…
1を聞いて0を知れ!
Re:クライアントは無問題？ (オフトピ) (スコア:0)
Re:クライアントは無問題？ (スコア:0)
cvsクライアントでgetしたソースをコンパイルしたプログラムがテロリストの手に渡っていてそれが誤動作したために飛行機テロの目標地点が誤ってあなたの家になる可能性だってあるわけですよ。気をつけないといけませんね。
Re:クライアントは無問題？ (スコア:0)
パッチつきで。
Re:クライアントは無問題？ (スコア:0)
"パッチ"の問題点は、
即物的というか、
おもいっきり具体的なエラーしか修正できないことなんだよね。
抽象的なエラーには対処のしようがない。
抽象的なエラー? (スコア:0)
「抽象的なエラー」というのは例えばどんなものを指すのですか。エラーが見つかったのであれば、何らかの修正を施す必要があるはずですよね。自分にはパッチを作成することの出来ないエラーというのが想像出来ないです。
Re:抽象的なエラー? (スコア:1)
パッチは、見付かった(つまり既存かつ既発見の)エラーに対してしか記述できないですよね。
だから例えば予防(未来)の役には立たないし、見たことがないソフトのパッチも書けない。
そこを踏まえると、上の人の、
>じゃあ、クライアントのどこに問題があるか、教えてください。
>パッチつきで。
という「ネタ」が活きてくるわけで。
未知のクライアントに対してパッチ書けるわけ無いよね。
Re:抽象的なエラー? (スコア:0)
Re:クライアントは無問題？ (スコア:0)
「参考になる」
等のモデがついちゃうんだろうなぁ。