デサフィナード事件2007年02月01日 14時51分02秒

資料性の高い弾さんの記事が読売新聞に著作権侵害だと突付かれて消されかねない可能性を鑑み、とりあえず魚拓とっておきますた

# Internet Archive に保存させるにはどうすりゃいいんだっけ?

あ、あと画像 2 つも魚拓とっておきますた (1 / 2)

ギザヘナード事件2007年02月01日 15時18分35秒

しかし大変な事件がおきましたね。ネット上にはまだニュース記事が出てきていないようなので、新聞記事から以下、抜粋しておきますね。

鼻歌を歌いながら著作権使用料の支払いを拒否するのは違法として、日本音楽著作権協会が館山市のレストラン「ギザヘナード」経営者の鼻之下伸夫さん(56)を相手に鼻歌差し止めなどを求めた訴訟の判決が30日、千葉地裁であった。山田淳次裁判長は「将来的にも著作権侵害行為を続ける恐れがある」として演奏差し止めや鼻毛の除去、損害金約 190万円の支払いなどを命じる判決を言い渡した。

しかし今後はアレだね、むかつくお店を潰すには、そのお店に毎日通って歌を歌えばいいんだ。実に簡単だね。。。!!

IPAを甘やかすな2007年02月02日 09時23分03秒

とりあえず、今回のケースでは、はまちや2さんは IPA という独立行政法人に、本名という個人情報 (個人属性?) をあずけたくないという意思表示を示しているという点を無視するべきではないと思いますよ。例えば、警察へ通報を行う際には、必ずしも実名を名乗る必要はありません。

IPA が脆弱性の報告に際して氏名と連絡先の提示を求める根拠は、FAQ の中で説明しています。その根拠というのが中川昭一元経済産業大臣による告示な訳ですが (注: PDF ファイルです!!)、この中では、報告者が氏名を明かさねばならない理由については触れられていません。仮に、情報の信頼性を担保する為なのだとして、それが信頼しうる有効な情報であることを検証する能力が IPA に無いのだとしたら、それはそれで問題なのでは無いでしょうか? (「正確な情報」である必要は必ずしもありません。発見者が脆弱性の危険性について正しく検証できないケースは多々あります。しかしどのような程度の脆弱性であれ、報告の仲介を担う行政機関である以上、開発元に情報を渡し、議論を進める義務はあります。) その検証の根拠を「氏名」といった個人情報の提示に求めているのだとしたら、IPA という機関は無能であると断ぜざるを得ないし、そのような機関を信用して利用しようとする人は少なくなるかもしれません。

kyoumoe さんが言わんとすることもわかります。物事を前に進める為には、お互いの協力関係が必須であり、それを円滑に進める為のコミュニケーション作法はあってもいいだろうと。そしてその作法に準じないはまちや2さんの行動を囃し立てる行為を「幼稚だ」と断じたくなる気持ちもわかります。

しかし、世の中にはいろんな人がいる。はてぶでの反響が大きいだけに、多くの人がはまちや2さんの行動を賞賛しているように見えるのかもしれませんが、単純に関連する 3つの記事のブックマーク数だけ見たって所詮は述べ件数でも数百じゃないですか。こんなもん、「そういう人もいる」の域を出ません。全然日本終わってる根拠になんてなりゃしない。

むしろ、こういう、いろんな人がいるからこそ、コミュニケーションにおける作法とか、態度の取り方とかについて、各々が考えながら生きる必要があるんです。みんなが同じように礼儀正しかったら、コミュニケーション作法なんて考える必要も無い。

IPA には今回の件から早めに教訓を得て、報告者の氏名の扱いについて考えを改めて頂きたいです。信頼性に対する薄弱な根拠を担保にすることと、報告の敷居を下げ、コンピュータ利用の安全性底上げを早めること。優先順位は、はたしてどちらの方が上でしょうか?


Fri Feb 2 23:11:21 JST 2007 - 追記

正論ではあるんだが,敷居を下げたら下げたで別の問題も出てくるんだよね.いたずらの届出ばかりになって制度が機能しなくなるのも困りもの.

