水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 2009年のえび日記 > 2009年6月

2009年6月

2009年6月30日(火曜日)

五十円玉二十枚の謎

公開: 2009年7月1日2時0分頃

読み終わったので。

読み始めてすぐ強烈なデジャブに襲われたのですが、冒頭の作は「法月綸太郎の冒険 (www.amazon.co.jp)」に収録のものですね。思い起こせば、当時は北村薫を知らなくて……。

内輪ネタが多すぎて、マニアでない人にはイマイチ楽しめないかも。

関連する話題: 本 / 買い物

2009年6月28日(日曜日)

中国語のSQL系エラーメッセージ

公開: 2009年6月30日14時15分頃

掲示板に、あからさまにspamと思われる書き込みがあったので調査。

検索してみると同種の書き込みがたくさんなされているので、爆撃系ですね。で、なんとなく商品ページのURLの末尾に%27を付けてみたら、文字化けしたメッセージが。エンコードをいろいろ変えてみるとこんな感じに。

Microsoft JET Database Engine 错误 '80040e14'

字符串的语法错误 在查询表达式 'id=2471'' 中。

/product_view.asp，行 55

エキサイト翻訳にかけるとこんな感じ。

Microsoft JET Database Engine 誤り '80040e14' 文字列

の文法の誤り 数式を検索しています 'id=2471'' 中。

/product_view.asp，それで結構です 55

※「行」→「それで結構です」は誤訳っぽいですが、面白いですね。

SQLインジェクションの疑いがあるわけですが、どうしたものか……。情報セキュリティ早期警戒パートナーシップは「主に日本語で記述されたウェブサイト」なら対象になるのですが、なんか偽ブランド品販売の気配もしますし、言ったとしても修正されない気がするのですよね。届出件数が多すぎてキツイという話も聞いているので、華麗にスルーの方向ですかね。

関連する話題: セキュリティ / spam / IPA / 情報セキュリティ早期警戒パートナーシップ

ぱにぽに12

公開: 2009年6月30日13時45分頃

出ていたので。

内容をよく見ないで初回限定特装版を買ってしまいましたが、今回は冊子じゃなくてCDなのですね……。

ゲームセンターCX (www.amazon.co.jp)のネタ(なのか?)が面白かったです。つか、この姫子は「アトランチスの謎 (www.amazon.co.jp)」じゃないのかなぁ。

関連する話題: マンガ / 買い物 / ぱにぽに

2009年6月27日(土曜日)

ドラクエの セーブデータは ただひとつ

公開: 2009年6月30日13時20分頃

「ドラゴンクエスト９のセーブに関する大事なこと (sp-game.cocolog-nifty.com)」。

１本のソフトにセーブできるデータは１つまでだよ！

(～中略～)

ちなみに、ＤＳ版のドラクエ４や５では1枚のＤＳカードに複数のセーブデータがセーブできました。

ドラクエ9 (www.amazon.co.jp)のセーブデータは一つしかないそうです!

ポケモンと一緒……なのですが、くりきんの時にも書いたように、ストーリーが淡泊でやり直しのニーズがあまりないから許されていると思うのですよね。ドラクエはそういうゲームじゃないんで。

※それに、ポケモンは色違いがでるので、色違いを両方とも即買いするやり込み派の人はストーリーのやり直しができます。

ちなみに、ポケモンの場合にはもう一つ現実的な理由があるのだと思っています。以下の条件を両方とも満たすと、困った問題が起きます。

この場合、以下のような手順を行うと……。

重要アイテムが簡単に増殖することになります。脆弱性みたいなものですね。

なので、もしドラクエ9が通信で能動的にアイテムの受け渡しができる仕組みであれば、セーブデータがコピーできない仕様は理にかなっています。まあ、単にコピーできなければ良いので、セーブデータを一つに制限する必要まではないのですが、セーブデータが複数持てるのにコピーできないというのも違和感がありますしね。

……しかし、ドラクエ9って通信でアイテムの受け渡しができるのでしたっけ? その辺、よく分からないですね……。

※ちなみにポケモンは内部的にはセーブデータを2つもっていて、片方をバックアップに使用しています。それを悪用した増殖技もあるようですが……。

関連する話題: ゲーム / ドラクエ / ドラクエ9

ぐーぱん! 2

公開: 2009年6月30日2時15分頃

見かけたので購入。

赤城さんは不幸キャラ確定で。相変わらず方向性がよく分かりませんが、面白いからOKで。

関連する話題: マンガ / 買い物 / ぐーぱん!

2009年6月26日(金曜日)

JVN#93827000 レッツPHP! 製 Tree BBS におけるクロスサイトスクリプティングの脆弱性

更新: 2009年6月30日18時30分頃

そういえば公開されていました。

これはひたすら良くあるXSSで、クエリ文字列にいろいろ入れると残念なことになります。届出に記載していたのはこんな3パターン。

tree.php?all=%3cscript%3ealert%28document.cookie%29%3c%2fscript%3e
tree.php?mode=root&page=%27%3e%3cscript%3ealert%28document.cookie%29%3c%2fscript%3e
tree.php?n=%27%3e%3cscript%3ealert%28document.cookie%29%3c%2fscript%3e

Googleで検索してみるとかなりの数ヒットするので、けっこう使われている気がします。気がついた人は管理者に「更新してね」と言ってあげましょう。

※「JVN#32788272 レッツPHP! 製 PHP-I-BOARD におけるディレクトリトラバーサルの脆弱性 (jvn.jp)」というものも公開されていますが、これは別の方が届け出られたもので、別件です。たまたま同時期に届け出られて一緒に対応されたのだと思います。

関連する話題: セキュリティ / IPA / JVN / 情報セキュリティ早期警戒パートナーシップ

2009年度 IPA情報セキュリティセミナー 技術コース専門編

公開: 2009年6月30日0時20分頃

午後は専門編。ケーススタディ中心に脱線交えつつだったりもしたので、本当に雑多なメモになっております。

※というかですね、ロビーの状態が酷すぎでトイレに行くにも息を止めなければならず、後半は体力が保たなかったですよ。パーティションで区切られただけのスペースを「喫煙所」と称されても……。皆さんあんな状態に耐えられるのが凄いですね。

ケーススタディ: DNSを攻撃された事例
  • たいていのインシデントは苦情で始まる (昔は。最近はインシデントが分かりにくい)
  • ウェブに(たまに)つながりにくい、メール遅延、メールが来ない→ネットワーク障害を疑う
  • メール受信は遅延するものの、送信は問題ない。ウェブサイトも、内側から見る分には問題ない。サーバ負荷も問題ない→原因特定できず。ISPに問い合わせるも障害報告もなし
  • 「御社のウェブサイトを見たらウィルス対策ソフトが反応」「これまでと違うページが見えることがある」という報告→管理グループに連絡、緊急対応開始
  • SQLインジェクションを疑うも、何もなし。XSS? 監視サービスにも、ログにも何もないが……。ベースライニング→ベースラインを作って、逸脱したアクセスを洗い出す
  • 念のため社外から(携帯電話回線経由で)アクセスしてみると、微妙に違うサイト、ウィルス対策ソフトが反応。リロードすると何度かに一度出てくる (再現率が100%ではない)
  • →パケットキャプチャして調査。家からのアクセスでパケットをキャプチャして調査→知らないIPアドレスに誘導されている、nslookupで調査
  • 何年か前に使っていて、今は使っていないはずのネームサーバが存在。昔委託していた業者のDNSサーバが登録されっぱなし。期限切れ後に第三者がそのドメインを取得→数分の一の確率で偽サーバに誘導されてしまう
  • 悪意あるメールサーバは、メールを受信してから本物サーバにフォワードしていた。だから、遅くなるがメールは届いていた (発覚が遅れる原因)
  • 被害……公式サイトにアクセスした人にウィルス感染、外部からのメールも読まれてしまっていた(情報漏洩)
  • やめる、いなくなるときの処理は漏れがち(たとえば退職処理)。いつその情報を消せば良いのか?

