Namazu 2.0.13以前にクロスサイトスクリプティング脆弱性 63
ストーリー by Acanthopanax
穴ふさぎ 部門より
穴ふさぎ 部門より
Anonymous Coward曰く、"純日本産の全文検索エンジンとして導入実績も数多いNamazuにクロスサイトスクリプティング脆弱性が発見された。2.0.13以前のnamazu.cgiにタブ(%09)から始まる検索文字列を指定すると、検索文字列がサニタイズされなくなる不具合があるとのことで、ユーザーは、すでに公開されている修正版をダウンロードして早急にアップデートした方がいいだろう。"
12月15日付けで、Namazu 2.0.14が公開されている。
[2004-12-16 00:55 JST Acanthopanaxによる追記] コメントでも指摘されているように、/.Jにもこの脆弱性が存在します。/.J側の対処が完了するまでは、ログアウトするといった対策をお願いします。たいへん申し訳ありません。
[2004-12-16 01:23:46 JST tachによる追記] とりあえず対処しました。バージョンは変わっていませんが、問題の文字を置き換えるようにしてnamazuに渡すようにしました。
[2004-12-16 01:47 JST Oliverによる追記] ここ一週間のログをチェックしたところ、当ストーリ掲載以前に脆弱性を利用するアクセスが行われた痕跡は確認できなかった。また、掲載後、応急処置が行われるまでの間には267回の%09を含んだNamazuへのアクセスがあり、その内247回がデモリンクを含むコメントに記載されていた確認用のコードを使ったものだった。残り20回に関しても同種のテスト目的のもので、他ユーザのクッキーを盗むようなアクセスはなかった。
/.Jのnamazu.cgiをとめろ！ 今すぐ！ (スコア:5, 参考になる)
Slash CodeでCookieがどう使われているかがを考えれば，
この脆弱性は致命的だ。すでに実証コードも出ている。
スラッシュドットジャパンの管理者へ
NamazuのUpdateが完了するまでnamazu.cgiをとめろ！
今すぐだ！ 今すぐ！
あ，対処されましたね (スコア:1)
とりあえず，アクセスログは保存しておいて，
後日チェックはしておいてください。
Re:/.Jのnamazu.cgiをとめろ！ 今すぐ！ (スコア:0)
まだ止まってないよ。
Re:/.Jのnamazu.cgiをとめろ！ 今すぐ！ (スコア:0)
私の認識だと
・スラッシュドット内でのなりすまし → 荒らし、日記削除（？）
くらいの脅威しか思いつかないんですが実際にはたとえば
・他のサイトも含めたクッキーを盗み放題 → 使い方によっては危険
・任意のブラウザバグコードを埋め込む
→
Re:/.Jのnamazu.cgiをとめろ！ 今すぐ！ (スコア:2, 参考になる)
上にもあるけどログアウトしてたらcookieの中身は読まなかったので、ログアウトするしか。
＃といいつつID。
Re:/.Jのnamazu.cgiをとめろ！ 今すぐ！ (スコア:2, 興味深い)
ここを旧パスワードもチェックするようにすれば、少なくともパスワードを変えられてしまう事は防げるんじゃないだろうか。
割と一般的な仕様ではあると思いますが。それでも、メールアドレスなどの個人情報を覗かれるのや、荒らしに使われたり日記削除などされる事に関しては防げないけど、最低限の防御体制ということで。
あと、もし可能ならばだけれども、自分のIDにログインしたユーザのIPなどの記録が閲覧できるといいですね。自分だけでいいので。
そうすれば、悪用された可能性の自己チェックができます。
パスワード変更 (スコア:2, 興味深い)
新規アカウント取得のときmax24文字のパスワードが指示されていて、設定できる
（20文字以上のパスワード設定なのでログイン不能におちいる）
というバグというか新規ユーザへの罠は改善されたのでしょうか？
あと、パスワードに使用できない文字が指示されていない罠とかも。
（これも、パスワード設定はできるがログイン不可になる）
Re:/.Jのnamazu.cgiをとめろ！ 今すぐ！ (スコア:1)
今回のインシデントをきっかけとした改善点として，この仕様（？）は修正するべきだと思います。パスワード変更時に旧パスワードを要求するようになれば，Cookieをぬきとられても，パスワードを変更されてアカウントをのっとられる危険が大きく減ります。
アカウントののっとりが発生するととんでもないことになります。のっとられたアカウントがある程度以上ある状況では，アクティブなユーザーに対して「このIDは本来私のものだったのにのっとられた」と管理者に連絡する，という「攻撃」が可能になってしまいます。
私はPerlがほとんど読めないのでコードをちゃんとチェックしてないのですが，現在のSlash Codeでは「のっとられたアカウント」と「正規のユーザーが使いつづけているアカウント」の区別をつけるのがシステム的に非常に難しいのではないでしょうか。
このような「攻撃」がおこなわれると，多くのIDを無効化する必要が出てしまうでしょう。結果としてSlashdot Japanというコミュニティ自体に取り返しのつかないダメージを与えることになってしまいます。
Re:/.Jのnamazu.cgiをとめろ！ 今すぐ！ (スコア:1, 参考になる)
＞実際どれくらい危ないんでしょうか？
/.Jのセッションをのっとられた場合，何より怖いのは
ユーザー情報にアクセスされて，登録しているメールアドレスを
みられる，ということだと思います。リアルのアドレスを知られると
高い確率で身元が割れます。
Re:/.Jのnamazu.cgiをとめろ！ 今すぐ！ (スコア:0)
そんなに重要なメールアドレスを登録しているんですか？
スラドの登録アドレスごとき、フリーのウェブメールで十分では？
リスクを背負わせる場所を間違っているような感じがしますが。
Re:/.Jのnamazu.cgiをとめろ！ 今すぐ！ (スコア:0)
mail addressを/.なんかに登録しちゃいかんでしょう。
Re:/.Jのnamazu.cgiをとめろ！ 今すぐ！ (スコア:0)
スラッシュドットジャパンもヤバいじゃん！ (スコア:3, すばらしい洞察)
Re:スラッシュドットジャパンもヤバいじゃん！ (スコア:2, 参考になる)
とりあえず全員スラッシュドットからログアウトしたほ (スコア:1, 参考になる)
Cookieを盗まれるとアカウントを乗っ取られます。
スラッシュドットはログアウトすればCookieが消える仕組みだったはず。
既にやられたと思う人はパスワードの変更をお忘れなく。
スラッシュドットはCookieの内容はパスワードのMD5ですから、
変更しないといつまでも乗っ取られますし、
変更すれば大丈夫です。
Re:スラッシュドットジャパンもヤバいじゃん！ (スコア:1, 参考になる)
それはそれとして、バージョンが古いから問題だとは単純には言い切れません。まず/.-JのマシンはDebian Woodyなんですが、backportという形でsecurity fixがリリースされるというのは有名な事実ですね。それからNamazuの場合テンプレートをコピーしてカスタマイズするというのがよく行われるのですが、プログラム自体は更新してもテンプレートはそのままなので、そこに記述されているバージョンも古いというパターンがあると思います。まあこれは放置している方が悪いというか、そもそもテンプレートからバージョン番号は消しといた方がいいとは思いますけど。
何故TAB (スコア:3, 興味深い)
"output.c: html_print()" の設計方針がまったく理解できない。
\x01や\x02にも特殊な意味を割り当ててるようだし
web経由でやってくる汚れたデータを扱う場所で
なぜそのような独自メタ文字を定義するのかな。
手を抜くという目的のためなら手段を選ばない。誰だって犠牲にする。
大人って汚いね。
unhtml_buffer()なんて
条件によってはループが終るときi==BUFSIZEだけど
そのあとbuf[i]にカスを突っ込んでるから他所の土地に手を出してることになる
安全のためにstrncpyを多用してるみたいだけど
strncpyは溢れたとき自動で末尾に留め具NULを置いてくれないから
strncpyを呼んだ後に自分で置かなきゃならないのに放置しているところ沢山
ほんの数十秒眺めただけで気持ちの悪いコードが沢山見えた。
気持ち悪い原因は埋め込まれている沢山のHTMLタグが原因かもしれないけど。
探せばもっと出るんじゃない？
表に出てないだけで実はいくつもの脆弱性が裏では有名になってるのではないかと
思ってみるテストとか言ってみるテスト。
本気でセキュリティーを重視したければnamazu.cgiは選択の候補から外すことか。
Re:何故TAB (スコア:1)
こういうことがやりたいときにはこういう実装が一般的、みたいな
暗黙の了解っていうのはプロのプログラマー（変な表現！）の人たちは
何処で身につけられるのでしょうか？
学校、自分の経験から、会社の先輩から、他人のソースを読んで、
とにかくヒラメキ、そんなのがわからん天才以外プログラミングしてはいかん、etc・・・
勉強がてらの趣味プログラムしか経験していない私ですが
その課程で一番プログラミングに必要とされる知識は
結局そういう実装上の常識？みたいなもんなんじゃないかと痛感しました。
大きな意味でアルゴリズムだと思うんですが
教科書に載ってるような純数学的っぽいエッセンスのようなものではなくて
もっと軽い一般常識とかマナーとかの次元にあるようなルールみたいなものです（表現しづらい）。
自分の経験だと試行錯誤な経験と人のソースを読む
ってことで地道に身につけてくしかないかなぁ、道はスゲェながそうだ・・・
という結論に達したのですが皆さんはどう思われるでしょうか？
あとプログラマーの人たちの間ではこういう常識のあるなしで
こりゃすごいプログラマーだとかそいういうのを判断する材料にしてたりするんでしょうか。
それともとにかく動くプログラムを書く人が一番偉い人？
なんか曖昧な表現が多くてなおかつ野次馬根性全開な質問ですが
皆さんのご意見が伺えれば幸いです。
Javaなどの高級な言語を使いましょう (スコア:1, 参考になる)
ソフトウェアエンジニアリングとアルゴリズムだけに注力したいのなら、そのような些末にとらわれない言語を使うべきです。
# もちろん、Cを使わなければいけないときもありますが。
いったん「何をするべきか」「何をするべきではないか」が分かってしまえばいいんですけど。
> 自分の経験だと試行錯誤な経験と人のソースを読む
> ってことで地道に身につけてくしかないかなぁ、道はスゲェながそうだ・・・
> という結論に達したのですが皆さんはどう思われるでしょうか？
ある問題をCで書き表すとき、その方法にはいくつかありますよね。
私はそれらの選択肢を頭の中でアセンブリ言語に直し、もっとも単純で、できれば高速になるものを選びます。
高速化はこだわらない方がいいですね。機械的に出来る最適化はコンパイラがやってくれますし、数回しか
実行されないところを高速化してもしょうがない。
それよりはソースが単純なものになるように書きましょう。
そうすれば、あとで(自分を含む)誰かが読んだときに分かりやすいですし、変に凝った書き方をするよりも
高速かつ安全であることが多いです。この辺りはCに限りませんけどね。
変なソースを読むよりは、「意識してプログラムを書く」方がお勧めですね。
あとK&Rをきちんと読みましょう。
あの本には標準ライブラリ関数を実際に作る話がたくさん出てきます。自分でもやってみましょう。
処理系で実装は違えど、内部でどんな処理をしているかを知っていれば、取捨選択やコスト計算が出来るようになります。
あとやってはいけないこともね。ついでに関数ごとの細かい違いも頭に入りますし。
# fputs() と puts() の出力の違いとか。 :)
Re:Javaなどの高級な言語を使いましょう (スコア:2, 参考になる)
＞(理解出来ない|まともに使えない)、Cの欠点です。
＞ソフトウェアエンジニアリングとアルゴリズムだけに注力した
＞いのなら、そのような些末にとらわれない言語を使うべきです。
C言語はもともとメモリ操作が容易にできることを想定して
作られているので、それは仕方ないのかなあ、とも思います
私がむしろ問題だと思うのは、
＞あとやってはいけないこともね。ついでに関数ごとの細かい違いも頭に入りますし。
＞# fputs() と puts() の出力の違いとか。 :)
こちらでしょうか。コンパイラ実装の容易性を優先して、コーディングの容易性を犠牲
にしすぎているように思います
Re:何故TAB (スコア:1)
# パターンくらいはあるんだけど。代表的なのは文字列の終端。
# Cは言語もライブラリも境界にルーズだからね。
必要なのはコンピュータの動作を脳内でエミュレーションする事と、
とことん悲観的に、意地悪くなることかなぁ...
>そんなのがわからん天才以外プログラミングしてはいかん
そんな事はないし、最初から天才な奴もいない。試行錯誤が役に立つ
場合もあるし、アルゴリズム辞典牽いた方がいい場合もある。一般解
はないと思う。
Re:何故TAB (スコア:1)
サンデープログラマからすると、本に載っている内容を
少し変更して組み合わせたりするのをよくやります。
セキュリティーホールによるアップデートの報告のたび、
「俺がネットワークプログラミングしたら、こんなの連発
だろうなぁ」と思います。
-- gonta --
"May Macintosh be with you"
必ず逆を考える (スコア:1)
よく聞くのはすべての場合を考えろってことですかね。
何かをする場合、出来ないときはどうなるのか、しなくて良いとき、いけないときはどんな時かとか、ある変数を使う場合、正しい値の場合はどんな時か、正しくない値はどうするのか、等々と、それらをチェックしなくて良い理由と範囲を明確にする。そうでなければチェックする、そんな所でしょうか。
＃で、それを見落としたり、勘違いしたりしてバグると。
Re:何故TAB (スコア:1)
恥を忍んで人に見てもらうってのが早道なのかもね、と言う提案でした。
Re:何故TAB (スコア:0)
>"output.c: html_print()" の設計方針がまったく理解できない。
ソース見てないからはっきり言えないが
Unicodeの一バイト目ならそういう処理もあるんじゃね?
Re:何故TAB (スコア:0)
Re:何故TAB (スコア:0)
Unicodeって……たぶんUTF-8のことを指してるんだろうけど、その程度の理解なら普通にコーディングしてください。
Cの場合の"普通"とは、iconvやワイド文字処理関数を使い、直接触らないということです。
Namazuいらない (スコア:3, 興味深い)
結局、Googleで探したほうがよっぽどマシなわけで…。
役に立たない検索機能を放置するよか、Namazu自体を取っ払った方がよろしいのでは？
# とりあえず様子見で、当面はAC。
Re:Namazuいらない (スコア:2, 参考になる)
適当に検索すると「セクション無所属」だけが検索されるみたいです．
旅に出ます．(バグを)探さないで下さい．
Re:Namazuいらない (スコア:2, すばらしい洞察)
Namazuを取り払って、"site:slashdot.jp" つけてGoogleを呼び出すフォームを取り付けたほうが、ユーザとしてうれしい。管理者も楽になってうれしいんじゃないかな。
Re:Namazuいらない (スコア:0)
Re:Namazuいらない (スコア:2, 興味深い)
相変わらず、古い記事しか検索に引っかからないようですね。ex) 「脆弱性」で検索、日付でソート [srad.jp]
Index の更新は行なわれているのでしょうか?
むらちより/あい/をこめて。
Re:Namazuいらない (スコア:1)
Namazuの記事は「脆弱性」というキーワードではなく、
「クロスサイトスクリプティング脆弱性」で分類されているんじゃないでしょうか。
試しに
「*脆弱性*」 [srad.jp]で検索すると表示されました。
これってKakasiとかChasenとかの問題？
Re:Namazuいらない (スコア:1, おもしろおかしい)
人はそれをバッドノウハウと呼びますが、ええ。
＃スラドでのNamazu検索にはさらに一層のノウハウが……あっても使えない気がするのは何故？
N-Gram じゃないから？ (スコア:1)
カスタマイズした辞書 + 形態素解析ならうまくわかち書きできる？
いま、「東京都」のわかち書きってどうなってるんだろう。
屍体メモ [windy.cx]
Re:Namazuいらない (スコア:0)
見つかるケースを何度も経験した。
/. の namazu はまったく信頼してないので試さないけど、
今はもう直っているのかね?
リンク先を確認しても対策にならない (スコア:2, 参考になる)
Re:リンク先を確認しても対策にならない (スコア:1)
その通りでした。対処は終わりましたが、誤解を招かないように当該部分は削除しました。ご指摘ありがとうございます。
pnamazuは大丈夫？ (スコア:1)
こっちは大丈夫なんでしょうか。
サイトには
＞2001.11.28 までのバージョンは、 cross-site scripting 問題が残っていました。
と、ありますが今回の件とは無関係？
Re:pnamazuは大丈夫？ (スコア:2)
pnamazuのバージョンは2002/11/16のものです．
query=%09%22%3E%3Cscript%3Ealert('XSS')%3C%2Fscript%3E
としてみましたが，検索フォームに"{ >alert('xss') }"と出ただけです．
今回の件に関しては問題ない模様．
# パッケージに最新のnamazuが降りてくるのを待ったり，namazuだけコンパイルしなおしたりするのは面倒なので，pnamazuにしておこうかな．．．
旅に出ます．(バグを)探さないで下さい．
Re:pnamazuは大丈夫？ (スコア:1)
Re:pnamazuは大丈夫？ (スコア:0)
それよりも (スコア:1)
むーん (スコア:0)
#NamazuユーザーじゃないのでAC
あいたたた... (スコア:0)
どうりで (スコア:0)
Re:Exploit (スコア:0)
# それ以前に全文検索になってないからGoogleばっか使ってて、
# Namazuが/.-Jにもあるの忘れてた馬鹿なのでAC・・・
Re:Exploit (スコア:0, フレームのもと)
# せいせいどうどうと胸はないけど張って
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:Exploit (スコア:0)
# 馬鹿モデ酷いな
Re:"とりあえず"？ (スコア:1)