おいらはその辺についてはあんまり心配していません。現状でもいたずらはもっとたくさんあってもいいだろうし、その度にこの手の返事を返しているんだとすれば既に結構な手間ですし。はまちや2さんも (返信の書面で) 書いている通り、そもそも本名であることを確認する術が IPA にはない、という意味でも、氏名を要求することにあまり意味を感じません。

そもそもそんなはまちや2さんでも、メールアドレスは律儀に伝えているわけですし (当人も連絡を取り合うことの必要性は認識していらっさるのでしょう、っていうかリアクションが返ってくることを期待できなきゃそもそもブログのネタにもならんかw)、そこさえ守らせていれば、厳密なことを言えば実は既に匿名ではないわけで。

ちょwwwwwwww2007年02月03日 09時29分43秒

はてながメンテナンス中なおかげでハイパーリンクがひどいことになってるwwwwww

ああ、そうか。2007年02月03日 10時22分32秒

このコメント書いてから、ふと思ったんだけど、氏名公表しちゃっても構わない人が、氏名公表したくない人の代わりに報告してあげればいいんだ。

ちうわけで、ぜーじゃくせー発見したけど IPA に氏名公表したくない、ってひとは、以下のアドレスまでその内容をメールしてくだちゃれ。暇だったらおいらが代わりに IPA に報告するかもしれないし、しないかもしれませんw

main-window (あ) harapeko.jp

# はまちちゃんにもメールしてみますた。

GoogleAdSense/AdWords を利用した薬事法違反?2007年02月04日 22時30分41秒

これ、AdSense/AdWords に表示される宣伝文句を書いているのは広告主本人なわけだから、思いっきり薬事法その他の法律に抵触しそうな気がするんだけど、どうなんだろう?

ただ、記事内容によっては AdSense を設置しているサイト主にも刑事責任が発生しうる、という話なんだとすると、ちょっと困るなぁ (((((;゚Д゚)))))

勘違いしてたかも<Taint mode2007年02月05日 10時40分58秒

なお、このtaintperlやPerlの-Tオプションを指定した場合、この手のブラックリスト方式のメタキャラクタ漏れによる脆弱性は発生しない(記号を削るという方式では汚染は除去されていないとみなされる)。

$a = $ARGV[1];
$a =~ s/\W//g; # 汚染されている
$a =~ s/^([a-z]+)$//;
$a = $1; # 汚染されていない

というわけで、Perlでは、CGIというものが普及する以前から、

そのため、記号を全部削るという対策が普及しました。

のような対策は「言語として」推奨されていない(それでもそういう対策をしちゃう人は別問題として)。

ホントかな? ホントかな?

試しに、以下のスクリプトを書いてみましたよ。

#!/usr/bin/perl -T
use strict;

my $file = $ARGV[0];
open FH, $file;

コマンドライン引数の値をそのまま引数 2個形式 open の第2引数に渡しちゃっているという、明らかにダメなプログラム例。話をわかりやすくするため、サンプルも敢えてシンプルにいきますよ。

これ、例えば taint.pl なんて名前で保存して実行権限付加しておいて、以下のように呼び出したりしても、Perl は例外を発生しません

murachi@maha ~ $ ./taint.pl hoge.txt
murachi@maha ~ $

で、以下のように、open 命令の第2引数に渡す文字列がモードを指定することになるような値を、コマンドライン引数に指定すると、例外を発生します。

murachi@maha ~ $ ./taint.pl '>hoge.txt'
Insecure dependency in open while running with -T switch at ./taint.pl line 5.
murachi@maha ~ $

それではおさかなラボの人が「これでは汚染が除去されたとは看做されないよ」とおっさられている方法でサニタイズした場合、どうなるでしょうか? (ここでは敢えて、悪意をこめてこの言葉を使用します。もちろん、このようなコーディングを推奨するわけではありません。) スクリプトを以下のように修正してみましょう。

#!/usr/bin/perl -T
use strict;

my $file = $ARGV[0];
$file =~ s/\W//g;   # ←この行を追加
open FH, $file;

ここで、先ほどと同じコマンド呼び出しで試してみると、例外は発生することなく、スクリプトは実行されます

murachi@maha ~ $ ./taint.pl '>hoge.txt'
murachi@maha ~ $