※不正なDNSサーバによる誘導の説明。メールの場合、MXを解決→そのAを解決、となるので実際には説明より1ステップ多くなる。Webの例で良いのでは。また、メール送信のパケットキャプチャはクライアントでやっても駄目なはず (ほとんどの場合、クライアントはMXを引いたりせず、決められたサーバに投げるだけなので)。

  • ウィルス新種70万/月
  • iframeの脆弱性で、見ただけでファイル実行→Windows Updateが行われていれば脅威はない。最近はQT,PDF,Flashなどのプラグイン、マルチメディア系の脆弱性が利用されることが多い(最近のブラウザはきちんと対策されているし、自動アップデートもある)
  • 最初はダウンローダーだけが入る。検出困難 (ネットワークインストールを行うsetup.exeと区別がつかない)
  • 昔のボットはIRCを使っていたが、最近のボットはHTTP/HTTPSでふつうにGETアクセスしたりするので正規の通信と区別が難しい
  • LAME delegationの原因……設定変更忘れ、スペルミス (example→exmaple)
  • これらはNG: DNSとして応答しない、権威あるはずの人が Non-Autohoritative Answer、サーバごとに異なる応答
  • ドメイン情報ハイジャックで不正なDNSサーバを立てられると……メールアドレスがあれば、正式なSSL証明書を取得できる可能性がある
  • トラフィックの100%を誘導できるわけではない (複数あるネームサーバの一つだけが乗っ取られているので)
  • チェック: 現状の動作ではなく仕様を見る
  • TTLが短すぎると危ない

    ※とはいえカミンスキー氏によって「長くても危ない」となったような気もするところ

Webアプリケーションの脆弱性
SQLインジェクション
  • 「直接攻撃」に分類。攻撃者が直接サーバを攻撃。
  • Webサーバのログに怪しい形跡が残る……が、ステータスコードを見ても攻撃が成功したかどうかは分からない。POSTリクエストの場合、普通はログに残らない。Webサーバのログではなく、DBのログを見ると実際に攻撃が成功したかどうか分かる
  • DB側で用意された機能でエスケープすると良い……が、データベースの開発者も攻撃の動向をすべて知っているわけではない。特に、多バイト文字を考慮していないことがある
  • 究極の対策 (?) として「サイト閉鎖」という選択もある。実際、届け出られたサイトが閉鎖されることも。閉鎖するなら教えてほしい
XSS
  • 「間接攻撃」。悪い人が直接対象のサーバにアクセスするわけではない

※デモに関しては園田さんの所のコメント (d.hatena.ne.jp)参照。あと、多くのフィルタは"javascript"ではなく"script"を処理するので、javaとscriptの間に文字を混入しても突破できない可能性が高い気がしたりとか。

