k3c 曰く、 "Apache Foundationのアナウンスによると、Apache HTTPサーバのモジュールmod_aliasとmod_rewriteに、正規表現で9つ以上のcaptureを使うとバッファオーバーフローが発生するというバグが発見されたとのこと。また、バージョン2系列ではMPM使用時にmod_cgidの出力が間違ったクライアントにリダイレクトされるというバグも発見されている。これらを修正した新しいバージョン2.0.48および1.3.29が既にリリースされている。
どのバージョンからこのバグが含まれていたかという記述は…ないみたいですね…。"
mod_alias.c の場合 (スコア:3, 参考になる)
# そのまま引用しようとしたら、投稿フィルタに引っかかった...
この手のバグ(というかプログラマの怠慢といっていいかも)は実際のプロジェクトでも結構ありがちだと思うんですが、個人の意識向上といったもの以外に、有効な対策はないものでしょうか。
-- cooper
Re:mod_alias.c の場合 (スコア:3, 興味深い)
Revision: 1.17, Tue Jul 8 03:45:28 1997 UTC (6 years, 3 months ago) by akosut
ここで問題のバグが入って6年3ヶ月に渡って気付かれなかった模様。
今現役で動いてるApacheは1.xも2.xも全部影響受ける気がする。
Re:mod_alias.c の場合 (スコア:0)
てか、未だに1.3.27以前を結構見るよ。
もちろんパッチ当てた形跡無し。
#他人様のサーバーにゃ手を出しちゃいけねぇよ。
パッチ当てた形跡無しって (スコア:0)
実際にセキュリティホール突いてみたんですか？
debianみたいにバージョン上げずにバックポートしてる場合もあると思うんですが、それって普通にブラウザ等でアクセスする範囲内で判別つきます？。
Re:パッチ当てた形跡無しって (スコア:1)
判別できないでしょうね。しかし1.3.9に1.3.28とか1.3.29までバックポートするって結構大変かも。
# 何で1.3.9か、って？
# 1.3.9を使い続けている所があって。
# サーバのお守りを受託している会社が無気力、無能力で。
# 勿論、単にアップデートしていないだけですが。
Re:パッチ当てた形跡無しって (スコア:0)
w3mのように "v" キー1発でhtmlをplain textとして閲覧できたり、
"=" キー1発でresponce headerや文字コードなどの情報を参照ができたり、
framesetの構造を簡単に把握(?)できるものもあります。
それらが困難なウェブブラウザーもあります。
open sourceのブラウザーを改造してみたり、
自分でブラウザーを新規
Re:パッチ当てた形跡無しって (スコア:0)
だけなのか、バージョン表記はそのままでパッチあててあるのかを
区別できるんですか?
Re:パッチ当てた形跡無しって (スコア:0)
「『w3mのようにソースやヘッダーを簡単に参照できるブラウザーもあれば そうでないブラウザーもある』という例を示すことによって、 『ブラウザーといってもその機能はブラウザーの種類によ
Re:パッチ当てた形跡無しって (スコア:0)
実際のOSのバージョン番号が異なっていることを
パケットヘッダーを観察することによって判断できることと同じです。
httpdがレスポンスヘッダーによって返すバージョン番号と
実際のバージョン番号が違っていることを判断するための観察機能を
持ち合わせるブラウザーを用意してもいいし、
Re:パッチ当てた形跡無しって (スコア:0)
Re:パッチ当てた形跡無しって (スコア:0)
> debianみたいにバージョン上げずにバックポートしてる場合も
> あると思うんですが、それって普通にブラウザ等でアクセス
> する範囲内で判別つきます？
に対してw3mとかのネタを出してゴネたお前が頓珍漢。
Re:パッチ当てた形跡無しって (スコア:1)
とかのお尻の "Debian" のことを言っているのかな？
でもやっぱりこれだけじゃパッケージをアップグレードしているのかどうか判らないけど。
Re:パッチ当てた形跡無しって (スコア:0)
「普通にブラウザ等」
という意味不明な未定義俺様用語が出た時点でアウトです。
それに対する発言が元に噛み合っていなくても
元の発言の責任の範囲内です。
Re:パッチ当てた形跡無しって (スコア:0)
> という意味不明な未定義俺様用語が出た時点でアウトです。
あなたの脳みそがアウトなだけでは。
こういうのがいるから技術者は頭が固いとか言われるんだよね。
Re:パッチ当てた形跡無しって (スコア:0)
> httpdがレスポンスヘッダーによって返すバージョン番号と
> 実際のバージョン番号が違っていることを判断するための観察機能を
> 持ち合わせるブラウザーを用意してもいいし、
そんなブ
Re:mod_alias.c の場合 (スコア:2, 興味深い)
あるいは現状よりも強化するってのが必要なんじゃないかと。
ずっと以前に聞いた話では apache httpd のチームはその
コード変更を取り込むかどうかはコアメンバで投票しあって
決定するとかそんな感じだったような気がするのですが、
現状はそのあたりの仕組みはどーなっているのでしょうか。
Re:mod_alias.c の場合 (スコア:1)
と感じています。
日頃の意識(長さチェックは厳密にとか)
コーディング規則のチェックシート
レビュー
などなど
バグ発生後も
なぜなぜシート
を作ったりして個々の意識を高めていくと。
そして結局はCASEなどには勝てないと思いますし。
バグ統計を聞いて愕然としました。
Re:mod_alias.c の場合 (スコア:1)
日頃の意識という意味では、プライオリティの高い順に、以下のような点に注意して進めています。
- 仕様を満たしていること
- メンテナンス性が確保されていること
- そこそこの移植性を確保していること
- そこそこのパフォーマンスを確保していること
パフォーマンスに関しては、まずほとんど問題になることはないですね。多少効率が悪くても、メンテナンス性や移植性に優れるなら OK というスタンスです。もちろん、仕様に記述された最低限のパフォーマンスは確保されます。レビュー時には過去の経験をもとにいろいろな角度からチェックしますが、C なら lint にパスしたコードを対象にしてます。あまりにも泣きたくなるような警告については、無視することもありますが...
-- cooper
Re:mod_alias.c の場合 (スコア:1)
まあ、チェックが自動で出来たとしても、結局個人の意識が無いとダメなんでしょうけど。CVSコミットごとにチェックを自動で書けて、常にメールが流れる、とかやっても無視する人は無視しちゃうでしょうし。
-- Takehiro TOMINAGA // may the source be with you!
Re:mod_alias.c の場合 (スコア:2)
すばらしいツールをお持ちでしたら
是非、まだ発見されていない apache の潜在的な問題を見つけて
apache にフィードバックしてください。
Re:mod_alias.c の場合 (スコア:2, 興味深い)
ってのは冗談ですが。
ちょっと参考URLとか出せないのが弱いんですが、ツールによるチェックが元で見つかったapacheとかLinuxの脆弱性ってのは結構あると聞いています。bugtraq とか見てるとそれなりの頻度で「このバグはXXを使って自動チェックの結果を確認することで発見した」みたいなメールがきてます。
なので、この手のツールはそれなりに有効だと思います。が、問題は「誤認識」「誤警告」が多いうえ、(特に実行時チェックを行う系のelectricfenceとかは)異常に遅いという点だと思います。
また、大量に出る警告の中から、問題を拾い出すだけでもかなり大変です。自分が担当している一万行程度のコードが相手ならともかく、第三者の書いた何十万とあるコードのバグ発見てのはかなり辛いんですよね。
まあ、世の中の(スクリプトキディーでない)「本当のクラッカー」さんはそのへんをやってるんでしょうけど。
正直、他人のコードのデバグよりは自分の好きでコードを書くほうが楽しい、というのは事実だし…
-- Takehiro TOMINAGA // may the source be with you!
Re:mod_alias.c の場合 (スコア:0)
その警告を多くの人に流す、もしくは誰でも見れる位置に置くことによって
無視しない人が一人でも現れれば、誰かがそのバグの存在を認識できるので、
誰もそのバグの存在に気づいていなかった状況から比べれば雲泥の差です。
Re:mod_alias.c の場合 (スコア:1)
現状では、他人（第三者）が介在しにくい状況だろうし、とすると道具に頼るしかないか。
ヘンなコードだと保存できないエディタとか（保存する際には、矯正してしまうとか）、ヘンなコードだと、こんなんコンパイルできるか！ボケっ！！とかいってオブジェクト吐かないヤツとか。
Re:mod_alias.c の場合 (スコア:0)
頑張る必要はあると思いますよ。
道具が検出しても「悪用できそうにない」と判断して修正しない
人がいるかもしれません。で、半年後に思わぬ方法で悪用され
ちゃうとか。
そ
Re:mod_alias.c の場合 (スコア:0)
その状況に問題があるのでしょう。
XPをしろとは言わないけれども、丹念なコードレビューをすれば、
「個人で完結する」状況とはならないと思います。
やはりapacheの開発体制に問題があるのでしょう。
Re:mod_alias.c の場合 (スコア:1, 興味深い)
えーーと。まったく別問題だったりするのですが Apache ネタ
という事でここに書かせてもらいます。
ab(Apache Bench)にも同様なバグがずいぶん前から付いています。
具体的には URL を格納するバッファが 1024Byte 固定になっているので
長いURLを ab に処理させようとすると ab が落ちます。
問題のコードの 1.3.29 のものを見てみましたが、相変わらず
strcpy で 1024Byte の配列にコピーしているなぁ...
# 報告の仕方がわかってないのでACで
Re:mod_alias.c の場合 (スコア:1, 参考になる)
> strcpy で 1024Byte の配列にコピーしているなぁ...
grepすればまだまだアヤシゲなstrcpyを目にすることができるのですが
それに関しては次回のお楽しみかな?
char buffer[300];
if (DosSearchPath(SEARCH_ENVIRONMENT, "PATH",
interpreter+2,buffer, sizeof(buffer)) == 0) {
strcpy(interpreter+2, buffer);
環境変数から得られた文字列を300 byteのauto変数にstrcpyしてみるテストとか。
Apacheは全体的に
char buffer[300];
のようなマジックナンバーによる確保が多いです。
strcpyやsprintfといった関数の使用が多くてその前後が無頓着です。
脆弱性ネタの宝庫なのでこれからも小出しにバージョンアップする予定?
# こんなものをサーバーとして使っているのが不思議
Re:mod_alias.c の場合 (スコア:2, 参考になる)
> すがそれに関しては次回のお楽しみかな?
この文が続くコード中のstrcpy()が怪しいという意味なら、それは違うんじゃないか、と。DosSearchPath()で事前の縛りを入れてるでしょう。
> のようなマジックナンバーによる確保が多いです。
> strcpyやsprintfといった関数の使用が多くてその前後が無頓着です。
一概に無頓着とは言えないと思いますよ。釈迦に説法とは思いますけど、一応。Ｃでデータの移し替えをやる場合、元データと同じサイズの領域を確保する方法と、適当な大きさの領域を確保しておいて事前にバッファ溢れをチェックを行う方法とがありますね。
元コメント(#423858)にあったコードは後者の方法。レビューの際には「妥当」とされるコーディングです。もしもこれに「不適当」と言ったら、「Ｃを勉強して来い！」と言われかねないです。
sprintf()は、無頓着は良くないですね。明らかにOKな場合(intを文字列化したテキストを得る、とか)を除いてやはり事前チェックは必要でしょう。それは結構面倒臭いので、自前ライブラリに動的確保を行いつつsprintfする関数を入れて置いたりしますけど。
Re:mod_alias.c の場合 (スコア:0)
> レビューの際には「妥当」とされるコーディングです。
> もしもこれに「不適当」と言ったら、「Ｃを勉強して来い！」
> と言われかねないです。
apacheのようなソフトウェアは以下の特徴があります
・世界中の大勢の人が利用する(apacheを設置する)
・そのユーザー(apacheを設置する人)の多くはソフトウェアに対して強い安全性を求める
・二次的なユーザー(apacheにアクセスする人)の中には
攻撃の意思と十分な技術を持つ者が多く存在している。
なおかつ彼らは攻撃
Re:mod_alias.c の場合 (スコア:2, 興味深い)
#423858のコードは、クリティカルな用途のソフトでも「妥当」とされると思いますよ。問題はそこでしょう？レビューがどうのは直接関係ありません。
なら、「不適当」である理由を述べたらどうでしょう。どんなレベルのレビューにしても、説明もせずに「不適当」と言い放つのは、まともなエンジニア、マネージャのする事ではありませんから(実際には多いですけどね）。
Re:mod_alias.c の場合 (スコア:0)
それとも、レビュワーはプログラムの用途なぞ考慮する必要がないとでも？
＃それすらスキルの内ということであれば、それはそれでレビューの意義をいくつか捨
Re:mod_alias.c の場合 (スコア:0)
誰が「不適当」だと言ったのですか?
理由だけ存在されても怖い
Re:mod_alias.c の場合 (スコア:0)
官僚のコメントのように解釈に悩む表現ですね。
これは結局のところ「関係がある」という意味になる？
> それよりも、レビューをどれだけ真剣にやるか、レビューの参加者にどれだけの
スキルがあるか、の方が。それを経由すれば質と重大性に全く関係ないとは言いませんが。
これもいろんな解釈が可能。
> #423858のコードは、クリティカルな用途のソフトでも「妥当」とされると思います
> よ。問題はそこでしょう？レ
Re:mod_alias.c の場合 (スコア:0)
> ・そのユーザー(apacheを設置する人)の多くはソフトウェアに対して強い安全性を求める
> ・二次的なユーザー(apacheにアクセスする人)の中には
> 攻撃の意思と十分な技術を持つ者が多く存在している。
> なおかつ彼らは攻撃に特化したクラ
Re:mod_alias.c の場合 (スコア:1)
もともとA Patch というくらいだし、これからもどんどんパッチを当ててくのではないでしょうか。
Re:mod_alias.c の場合 (スコア:0)
これって「脆弱性」なんですか？ (スコア:1)
Buffer Overflowをおこすように読めるんですが。「外部から」の
入力によって落ちたり乗っ取られたりするのが「脆弱性」であって，
設定とかの「内部から」の入力で落ちるのは，単なるバグというのでは
ないでしょうか。
# 正規表現の「キャプチャー」を，いまいち理解していないから
# 変なこといってるんだろうか。括弧を使わなければいい，
# というわけじゃないのか？
Re:これって「脆弱性」なんですか？ (スコア:3, 参考になる)
mod_rewrite のディレクティブは一部を除き .htaccess でも使えるので，脆弱性と言えるのでは?
HIRATA Yasuyuki
納得 (スコア:1)
使用可能にしているプロバイダとかでは問題になりますね。
感謝！
Re:これって「脆弱性」なんですか？ (スコア:0)
可能性があるので、十二分に脆弱性です。
Re:これって「脆弱性」なんですか？ (スコア:0)
設定ファイルを利用しているときの脆弱性では?
少なくともApacheが読む設定ファイルを書くことができるのは第三者ではない。
Re:これって「脆弱性」なんですか？ (スコア:0)
Re:これって「脆弱性」なんですか？ (スコア:0)
「脆弱性」なのか「脆弱性以外のバグ」なのかは、
modules (スコア:1, 興味深い)
オプションのモジュールも一緒に使用している人もいると思いますが、
その場合、本家apacheのバージョンが上がっても
すぐにはついていけないとか、手間がかかるとかあると思いますが、
それに悩むみなさんどのようにお過ごしですか？
できましたらアイデアや技を自慢してください。
mod_ssl-2.8.16-1.3.29 (スコア:1)
# さーて、入れ替えだヽ( ´ー｀）ノ
-- daemontools.
Win32 binary (スコア:0)
Build環境が(用意出来)無いからとかでしょうか？
Re:Win32 binary (スコア:1)
Re:Win32 binary (スコア:1)
http://www.apache.org/dist/httpd/binaries/win32/
http://nagoya.apache.org/mirror/httpd/binaries/win32/
Re:Win32 binary (スコア:0)
Re:FreeBSD では... (スコア:1)
apache 1.3も40時間前に更新された [freebsd.org]模様です。