それじゃあ置換操作が行われちゃっているとことごとく汚染フラグは下ろされちゃうのかっていうとそういうわけでもなくて、例えば以下のように、状況的に間違っちゃっているフィルタリングを行っているような場合、

#!/usr/bin/perl -T
use strict;

my $file = $ARGV[0];
$file =~ s/%([\da-f][\da-f])/pack 'H2', $1/eg;  # ←この状況では無意味な置換
open FH, $file;

以下のように呼び出すことで、やはり例外は発生する。

murachi@maha ~ $ ./taint.pl '%3ehoge.txt'
-bash: ./taint.pl: /usr/bin/perl: bad interpreter: Text file busy
murachi@maha ~ $

何故なら間違った置換操作によって %3e> に置換されるから。そして、その状態で open の第2引数に渡すと読み込みモード以外のモードになってしまうので、安全では無いとして例外が発生する、と。

つまり、Taint mode における Perl は、外部入力由来の値について、適切な置換操作による汚染の除去が行われたかどうかに関わらず、その値の使用時に安全性のチェックを行うと。そして、その値を利用する状況に応じて、その値が安全では無いと看做されるのであれば、例外を発生する、ということなわけだわね。

(Mon Feb 5 23:02:22 JST 2007 追記) とりあえず、致命的に間違っている上記の行に取り消し線を入れておきます。詳細は追記以降をご参照ください。

で、ここまで調べてみて、思ったんだけど、Taint mode は安全では無い値の利用について、その値を利用する (すなわち、出力する) 際の水際で、状況に応じたチェックを行い、安全かどうかを検証する。これが意味するところは、すなわち、プログラマーが状況ごとに正しい値の形式を把握していなければ、Taint mode を利用する意味はあんまりなくなっちゃうんじゃないか? っていうこと。

何が言いたいのかっていうと、つい最近、おいらはこんな記事を書いた。驚くべきことに、taint mode でぐぐると、この記事は結構上位に表示されちゃう。で、この中でおいらは、以下のように書いてしまったわけなんだけれども、

で、実際の、(恐らく) 正しい (と思われる) 運用方法ってのは、一通りシステムを作り終えた段階で最終チェック的なテストの一つとして、あるいはある程度組み終えたところで設計の正当性を確認する目的で、んー、どっちかっていうと後者の意味合いの方が重要になってくるのかな、とにかくそんなタイミングで Taint mode を ON にしてみて、動くことをチェックする。それだけ。で、そこで動かなかった場合に、原因と、それに起因する設計上の欠陥を調査し、設計上の semantics を考慮したうえで、修正を反映する。つまり、Taint なデータが流れている場所を見つけたからといって、その場所だけを局所的に直すんではなくて、それを元に (というかヒントの一つ、ぐらいの目安で) 設計自体を見直す、っていう使い方ができれば、いいんでないかなぁとか思うわけです。

実際に、「結果として危険な値」を流すことができなければ、つまりそういうケースを検証するテストデータを用意することができなければ、設計上の欠陥を見つけることもできないのではないか? ついでに言えば、優秀なテスト設計者がテストを作ってくれるならともかくとしても、仮に設計者自らがテストデータを作成するんであれば、危険な値が流れる可能性のあるデータを用意できるという時点で、プログラムの設計上のキーポイントを把握していると言うことでもあるわけで、そう考えると、上記のような目的で Taint mode を利用するってのは、実はナンセンスなんじゃないかと思えてきてしまったのです。

そうすると、やっぱり Taint mode の正しい使い方は、本番環境で使用する、なのかなぁ。なんだろうなぁ。

あ、ちなみに、推奨されるべき実装は、そもそも 2引数形式の open は使用せず、3引数形式の open を使用するか、または sysopen を使用する、なのであったりします。

#!/usr/bin/perl -T
use strict;

my $file = $ARGV[0];
open FH, '<', $file;    # そもそも 3引数形式を使えと

# いちおうこいつにもリンクしとこ。。。


Mon Feb 5 23:02:22 JST 2007 - 追記

かなだまさかつさん、コメントにてご指摘ありがとうございます。

追試してみました。

#!/usr/bin/perl -T
use strict;

my $file = $ARGV[0];
open FH, '>', $file;