インシデントレスポンス
  • RFC2350
  • 誰かが試しにIDSを動かしたら検出。誰が試しに稼働したんだ?(w
  • 検出されたのはold fashionな攻撃、Nimda系
  • 一昔前→ワームがどーん、大量トラフィックで派手に始まる
  • 今のインシデント→静かに始まる。ビジネスが目的なので、長く息の続く踏み台にして稼ぎたい
  • アンチウイルスのプロセスが停止されている。未知のウィルスに感染。
  • 他にも怪しい挙動をしているマシンがあるかも知れない。全体への影響を知るため、止めたりせずに調査
  • 調査ツールをインストールしたりすると証拠隠滅活動を行う可能性もあるため、外から観察
  • 何かをダウンロードしている。Wiresharkの便利機能でストリームをフォロー、分割データを一つに合体。"MZKERNEL32.DLL"などの文字列を発見。実行ファイルのダウンロードを行っている事が判明
  • ダウンロードがウィルスの活動とは限らないが、ユーザーの証言と照らし合わせて、全く心当たりのないダウンロードと判断できればインシデントと判断できる。ダウンロードされたファイルに対してマルウェア解析を行うかどうかは判断による
  • とりあえず virustotal に投げてみる? pedump で PE ヘッダを確認? CCCに投げてみる?
  • ダークマターIPアドレス(未使用IPアドレス、本来、そこに対する通信は発生しないはず)にハニーポットを設置という方法も

関連する話題: セキュリティ / IPA

2009年度 IPA情報セキュリティセミナー 技術コース標準編

更新: 2009年6月30日0時20分頃

2009年度 IPA情報セキュリティセミナー (www.ipa.go.jp)開催。本当はマネジメントコースに参加したかったのですが、プレスリリースが出て間もないはずなのに受付終了していて断念、技術コースに出てみました。

※実はこれ、参加無料の上に、タダで情報セキュリティ白書2009 (www.amazon.co.jp)がもらえるという、目茶苦茶お得なセミナーなのですよね。すぐ埋まるのも頷けます。まあ、私は白書は既に持っていますけれど……。

以下、私が気になったポイントをメモ。あくまで私のメモなので、本筋の部分はあまりメモしていません。

情報セキュリティ10大脅威
DNSキャッシュポイズニング
  • カミンスキーのアレ。
  • 米国のISPのDNSが実際に攻撃を受けたとか。
  • DNS Ampの話 (いや、これ別の話になってますけど……)
標的型攻撃
  • 昔はexeやscrなどの実行ファイルが添付されてくるのが常套手段で、頑張って拡張子を偽装したりしていました。最近の攻撃ではdocやpdfなどの文書ファイルが添付されてきて、拡張子も本当にpdfやdoc。そしてリーダー側の脆弱性を突いてくるという。
  • IPAからのメールを装った攻撃もあり、文面はIPAのサイトの本物をコピペしたもの。これを機に、「IPAからは添付ファイル付きメールを送らない」というポリシーを定めた (ので、IPAから来たメールに添付ファイルが突いていたら偽物と判断して良い)。
  • 防ぐのはなかなか難しい。標的型攻撃に関する情報収集と周知徹底が重要。
情報漏洩
  • 今年に入っても相変わらずWinny、Shareからの漏洩は多い。恥ずかしながら、IPAからもWinny経由で情報漏洩した人が出てしまった。
  • 漏洩させないためのルールづくりが重要。IPAはそういうルールを持っていて、それ故、例の漏洩事件でもIPAの重要情報は漏れていなかった (漏洩したのは前職での情報)。
  • 端末操作の履歴、USBメモリの無断使用禁止、等を定める。ルールが守られないこともあり得るが、それで事故が起きた場合はその個人の責任となる。
  • 大企業では、会社支給の携帯電話を紛失したら懲戒処分となる場合がある。懲戒処分なので社報にも載る。罰を与えるというよりも、管理の重要性を周知するという意味合いが強い。
  • 情報持ち出し時には暗号化を行う。たとえば、必要に応じて暗号化機能付きUSBメモリを貸し出すなど。
ウィルス・ボットの感染経路
  • USBウィルス、と言われるがSDカードでも観戦。店頭のDP端末も感染した。不特定多数が使うPCは危険。
  • 最近のボットは指令サーバが冗長化されている。ホットスタンバイで立ち上がってくる。
  • 最近のPCはパワフルなので、ボットが動作していても動作が遅くなるなどの症状が出にくく、気付かない。
  • exeではない感染経路。PDF, MS Officeの脆弱性を悪用。「ウィルスはexe」の常識が覆る(一昔前はアイコン偽装、拡張子偽装)。見分ける方法は、出所を見るしかない。
  • USBメモリ経由の感染。「ネットに繋いでいないから安全」が覆る。オフライン、隔離ネットワークへの感染。
  • ボット感染の罠を仕込まれたサイト増加。SQLインジェクションで正規サイトに罠が埋め込まれている。
脆弱な無線LAN
  • WEPはすぐに解読できる
  • 無線LAN APただ乗り、不正メール送信に利用。ある日突然警察が……。
  • 自分の家のAPをわざと脆弱にしてとぼけた、などという事例も。
  • WEPはだめ、WPA2+AES。
  • そもそも無線LANを使う必要があるのか?
  • パスワード/ネットワークキーに注意。IEEE802.1xでは最低20文字以上とされている。

    ※2009-06-30 追記: ここは私のメモの間違いで、「IEEE802.11 では、WPA2で“パスフレーズ”を設定する場合は最低でも20文字にする」が正解とのことです。コメント参照。

  • WPS、AOSSなどの自動設定を使用するのも有効(ただし勝手に使われる事故も……知らないうちに子どもがDSを接続)。
スパムメール
  • エラーメールに注意。偽装された送信元に大量のエラーメールを返すと、それがDoS攻撃になることも。
  • 第三者中継を許すサーバは最近ほとんど見ないが、便利なアプライアンス(UTM)を入れたら、不正中継をするようになってしまったという事例も。チェックはすべき。
ユーザIDとパスワードの使い回し
  • 攻撃者は、マイナーサイトで盗み取ったIDとPASSをYahoo!で試す。
  • 覚えられないが……「信頼できる」パスワード管理ソフトを使うのも手。
正規サイトを経由した攻撃
  • 難読化されたスクリプトの埋め込みが多発。GENO→中国サイトに飛ばされて感染。
  • 難読化の意味……解読を困難にし、遷移先の分析を困難にする。改竄されたサイトの一覧をGoogleで取得することが難しくなる。訳の分からない文字列が大量にあったら危ないと思って良い。
  • GENOウィルスの感染例路は調査中だがなかなか分からない。SQLインジェクションで広まるわけではない、FTPのアカウントが盗まれているが、それがすべてでもない。FTP用の端末が感染し、PC内のHTMLにことごとく不正コード埋め込まれたり。
  • 様々なサイトをリダイレクトして最終的にウィルスサイトにたどり着く「ナインボール」型。
誘導型攻撃
  • 誘導の手段
    • ネットサーフィン中に誘導される
    • スパムメールに記載のURL
    • 添付ファイルクリックで
    • 悪意あるバナー広告
    • 謎のSEOで検索上位に出現
  • 利用される脆弱性
    • XSS
    • 脆弱なソフトウェア
組み込み製品
  • 組み込み製品のCSRFなど。
  • 機器の設定画面をタブブラウザの複数タブで開かない。作業が終了したらブラウザを閉じる。
脆弱性関連情報の届出状況
  • 今週も「ウィルス対策ソフトがあればWindows Updateはしなくても良いのですよね?」って言われた。
  • 届出情報が多すぎで担当者が死にそう。

※SQLインジェクションのサンプルが微妙かも。本来、攻撃者は 'john' を知る必要がないはずなので。XSSの説明も分かりにくいかも。検索サイトでCookieが盗まれて何が起きるのかと。

不正アクセスの届出状況
  • インターネット定点観測「TALOT2」: 10箇所で監視。サービスは特に動いていない状態で、ただ繋いで放置しておく。
  • 一日あたり119箇所から372件のアクセス。
  • 届出件数は減っている。が、被害は減っていない様子。届出を控える傾向にある?
  • 統計では、SQLインジェクションは「侵入」に含めている。「その他」は不正プログラム埋め込み、なりすまし(他人のID・パスワードを利用)など。MMORPGの不正アクセスが増加している。

関連する話題: セキュリティ / IPA

マクドでDS

公開: 2009年6月28日22時50分頃

「マックでDS (www.mcdonalds.co.jp)というのが始まっているようで。

せっかくなので試してみようかなと思い、丸の内新東京ビルヂング店に行ってみたものの、店内に三歩踏み入れた時点で「この店は私には無理だ」と判断。

※某ウェンディーズもそうですが、皆さんあの状況で食事できるというのが凄いです。メチャクチャ我慢している……というようにも見えないので、そもそも平気なのでしょう。うらやましい。

仕方なく少し歩いて丸の内国際ビルヂング店に突入。テキトーに操作してジラーチをゲットしました。

なんかクーポンとか色々あるようですが、そっちはあまり見ていないので……。

関連する話題: ゲーム / ポケモン / たばこ / 飲食物

東京商工会議所の地図を印刷して良いのかどうか分からない

公開: 2009年6月27日1時40分頃

「2009年度 IPA情報セキュリティセミナー」というのが東京商工会議所ビルで開催されたのですが、「東京商工会議所ビルのご案内 (www.tokyo-cci.or.jp)」を見ると地図があるのです。そんなに分かりにくい場所ではないのですが、まあ、念のため地図を印刷して持って行こうか、なんて思いますよね。

ところが、こんな記述が目に入りまして。

※無断転載、無断複製を禁止します。

以上、東京商工会議所ビルのご案内 より

プリンターで印刷するのも立派な複製でしょう。問い合わせて印刷の許可をもらえば良いのでしょうが、急いで出たかったりするわけで。まあ、これは明らかに私的複製ですし、私的複製の権利は著作権法で保証されていますから、何か言われても突っぱねられるだろうと判断して印刷してしまいましたが。

しかし、地図を掲げておいて複製禁止と言われるのも……来てほしいのか、来てほしくないのか、よく分からないですね。

関連する話題: セキュリティ / IPA

2009年6月25日(木曜日)

検疫したファイルがまた検疫される

公開: 2009年6月27日1時40分頃

「ウイルス定義ファイル更新時に検疫フォルダをスキャンすると Auto-Protect で DWHxxxx.tmp が検出される (service1.symantec.com)」。

Symantecのアレには怪しいファイルを「検疫」して隔離する機能があるのですが、パターンファイル更新の際、謎のウィルスが検出されて検疫されることがあるというお話。どうもこういうことのようで……。

過去のパターンで検疫したファイルは、新しいパターンでは異なるウィルスとして検出される可能性もあります。ですから再チェックしようとするのでしょう。それ自体は納得できますが、チェックのためには検疫から取り出す必要があるわけです。取り出すと、その瞬間に「ウィルスに感染したファイルがハードディスクに保存された」ということになりますから、Auto Protectが有効だと、その瞬間にまた検疫されることになります。

……まあ、ある意味、正しい挙動のようにも思いますが……。普通に見ると、また新たなウィルスが検出されたようにしか見えないわけです。この時検疫されるのはあくまでテンポラリファイルなので、最初に検疫されたときとは異なるファイル名になっていたりして、混乱に拍車をかけます。検疫済みファイルの一覧にはファイル名だけでなく、ファイル内容のハッシュ値なんかを表示してくれると分かりやすいのかもしれません。

関連する話題: セキュリティ / シマンテック

層圏トポス

公開: 2009年6月26日1時20分頃

「層圏トポス」って、なんかちょっとかっこいい小説のタイトルみたいですね。

しかし本当は「層・圏・トポス (www.amazon.co.jp)」という本で、表紙のタイトルのタイポグラフィが微妙なために、ぱっと見るとナカグロの存在に気付かないという。

関連する話題: 本

2009年6月24日(水曜日)

大東京トイボックス4

公開: 2009年6月26日1時15分頃

クソゲーといえば……?

これまた出ていると言われて購入。

大型タイトルの発売日って他社におおきな影響を及ぼすのですよね。ドラクエの延期も迷惑なんだろうなぁ。

関連する話題: マンガ / 買い物 / 東京トイボックス

社長自ら「黄金の絆はクソゲー」

公開: 2009年6月25日23時55分頃

「我々はプロ意識がなかった――ジャレコ加藤社長が語る同社の過去と未来 (ascii.jp)」という話が。

「黄金の絆 (www.amazon.co.jp)」の話が興味深いです。

――　最新タイトル「黄金の絆」についても「クソゲー」と思われていますか。

加藤　まあ、クソですよね。あれをクソと言わずして、何をクソと言うのかってことです。上品に「よくがんばってくれました」なんていうのはウソでしかないですよ。

といっても、それは開発会社のせいにしているわけではなく、結局は「自分たちもクソ」だし、それを世に出してしまった自分こそクソだったんだと思っています。

以上、我々はプロ意識がなかった――ジャレコ加藤社長が語る同社の過去と未来 より

社長自ら「クソゲー」であることを肯定!! セールス低下の要因になりかねないのに、潔く肯定する態度には好感が持てますね。

各所の評判や動画などを見る限りでは、音楽、グラフィック、シナリオといった要素自体はそれほど悪くもないようです。ただ、ローディングが異様に長いとか、敵が突然わき出してくるとか、敵が棒立ちとか、ボスの動きが全部一緒とか、当たり判定が見た目どおりでないとか……要するに、プログラミングの部分が力不足だったという話のようなのですね。

プログラムって、ぱっと見では動いているように見えても、実は見えにくいところで動作が変だったりすることが結構あります。これはゲームに限らない話で、Webアプリもそうですね。正常系はいちおう動くけれども異常系が駄目すぎるとか、想定外の値を入れたら死んでしまうとか、良くある話です。

こういう隠れた部分の品質は見えにくいので、開発会社の力量をはかるのも難しくなります。品質は良く分からないので、単に金額が安いところが選ばれることになったりして……。最近はどうも低価格・低品質の開発会社がかなり増えているような気がするので、そこは注意したいと思いつつも、やっぱり金額重視になるのが現実だったりとか。

ある意味、発注側の力量が試されるわけで、やっぱり発注側がしっかりしていないと駄目なのかもしれないですね。

――　なぜそこまでの「クソゲー」になってしまったんですか。

加藤　要はプロ意識がまったくなかったということですよね。満足いかないクオリティのまま世に出そうとしてしまう生ぬるさが原因です。当初の計画から半年遅れで進行して、それであのレベルですよ。こちらは数億円の投資をしているわけですから、それを何に使ったんだコノヤロウということになる。

以上、我々はプロ意識がなかった――ジャレコ加藤社長が語る同社の過去と未来 より

たいていの場合、プロジェクトが大幅に遅れると、その分品質が高くなる……ということはなくて、むしろ逆です。大幅に遅れるということは、プロジェクトの根本的な部分で何か問題が起きている事が多いので、成果物の品質も低い場合が多いです。

……とか、とか。

関連する話題: ゲーム

みなみけ7

公開: 2024年12月21日18時5分頃

出ていると言われて購入。

なんか見たことあるエピソードばっかりだったような気がするのは気のせいではないのだろうなぁ。DVD付き限定版 (www.amazon.co.jp)というのも存在するらしいですが未確認。

※ところで、76ページのチアキのエピソードは実際にあった裁判例で、「たぬき・むじな事件」として知られています。「その地方でむじなと呼ばれていた」からではなくて、「全国的にたぬきとむじなは異なると認識されていた」ことが認定されて無罪となった事例です。類似のものに「むささび・もま事件」というものもあるのですが、こちらは「その地方で呼び名が違うというだけでは駄目」ということで有罪なのですね。

関連する話題: マンガ / 買い物 / みなみけ / 法律

2009年6月23日(火曜日)

XMLを受け取る際は外部実体に注意

公開: 2009年6月24日15時20分頃

「XMLをparseするアプリのセキュリティ (d.hatena.ne.jp)」。

以前に書いたXML entity explosion attackの話の最後の方でもちらりと触れましたが、外部からXMLを受け取るとき、パーサが外部実体を解釈するとまずいことになる場合があります。

ということですね。特に後者の場合、ディレクトリ・トラバーサルよろしく、サーバ内の任意のファイルの内容が見えてしまう可能性があるので注意が必要です。

SOAPなどで外部からXMLを受け取るAPIは良くあると思いますが、外部からやってきたXMLをパースする際は、DTDや外部実体は全く読みに行かないように設定しておきたいところですね。

※もっとも、XHTMLを読む必要がある場合は©などの実体参照が解釈できなくなってしまうという問題もありますが……。

関連する話題: セキュリティ / XML

Xbox360版「怒首領蜂 大往生」がPS2版のソースコードパクリだった

公開: 2024年12月21日0時10分頃

Xbox360の「怒首領蜂 大往生 ブラックレーベルEXTRA」ですが、こんなお話が。

Xbox360に移植するに当たってPS2版のソースをもらって……というのなら別に良いのではないかとも思えますが、無断でとなれば話は別。しかし、PS2版のソースコードをパクってXbox360版にそのまま適用できるものなのですかね? その辺りの開発の事情はよく分かりませんが。

発覚の経緯については、アリカの副社長である三原一郎氏が書かれているようで。

この話はなかなか興味深いのですが、ともあれ発見の経緯はこんな感じのようですね。

大往生３６０のＸモードを遊んでみた時にも思ったんですが、びっくりするぐらい『ゲーム中』に『追加』されたグラフィックがない。

(～中略～)

・・・まさかと思うけど、・・・エミュぽいもんにパッチ当ててないか？

以上、Mihara's sub Layer | 今週のファミ通 より

細かくレポートするみたいな事を書きましたが、色々と検討した結果、公開するの止めます。

（追記）

なんでこんなに移植度が低いのか不思議でしたが私の中で推論が出たので。

以上、Mihara's sub Layer | 移植の精度云々に関して より

クオリティの低さが気になって、というのが発端と言って良いのですかね。発売当初から移植のクオリティが低いという話はあって、一部で (クソゲーオブザイヤーなどで (koty.sakura.ne.jp)) 話題になってはいたのですけれどね。

関連する話題: ゲーム / プログラミング

2009年6月22日(月曜日)

お手柔らかに願いたい ITセキュリティ予防接種調査報告書

公開: 2024年12月21日16時25分頃

JPCERT/CCのサイトで「IT セキュリティ予防接種調査報告書 (www.jpcert.or.jp)」というものが公開されていますね。なかなか興味深いです。

抜き打ちで疑似攻撃メールが送られるわけですが、受け取る側にもなかなか手強い方がいらっしゃるようで。

メールを見てすぐに訓練のものと気付いたので、Linux上でWordファイルをHTMLに変換し、マクロウィルス等の感染の危険性がないテキストブラウザw3mで閲覧した

ほー、これは参考になります。Word文書を安全に見る方法があると良いなぁと、いつも思っていたのですよね。明らかに不審なものは無視で良いのですが、中身を確認したいこともあるわけです。マクロ無効なら安全……なんて言い切れないわけでして、とりあえずVirusTotal (www.virustotal.com)に突っ込んで何も出ないことは確認しますが、それでもゼロデイとかありますからね。

被験者企業Iでは、非常に多くの偵察アクセスを観測した。第1回配信時には総アクセス数852回のうちの566回(66.4%)が、第2回配信では総アクセス数128回のうちの69回(53.9%)が、偵察アクセスであった。

被験者企業インタビューの際の話では、中にはWebアプリケーション用の脆弱性診断ツールを使って脆弱性診断を行った被験者もいたようである。また、他のサイトを経由してアクセスするものなど、巧妙なものも見られた。

お手柔らかに願いたいものである。

思わず笑ってしまいました。「お手柔らかに願いたいものである」という一文は報告書に書く必要のないものだと思いますが、味があって良いですね。

ちなみにこの記述は「被験者企業I」についてのものですが、被験者企業Iというのはラックホールディングス株式会社とその子会社なのです。つまり、ラックにビーコン付きメールを送信すると、通常5万円 (www.amazon.co.jp)のところを無料で診断してもらえるわけですね。:-)

