FreeStyleWiki 等で発覚した脆弱性。
JP Vendor Status Notes: http://jvn.jp/jp/JVN%2398836916/index.html
Diff に時間がかかるとのこと。YukiWiki ではだいじょうぶでしょうか？
- あります。
- この脆弱性(?)は非常に単純で、違いがいっぱいあると差分計算に時間とメモリが必要、というものです。
- 例えば、あるページに3万行ありその全ての行を書き換え更新すると、差分の計算に15分程かかり、メモリは80MB程消費します。
- これを複数のページ(10〜20ページ程)に対して同時実行すれば、サーバは最悪ダウンします。
- 対策としては、Webサーバ側でリソース制限を行うか、YukiWiki側で常識外れに巨大な差分が生じる時は、差分の更新をしない処理をするしかないと思います。
- YukiWikiならsub do_writeにある差分書込の処理を↓な風に変えればO.K.ですかね。
- $diffbase{$form{mypage}} = &difftext(?@msg1, ?@msg2) if (@msg2 < 1000);
- ページ内の行数の方を制限したらだめですか？
- むしろそれが本筋ですね。ただ、私はなるべく制限をしたくないので、difftextを止める方を選んだんです。
- 行数制限ならかなり厳しくしないと駄目ですね。
- 1000行でdiffを止めるという処理と同等の結果を得たいなら、1000行の行数制限をすればいいだけでは？
- ページ内の行数制限だと厳しくしないとダメってのは、なぜそう思うんですか？同じ事ですよね。
- ちなみに、実際改造する場合の容易さは違いですね。YukiWiki内部では書き込みされた情報はスカラー変数で持っているので、行数を算出する必要があります。difftextで処理する箇所では、配列に移しているのでif文一発で処理できます。
- YukiWiki 2.1.3が公開されていますね。
- YukiWiki 2.1.3 では 「書き込み長さの最大制限」が設定できます。こちらは、行数ではなく、文字数を対象にしていますね。
- diff機能が問題となってるのは処理時間が最悪O(n**2)かかるという事です。100行の処理に10m秒かかるなら、1000行の処理に1秒、三万行の処理に15分かかるという事です。
- この処理時間は行数によります。つまり最低1文字+改行コードの2byteで、3万行をリミットにするなら約59kb、1000行なら2kbです。