3 引数 open を書き込みモードで呼び出す場合、上記では当然例外になります。これは、以下のような呼び出しであっても例外になります。

murachi@maha ~ $ ./taint.pl hoge.txt
Insecure dependency in open while running with -T switch at ./taint.pl line 5.
murachi@maha ~ $

んで、じゃあサニタイズしましょーってな感じで (←こらこら)

#!/usr/bin/perl -T
use strict;

my $file = $ARGV[0];
$file =~ s/\W/_/g;      # ←とりあえず置換してみた
open FH, '>', $file;

とかやっても、まだ値は「危険」と看做されて例外が発生します。これがかなだまさかつさん曰くところの、記号を削るという方式では汚染は除去されていないとみなされる、ということだわね。

んで、以下のように記述すると、

#!/usr/bin/perl -T
use strict;

my $file = $ARGV[0];
$file =~ s/\W/_/g;
($file) = $file =~ /(\w+)/;     # ←ワード構成文字のみ抽出
open FH, '>', $file;

これなら例外発生せずスクリプトは必ず実行されます。Perl は正規表現のキャプチャを用いた値の抽出を、そのデータが取るべきフォーマットとの整合の結果選択される値と看做して「安全」になったのであろうと (つまり、「洗浄」されたと) 解釈するのですね。

てゆか、追記前の文末でリンクしたこいつにもその辺ちゃんと書いてあるじゃん。読めよ>ヲレ (以下、強調は T.MURACHI による)

しかし、汚染の検査は面倒です。あなたのデータの汚染を取り除くだけと いうこともあるでしょう。汚染検査機構をバイパスするためのただ一つの方法は、 マッチした正規表現のサブパターンを参照することです。 Perl は、あなたが $1、$2 などを使って部分文字列を参照したときに、 あなたがパターンを記述したときに何を行うのかを知っていたと仮定します。 つまり、汚染されていないものを束縛しないか、機構全体を無効にするということです。 これは、変数がなんらかの悪いキャラクターを持っているかどうかを 検査するというのではなく、変数が良いキャラクターのみを持っていることの 検査には都合が良いです。 これは(あなたが考えもしないような)悪いキャラクタを見失うことがあまりにも 簡単であるからです。

ちなみに、以下のようなスクリプトを書いた場合でも、例外は発生せず、スクリプトは実行されてしまいます。

#!/usr/bin/perl -T
use strict;

my $file = $ARGV[0];
($file) = $file =~ /(.+)/;  # ←これはひどいw
open FH, '>', $file;