※ところで、グラフの画像にマウスポインタを重ねると「報告書差し替えグラフ(川崎さんの手が入った範囲)」などと出るのですが、これはこういうものという事で良いのですかね。

関連する話題: セキュリティ / JPCERT/CC

2009年6月21日(日曜日)

ソフトバンク携帯、謎の頭金

公開: 2009年6月22日15時45分頃

「「頭金」「契約金」と称する上乗せ代金をソフトバンクショップなどに取られてしまった場合、どうすればいいのか？ (gigazine.net)」というお話が。

実はちょうど昨日、ソフトバンクショップで機種変更したのですが、謎の頭金は取られませんでしたね。というか、そもそも分割が嫌いなのでまとめて払ってしまいましたが。

しかし、やはり値段は分かりにくいと思いました。特に機種を決めたりしていなかったので、いろいろ相談させていただいたのですが、当然、価格も含めて検討することになります。お店の人が価格表を持っていたのですが、興味深いことに、わざわざ表の数値に24を掛けて価格を計算されていたのですね。つまり価格表には分割した際の値段しか記載されていないわけで、最初から24回の分割払いを前提としているのでしょう。

なので、たぶんこういう事なのだろうなぁと推測します。

……しかしまあ、分かりにくいですよね。そもそも分割前提で設計されているのがわかりにくさの原因のような気も。