ちうわけで、Taint mode はわかっていて使う分にはそれなりに保険にはなるけど、サニタイズ的な悪しき習慣を改善するほどの特効薬とはなりえず、わかってないで使おうとするとどつぼに。。。いやいや、ちゃんと理解してから使いましょうってことなんでしょう多分 (^_^; 。

そして、先日の記事で書いたような、設計上間違っている部分がないことを確認するための手段の一つとして利用するっていう考え方も、あながち間違いでは無かったのかな、ととりあえず思ってみる。。。いやでも、まぁ、そう結論付けるのはもうちょっとこの辺いろいろとさらってみてからにしよう。m(_ _;)m


Tue Feb 6 01:15:04 JST 2007 - さらに追記

Taint モジュールを利用すれば、汚染チェックを行う出力レイヤーを自作することもできるわけか。。。例えばこんな感じ?

use Taint;
sub safePrint {
    die 'Insecure request'  if tainted @_;
    print @_;
}

明日試してみよう。今日はもう寝るっす。。。

はまちちゃんとこに IPA からよくわからないメールが届いた件2007年02月06日 00時24分12秒

??? なんか、お礼のメールが来たみたいだけど、これってよーするに「受理しました」ってことなの? それとも「受理はしてない (だから仕事はしない) けど、とりあえずお礼のメールだけ返してうやむやにしておきます」ってこと? おいら、じぇんじぇんわかりましぇん >< 。

受理された脆弱性はその概要がここに表示されるらしい (Tue Feb 6 10:43:43 JST 2007 追記: Web サイトの脆弱性はここに表示されるわけではないっぽいです。謹んで訂正) んだけど、はまちちゃんとこにきたメールに書かれてるような書式の ID は見当たらないし、Yahoo! がどうこう、なんて記述も見当たらないし。。。

はまちちゃんが言いたいこともわかるけど (おいらも一部似たようなこと書いたし)、その気持ちが IPA たんには伝わりにくそうな態度しかとってなかったっていう意味では五十歩百歩かなぁ。面白かったけど。

とにもかくにも、IPA がちゃんと仕事をしてくれることを願ってやみません。。。


Tue Feb 6 10:43:43 JST 2007 - 追記

はてブのコメントにて指摘がありました。JVN はあくまで「ソフトウェア製品の脆弱性関連情報」を扱うサイトであって、Web サイトが脆弱であることに関連する情報を扱っているわけではない、ということかと思われます (なのよね?)。謹んで訂正。。。

「いじめ撲滅」のイエローリボン考2007年02月06日 14時24分30秒

てゆか、イエローリボンっていろいろあるのね。どれもそれほど知られているわけでもないような気はするのですが。。。例えば反戦平和のイエローリボンとか (日本語ページはなぜか「イエロー」とは明記されてないし雰囲気も微妙に違うけど)、障害者自立支援法反対運動のイエローリボンとか。

んで、今朝、報道番組を見ていて知ったのが、いじめ撲滅運動のイエローリボンいじめ撲滅ネットワークというサイトの中の人がどれほどのキャンペーン展開を図っているのかは知らないのですが、総和北中学校での事例(これのこと。いや、ぐぐったら上のほうに出てきたんで紹介してみただけなんですが、差別問題に触れていたりする辺り、「いじめ撲滅ネットワーク」とはまったく無関係なのかもしれません)など、「生徒が中心となって自発的に」という構図で活動が展開されているようです(どこまで自発的なのかはもちろん知る由もありません、恐らくネタを持ってくるのは教師なんだろうなぁとは想像してしまう訳ですが…)

千葉県学校教育情報ネットワークのサイトでは、いじめゼロ宣言なる文書が配布されています。Word ファイルなので、閲覧するには MS-Word などのワープロソフトが必要なのですが (OOo で閲覧できます)、まぁそれはそれとして、この文書にも最後の方に「イエローリボン」の単語が出てきます。各学校でご利用くださいとあるので、少なくとも千葉県下の教育自治においては、普及が推し進められていると見てよいのではないかと思われます。

今朝、見ていた報道番組では、とある学校 (やっぱり中学校だったかな、名前とかは忘れた) での取り組みの様子を伝えており、いじめ撲滅を、というよりは、いじめという問題について、考え、議論し、行動する人であることの証として、黄色いリボンをつけよう、というような話になっていて、それをつけるかどうかは強制ではなく自由意志、という形が取られていました。

おいらはこの活動の広がりの規模や内情を知らないので、正直言って易々とコメントできるような義理ではありません。が、取り組みの詳細な形態や意思の違いはあれ、共通して、なんとなく、「ほっとけない世界の貧しさ」キャンペーンに対して抱いた違和感と同様の違和感を感じています。「ほっとけない~」に関していえば、その違和感、というか嫌な予感は的中してしまったわけなのでありますが、、、よーするに、何らかの問題に対して、考え、あるいは議論し、行動する人であることの証を、その人の言動や態度、実際の行動を以って立てるのではなく、白いわっかや黄色いリボンなどといった印に求めるというやり方は、そのまんま「(全体主義的・排除的な) いじめの構図」に直結するのではないかと危惧するのです。ましてやそのターゲットとなるテーマが「いじめ問題」であるということに、ますます違和感は増大します。

この辺、名のある社会学者さんや、教育現場に携わられる方々、その他たくさんの方々に、どのように感じておられるのか、あるいはお考えであるか、ぜひともお伺いしたいところです。

29歳になりますた。2007年02月07日 08時10分59秒

はっぴばーすでー とぅーみー♪

はっぴばーすでー とぅーみー♪

はっぴばーすでー でぃあ おいらぁ~~~~♪

はっぴばーすでー とぅーみーー♪ わーどんどんどんぱふぱふぱふーーー

………。(なんだかちょっと寂しくなってきた)

朝っぱら早くから「お誕生日おめでとうコール」ありがと~♥ >かわいいかわいい甥っ子