関連する話題: 出来事 / 思ったこと / 携帯

2009年6月20日(土曜日)

慟哭

公開: 2009年6月21日13時50分頃

読み終わったので。

叙述トリックものなのですが、半分も読まないうちにトリックが予想できてしまい、しかもその予想どおりでした……。

もっとも、叙述トリックが途中で分かるということは、それだけ読者に手がかりが提供されているということで、つまりはフェアであるということでしょう。

関連する話題: 本 / 買い物

2009年6月19日(金曜日)

iPhoneがICMP echoで死亡する脆弱性……が分かりにくい

公開: 2024年12月21日0時10分頃

こういうお話が。

3箇所のどれを読んでも「細工されたリクエスト」「不正なリクエスト」とあるだけで、どのようなリクエストなのか分かりません。べつに具体的な攻撃方法が知りたいわけではないのですが、HTTPなのか、TCP/IPなのか、それとももっと別のレイヤーのものなのか……といったことさえ分からないのはどうかと思うわけで。

AppleのAbout the security content of iPhone OS 3.0 Software Update (support.apple.com)がリンクされているのですが、こちらは他のバグFixなども大量に列挙されていて、これはこれで分かりにくいです。まあ、探せば良いのですが……というわけで、これですね。

CVE-ID: CVE-2009-1683

Available for: iPhone OS 1.0 through 2.2.1, iPhone OS for iPod touch 1.1 through 2.2.1

Impact: A remote attacker may cause an unexpected device reset

Description: A logic issue in the handling of ICMP echo request packets may cause an assertion to be triggered. By sending a maliciously crafted ICMP echo request packet, a remote attacker may be able to cause an unexpected device reset. This update addresses the issue by removing the assertion. Credit to Masaki Yoshida for reporting this issue.

以上、About the security content of iPhone OS 3.0 Software Update より

細工されたICMP echoで死ぬそうですよ。これはなかなか厳しい感じですね。

※前にもどこかで書いた気がしますが、そもそも「情報セキュリティ早期警戒パートナーシップ」で取り扱った情報をわざわざ3箇所に分けて掲載する意味が分かりません。どれかが一番情報量が多いなら良いのですが、それぞれ欠けている情報があるので困ります。JVNに全部まとめていただけると読みやすいのですが……。

関連する話題: セキュリティ / IPA / 情報セキュリティ早期警戒パートナーシップ / Apple

2009年6月18日(木曜日)

PHPでは"0x0A"=="10"がtrue

公開: 2024年12月21日23時40分頃

「PHPの比較の素晴らしさ加減は正常 (anond.hatelabo.jp)」。

PHPでは"0x0A"=="10"がtrueになるのに、"0x0A" == "012"はfalseという話。無茶な話だなぁと思いつつも、実はマニュアルを見るとちゃんと書かれていたりするのですよね。

整数値を文字列と比較する際、文字列が 数値に変換されます。 数値形式の文字列を比較する場合、それは整数として比較されます。

以上、PHP: 比較演算子 - Manual より

というわけで、文字列比較時は「数値形式」の文字列どうしであれば数値に変換されて比較されることになっています。さらに、その変換についてはこんなふうにも書かれています。

この変換に関する詳細は、Unix のマニュアルページで strtod(3) を参照ください。

以上、PHP: 文字列 - Manual 文字列の数値への変換 より

つまり、Cの標準ライブラリ関数であるstrtodを使って変換しているわけですね。man 3 strtodの内容を見るとこんな事になっています。

入力する文字列 (の先頭部分) は以下の形式が期待されている。先頭にホワイトスペース、次にプラス (aq+aq) またはマイナス (aq-aq) の記号、その後に (i) 10 進数、(ii) 16 進数、(iii) 無限、 (iv) NAN (計算できない数、not-a-number) のいずれかがある (ホワイトスペース、符号は省略可能。ホワイトスペースは isspace(3) で識別される)。

以上、Manpage of STRTOD より

なんで16進数に対応していて8進数には対応していないのかというと、単に「strtodがそういう挙動だから」。

というわけで理屈は分かりますが、嫌なバグの原因になりそうな挙動ではあります。事と次第ではセキュリティ系の問題につながりそうな気もしますね。それが嫌なら==ではなく===を使えということなのでしょうけれど……。

関連する話題: PHP / プログラミング / セキュリティ

あずまんが大王 1年生 ゲット

公開: 2024年12月21日17時45分頃

届きましたよ!

初動が遅かったためか、本屋をいくつか巡ったものの完売状態で購入できず、Amazonで注文しておいたのでした。

中身は基本的に同じ……と思いきや、だいぶ変わっていますね。最初の方は全コマ書き直されています。ゆかり先生の台詞を中心にいろいろ変更されていたり、細かい部分にいろいろ手が入っていますね。9月以降はほぼそのまま……と思いきや、トーン貼りはやり直されているようです (いや、トーンではなくデジタル彩色なのかもしれませんが)。ちなみに写植もやり直されていて、たとえばちよちゃんの台詞はポップ体ではなくなっています。

「補習」が追加されているのですが、それ以外にも、入れ替えの形で新エピソードが追加されている部分がありますね。

巻末に追加となっている「補習」ですが、これがまた面白い。大阪さん成分が盛りだくさんなので、大阪さん好きな人にはかなりオススメです。

※あと細かいですが、索引が無くなっていますね。まあ、いらないですよね……。

関連する話題: マンガ / 買い物 / あずまんが大王 / あずまきよひこ

2009年6月17日(水曜日)

URL短縮サービスがやられた

公開: 2024年12月21日23時45分頃

URL短縮サービスのCligs (cli.gs)がやられてしまったようで。

この手のサービスはリンク先が分からなくてコワイとか悪用できるとかいう話は前からありましたが、サービス自体が陥落するというシナリオがあったとは。こうなってくると洒落にならないですね。

しかし、218万のURLが改竄というのも凄いですね。SQLインジェクションでDBの全レコードに一気に値を注入できたとか、そういう感じなのでしょうか。

関連する話題: Web / セキュリティ / Twitter

七回死んだ男

公開: 2024年12月21日20時42分頃

これは面白かったです。

正直あんまり期待していなかったのですが、良い意味で期待を裏切る面白さでした。読点をいっさい使わないスタイルは最初違和感がありましたが、それほど読みにくくもないですね。そして内容が秀逸。「反復落とし穴」という「体質」で同じ日が何度も繰り返されるのですが、この「リセットしてやり直す」という流れが文字通りゲーム感覚で、面白いです。

※ちょうどムジュラの仮面 (www.amazon.co.jp)(のバーチャルコンソール版)をプレイしていたりもして。

最後に予想外のどんでん返しがあったのも良かったですね。まさか主人公が…………とは思いませんでした。「反復落とし穴」が体質であって能力でないのがポイントで、これが最後に効いてきます。叙述トリックに近く、こういうのは好きですね。

関連する話題: 本 / 買い物 / バーチャルコンソール

2009年6月16日(火曜日)

DNS デボルブ話

公開: 2009年6月17日0時15分頃

セキュリティホールmemo経由 (www.st.ryukoku.ac.jp)で……マイクロソフト セキュリティ アドバイザリ (971888) DNS デボルブ用の更新プログラム (www.microsoft.com)。

不勉強なもので、デボルブという言葉を知りませんでしたが。

「contoso.co.us」のように、ドメイン名に 3 つまたはそれ以上のラベルがある場合、または、DNS サフィックスの一覧を構成していない場合、または、次の問題を緩和する要素に該当するものがない場合、誤りにより、クライアント コンピューターが組織の境界外にあるコンピューターを組織の境界内にあるかのように処理してしまう可能性があります。

(～中略～)

たとえば、western.corp.contoso.co.us ドメインの「Single-label」を見つけている Windows クライアントは、解決するコンピューターを見つけるまで、Single-label.western.corp.contoso.co.us、Single-label.corp.contoso.co.us、Single-label.contoso.co.us、Single-label.co.us と次々にクエリを実行します。

たとえば弊社 (www.b-architects.com)のドメイン名はb-architects.comなので、社内で「example」というホストにアクセスしようとした場合、example.b-architects.comを見に行きます。このときはexample.comを見に行ってしまうようなことはないはずです。

ところが、これがb-archietcts.co.jpである場合、example.b-archietcts.co.jpが見つからなかったらexample.co.jpにアクセスしてしまい、しかもそれがイントラネットゾーンとして扱われる……という話のようですね。要はCookie Monsterの話と同じだと思いますが。

実はずいぶん前に「Webプロキシ自動発見（WPAD）の脆弱性」という話があって、そのときはJPRS側で wpad.co.jp などを取れないようにして対応したわけですが、考えてみれば "wpad" という名前に限った話ではないわけで。イントラ内の FQDN でないホスト名を解決しようとする際には、同じ問題が起きていたわけですね。

関連する話題: DNS / セキュリティ

visited疑似クラスのビーコン話ふたたび

公開: 2024年12月21日23時55分頃

「JavaScriptを使わずにWebブラウザの閲覧履歴を盗む (slashdot.jp)」というお話が。原理は、「visited疑似クラスのビーコンを拾うサービスが登場」で書いたまんまですね。

脆弱性なのか仕様なのかという話もありますが、いちおう脆弱性関連情報としての取り扱いの対象にはなっているようです。

関連する話題: Web / セキュリティ / IPA

2009年6月15日(月曜日)

あずまんが大王 1年生

公開: 2024年12月21日18時35分頃

ノーチェックでした……。

新装版ですよ。あずまんが大王は全巻持っているのですが、表紙が大阪さんという時点で欲しくなるという。うむむむむ……。

※普通に考えたら1巻はちよちゃんになりそうなのに、大阪さんで来るというセンスが素晴らしい。しかし「地域最大」には置いてないぽい……。

関連する話題: マンガ / あずまんが大王 / あずまきよひこ

2009年6月13日(土曜日)

葉桜の季節に君を想うということ

公開: 2009年6月14日22時10分頃

読み終わったので。

帯に「最後の一文に至るまで驚愕」と書いてあったものの、最初の二文字でドン引き。しかし、「これはきっと叙述トリックの演出に必要なものに違いない」と考えて読み進みました。実際その通りで、この最初の展開が叙述トリックに大きく関わってくることになるわけですが。

叙述トリックのクオリティは高く、見事に騙されました。事件本編の謎は比較的ゆるいのですが、叙述トリック好きな方にはオススメかと。

関連する話題: 本 / 買い物 / 歌野晶午

2009年6月12日(金曜日)

ゴルフダイジェストの取り組み

公開: 2009年6月14日22時10分頃

不正アクセスによるサービス停止――事例から学ぶセキュリティ対策 (www.itmedia.co.jp)。2008年10月にやられてしまったゴルフダイジェスト・オンラインの話。

こうした点からも、同氏は情報セキュリティに対する取り組みを経営レベルで長期的に行うべきとアドバイスする。

「長期的に行う」って、「IPA経由で報告された脆弱性は半年以上寝かせてゆっくりと対応していく」という意味ではありませんよね……?

※しかし、今見ると修正はされている気がするので、単に修正完了の報告が届いていないだけなのかも。

関連する話題: セキュリティ / IPA

JavaScriptのコンストラクタは値を返せる

公開: 2009年6月14日12時50分頃

会社で「JavaScriptのオブジェクトについて考察してみた (d.hatena.ne.jp)」という記事の話題が。内容の妥当性はさておき、興味深いと思ったのがこれ。

var o = function() { return { prop : "私はプロパティです。" } };

var obj = new o();

console.log(obj.prop);

普通はコンストラクタは値を返したりしないわけです。しかし、この例ではコンストラクタがハッシュを返すようになっていて、そのハッシュが new の結果として生成されたことになっています。これはひどいと言うべきか、凄いと言うべきか……。

オブジェクト生成時の手順はECMA-262 (www.ecma-international.org)の 13.2.2 で規定されているのですが、以下のようになっています。

13.2.2 [[Construct]]

When the [[Construct]] property for a Function object F is called, the following steps are taken:

1. Create a new native ECMAScript object.

2. Set the [[Class]] property of Result(1) to "Object".

3. Get the value of the prototype property of the F.

4. If Result(3) is an object, set the [[Prototype]] property of Result(1) to Result(3).

5. If Result(3) is not an object, set the [[Prototype]] property of Result(1) to the original Object prototype object as described in 15.2.3.1.

6. Invoke the [[Call]] property of F, providing Result(1) as the this value and providing the argument list passed into [[Construct]] as the argument values.

7. If Type(Result(6)) is Object then return Result(6).

8. Return Result(1).

ふつうは 1.でオブジェクトが作られ、8.でそのオブジェクトが返るのですが、7.に注目。6.でコンストラクタを実行した結果としてオブジェクト型の値が返ってきた場合、1.で作られたオブジェクトではなく、コンストラクタが返してきたオブジェクトの方が結果になります。

※型がObjectである必要があるので、コンストラクタが return 1; などとしていても無視されます。

というわけで、これは仕様なのですね……。意義はよく分かりませんが、仕様なので複数のブラウザできっちり動作します。これは面白いですね。

関連する話題: プログラミング / JavaScript

2009年6月11日(木曜日)

魔女になる。

公開: 2009年6月14日12時50分頃

何となくメモ。

魔女好きな方 (誰?) へ。

関連する話題: ゲーム / ニンテンドーDS

2009年6月10日(水曜日)

スケッチブック6

公開: 2024年12月21日15時16分頃

6巻。

表紙の涼風コンビは何を装備しているのかと。

へびつかいの話が妙にツボでした。

関連する話題: マンガ / 買い物 / スケッチブック

2009年6月8日(月曜日)

「情報システム等の脆弱性情報の取扱いに関する研究会」2008年度報告書

公開: 2009年6月10日1時11分頃

「ウェブサイト構築事業者のための脆弱性対応ガイド」などを公開 (www.ipa.go.jp)……ということで。

「情報システム等の脆弱性情報の取扱いに関する研究会」2008年度報告書が公開されたというプレスリリースなのですが、タイトルを見ると、本編よりも「情報システムを安全にお使いいただくために」「ウェブサイト構築事業者のための脆弱性対応ガイド」をプッシュしたい感じなのですかね。まあ、本編は関係者以外にはどうでも良い感じの内容ですしね。

実は私もヒアリング調査に協力させていただいたりしておりまして、関係者のほうに分類されると思います。パートナーシップに関しては、「長期化案件への対応方針の検討」という部分が興味深いですね。以下、報告書本編の内容について、いくつかコメントしておきます。

24ページ: 処理の遅延について

■脆弱性届出の急増に伴う処理の遅延について

発見者は、脆弱性届出の受理通知に遅延が生じていることを認識しているが、それが大きな問題であるとの意見はなかった。

報告書には書かれていませんが、届出された脆弱性の種類や深刻度によって取扱の優先度を変えていると聞いています。緊急性のある案件については優先的に処理されているということで、たとえば、XSSよりもSQLインジェクションのほうが優先される傾向にあります。

つまり、「緊急性のある案件については優先的に処理されている」という前提で、「緊急性のない案件は大幅に遅延しているが、大きな問題ではない」と考えているわけです。遅れていても全く問題ない、と考えているわけではありませんので、そこはひとつ。

※緊急性が無いものは遅れても良いとは言え、4月14日に届け出た内容の不備を今になって質問されたりすると、だいぶ昔の届出の控えを発掘する羽目になって大変だったり……。まあ、記入の不備は私が悪いので、そこは申し訳ないのですが。

25ページ: 発見者から運営者に直接連絡

届出が多すぎて処理できない状況なので、発見者から当該ウェブサイト運営者に直接連絡してもらうよう推奨すべきとの提案も出たが、その一方、IPAが発見者に代わって交渉することで相手からも信頼が得られるという指摘もあり、さらなる検討が必要と考えられる。

これは私ではなくて、他の届出者の方からこのようなご意見があったとお聞きしております。が……そもそも、現状のパートナーシップガイドラインでは直接連絡は禁じられていません。届出者がしびれを切らして「直接連絡した方が早いじゃん!」と感じたなら、直接連絡して良いことになっています。

実際、私も発見した脆弱性すべてを届け出ているわけではなく、直接連絡した方が早いと感じたものは、直接連絡しています。直接連絡が色々な意味で面倒だから届け出ているわけで、そこを「直接連絡してもらうよう推奨」されてもちょっと、という感じはしますね。

26ページ: 製品の脆弱性に取扱開始の通知がない

製品案件については、取扱い開始の通知がなく、状況がわからない。

これは補足が必要だと思いますが、ウェブアプリケーションの脆弱性を届け出た場合、「受信」「受理」の連絡が来た後、ウェブの運営者に対して情報を通知した時点で「取扱開始」という連絡があります。そして修正された時点で「修正完了」が連絡されます。しかし、ソフトウェア製品の場合「受信」「受理」の連絡の後、いきなり「公開」の連絡となり、「取扱開始」に相当する連絡がありません。ベンダーに連絡が行っているのかいないのか、全く分からないのです。

まあ、質問すれば現在の状況は教えてもらえるのだろうと思いますが、「取扱開始」に相当する連絡があっても良いのではないかと思います。

36ページ: 古い製品を利用しているウェブサイト

「古い製品を利用しているウェブサイト」の対応が検討されています。

脆弱性の原因が、ウェブサイトの使用しているソフトウェア製品の脆弱性に起因していて、そして、その製品の修正版が既に公開されているが、アップデートしていないような案件の届出が増加している。

たとえば、とある脆弱性診断専門の会社が古いMTを使い続けていてXSS脆弱性を抱えていた、などというケースですね。届け出たところ、これは公表されている脆弱性であって、ウェブサイトの脆弱性には該当しない (けれども運営者には連絡する) という扱いになりました。このようなケースについても取り扱ってほしいという要望を伝えていましたが、それが今回検討された形になります。

そこで、脆弱性の原因が、ソフトウェア製品のアップデートを怠っていることに起因していることが明らかに判るような、極めて単純かつ不適切な運用は、取扱いを終了させる[取扱ルールを改訂]。

・脆弱性の原因が極めて単純なので、ウェブサイト運営者は自力で気付くべき。

・IPAで取扱いを終了する前に、脆弱性が攻撃された場合の脅威など、製品の脆弱性対策を促す旨の注意喚起をしたいと考えている。

・この結果、届出者は関連情報の取扱いに関する「お願い」から解放される。

結論としては、「運営者が自力で気付けよ」という話であって、積極的に扱っていくという方向ではないようですね。届出件数がやたら増加していることをふまえての判断でもあるでしょうし、これはこれで妥当であるように思います。

37ページ: 何度も修正を促したが対策がなされないウェブサイト

出ましたね。これは私も問題だと思っていたところです。25回促したケースが確認されていますが、お疲れ様でしたとしか言いようがありません。現在も、全く修正する気がないとしか思えない人がいたりして……。

※放置するだけならまだ分かるのですけれど、平然と脆弱サイトを量産し続けるのは勘弁してほしいです。

届出者としては、放置案件は取扱終了にしてほしいところです。ガイドラインでは取扱中の脆弱性関連情報は公表できませんが、取扱終了になれば、脆弱性を公表して危険性を周知することができるようになります。場合によっては回避策を提示できることもあるでしょう。

今回の報告では、一定期間後に取扱終了という方向で検討されています。

2)一定期間は１～2年程度が適当と考えている。

・ 対策できない理由として、「予算が無く、来年度の予算で対応する」旨の回答も多い。

・ 2008年第4四半期の取扱中1,907件のうち、300日(約1年間)以上未対策は81件（約4%）、700日(約2年間)以上未対策は20件（約1%）。

1～2年だそうで。なんか昔のガイドラインでは90日ルールが謳われていたような気がしなくもないですが、まあ実態に合っていなかったということなのでしょう。

※枝番が10個も振られている伝説の放置案件は昨年の8月からスタートしているので、ちょうどガイドライン改訂のタイミングで1年になるのかなと。

関連する話題: セキュリティ / IPA

2009年6月5日(金曜日)

カンニング少女

公開: 2009年6月6日22時0分頃

表紙の絵だけ見て買った。後悔はしていない。

ちなみに表紙絵は「世界の終わりの魔法使い (www.amazon.co.jp)」の西島大介氏。

内容ですが、なかなか面白くて良かったです。カンニング手法を考えるのは、脆弱性を見つけて攻撃手法を考えるのに通じるところがありますね。前半まで読んだところで「私ならこういう方法を考えるけどなぁ」と思っていたら、そのまんまの手法が出てきてのけぞりました。

以下、各カンニング手法の考察などをメモ。ネタバレ含みますので未読の方はご注意ください。

最初のカンニング

デジタル時計つきシャープペンシルの液晶部分に、QRコードの内容が表示されるツール。

これは大変そうですね。「デジタル時計付きペン (qprc.web.infoseek.co.jp)」を見ると写真が出ていますが、この大きさの液晶にマーキー表示では、読むのにかなり時間がかかるはずです。しかも、仕込まれた50個のQRコードのうち、どれにどのような情報が入っているのか覚えていないといけないわけで。

あと、そもそも下敷きが許可されていること自体が珍しいような気がします。許可するとしても無地のもののみとして、絵のついた下敷きはNGとされる可能性が高そうに思いますけれど……。

※巻末あたりに「QRコードは株式会社デンソーウェーブの登録商標です」と書いてあるのかと思いきや、ノークレジットでしたね。

模試のカンニング

カメラ・プロジェクター付きメガネ。QRコードリーダーの話で、「そんな小型カメラが実装できるならメガネに仕込めば……」と思っていたら実際に登場しましたね。

定期試験では使えないと書かれていますが、メガネを2つつくって相互に映像をやりとりできるようにし、片方を愛香が装着すれば良いでしょう。そうすれば、玲美は任意のタイミングで愛香の答案を見ることができるようになります。

いきなり眼鏡をかけると怪しまれるという話も出ていますが、「普段はコンタクトなんだけど、試験の時はメガネをかけるようにした」などと説明すれば良いだけでしょう。むしろ、本番だけメガネを装着するというほうが変で、リスクが大きいはずです。受験票に顔写真がつく場合、受験票の写真もメガネをかけた状態で撮らないといけませんし……。

本番のカンニング

……って、杜夫のあの技が成立するということは、受験票に顔写真はついていないようですね。カンニング以前の問題として「替え玉受験」という攻撃手法が存在しますので、多くの大学では受験票に顔写真を添付するようにしているはずです。鈴村女史、妨害電波なんかより先に、「受験票に顔写真をつける」という提案をした方が良いのでは?

あとネットワーク関係ですが、32hinode-bbc.get.comは「IPアドレス」じゃないですよ……。ちなみに当然ですがget.comは実在します。

それから145.122.213.*というIPアドレスが出てきますが、145.122.0.0 - 145.122.255.255はオランダのsurfnet (www.surfnet.nl)というところが持っているようですね。架空のIPアドレスを用意するのもけっこう難しいですよね。

関連する話題: 本 / 買い物

週刊ダイヤモンドのストリートビューネタ

公開: 2024年12月21日15時40分頃

週刊ダイヤモンド 2009年6/6号 (www.amazon.co.jp)の冒頭のマンガ「F氏的日常」がGoogleストリートビューのネタになっていて、思わず笑ってしまいました。

これはやってみたくなりますね。撮影車がいつ来るのか分からないので、実際には難しいでしょうが……。

※あと、個人的にツボだったのは太田川ダムで謎の水がしみ出しているという話。「謎の水」という表現がツボにはまりました。

関連する話題: 与太話

2009年6月4日(木曜日)

はてなブックマークでjavascript:なURIが使えなくなった日の記憶

公開: 2024年12月21日15時15分頃

「はてなブックマーク - 404 Blog Not Found:javascript - から数字と記号以外の文字を取り除く (b.hatena.ne.jp)」のブックマークコメントで、dankogaiさんがこのようなコメントを書かれています。

そういえば、はてブはjavascript:なURIをリンク化してくれないなあ...

今はできませんが、実は少し前まではできていたのですよね。

私がはてなブックマークを使い始めたころの話。about:blank という URI がブックマークできることを知った私は、沢渡真雪さん (www.misuzilla.org)とこんな会話をした記憶があります。

この日を境に、はてなブックマークでは javascript: な URI をブックマークすることができなくなったことでしょう。

※派手なゼロデイ公開ばかりが話題になりますが、世の中にはこういう地味な話がいっぱいあるのですよね。

関連する話題: セキュリティ

2009年6月3日(水曜日)

ニッポン硬貨の謎

公開: 2009年6月4日0時5分頃

読み終わったので。

エラリー・クイーンのパスティーシュ (作風や文体の模倣) 作品。クイーンファンにはたまらない……のだろうと思いますが、三部作くらいしか読んでいないからなぁ。

「それは無いだろう」とつっこみたくなる展開もありますが、翻訳物にありがちな、論理がだいぶ飛躍した感じなどをあえて再現している感じですね。

関連する話題: 本 / 買い物 / 北村薫

2009年6月2日(火曜日)

boolをStringに変換して長さを見てtrueと判断

公開: 2024年12月21日23時28分頃

これはすごい。

bool値をStringに変換してその文字の長さが4のときtrueと判断していた。

#さっき見た

以上、こんなコードは見たくない。 - hatest - はてなハイク より

こんな感じのコードなのでしょうか。

boolean foo = bar.check();
if(foo.toString().length == 4){
    // 処理
}

もちろん、本来ならこれで良いはず。

boolean foo = bar.check();
if(foo){
    // 処理
}

ものすごい発想ですが、これでも正しく動作するのが面白いですね。効率は悪いですが、それも誤差の範囲でしょう。

想像ですが、発想の経緯はこんな感じなのかしら?

  1. if(……) には必ず == や > などを含む条件式を書かなければならないと思っていて、if(foo) が発想できなかった
  2. bool値リテラルの書き方を知らず、if(foo == true) も発想できなかった
  3. 文字列リテラルは知っていたので if(foo == "true") と書いてみたが、型が違うのでうまく行かなかった
  4. 型を揃えるべく if(foo.toString() == "true") と書いてみたが、Javaだったのでうまく行かなかった

    ※Javaでは == での比較は同一インスタンスかどうかを調べるので、文字列比較は equals() メソッドを使うのが定石。

  5. そこで if(foo.toString().length == 4) と書いたら動いた

まあしかし、私は私でこんなのを書いたことがありますし……。

if(foo){
    return true;
} else {
    return false;
}

あんまり他人のことは言えませんね。

関連する話題: プログラミング

2009年6月1日(月曜日)

森の生活 193日目: 6月

公開: 2009年6月2日2時20分頃

街へいこうよ どうぶつの森 (www.amazon.co.jp)、193日目。6月になりました。いよいよ本格的に虫が出てきたり、夏の魚が出てきたりするようになります。というわけで、今日一日で捕獲したのが……。

ギンヤンマ
アレクサンドラアゲハ
ミイロタテハ
タランチュラ
カ
ウナギ
ヤママユガ
ゴライアスハナムグリ
ガー
モルフォチョウ
アロワナ
マンボウ

……と、こんな感じ。ずいぶん多い感じがしますが、まだまだいるはず。

関連する話題: ゲーム / Wii / 任天堂 / どうぶつの森 / 街へいこうよ どうぶつの森

情報セキュリティ白書2009

公開: 2024年12月21日17時0分頃

IPAの方から情報セキュリティ白書2009 (www.amazon.co.jp)を送っていただきました(ありがとうございます)。159ページの「執筆協力者」の頁に名前を出させていただいております。

去年のは実教出版から出ていましたが、今年は毎日コミュニケーションズなのですね。去年のものはWord文書をそのまま本にしたような体裁でしたが、今年はきっちり編集されている印象です。章ごとに色分けされていたり、グラフが見やすくなっていたりして、かなり読みやすくなっています。

読みやすくなり、ページ数も増えているのに、お値段据え置き。これはお得ですね (そういう問題ではありませんが)。

※どうでも良いですが、159～160ページの「執筆協力者」の並び順が微妙におかしいです。本来は社名の50音順のはずなのですが、セキュアスカイ・テクノロジーとセキュアブレインの間に弊社(ビジネス・アーキテクツ)が入っていたり、ラックの方が2箇所に分かれていたり……。元の10大脅威に出ている表を一度連結してから切り離したのですかね? まあ、気にしない方向で。

関連する話題: セキュリティ / 本 / IPA / 情報セキュリティ白書

最近の日記

関わった本など