最新

おおいわのこめんと (2005-08)


2005-08-02

[Security] 小ネタ

自前ネタが供給能力不足なのでセキュリティホールmemo経由のニュースネタ集。

偽無線LANとSSL

『公衆無線LANサービスの落とし穴――偽アクセスポイントに気を付けろ』 (ITPro)。アホかと。

SSLでアクセスしているページならサーバーの存在を認証が できるし,暗号化しているので問題がないと考えるかも知れないが,それも甘 い。偽の公開鍵証明書を埋め込んでいる可能性もある。この場合,Webブラウ ザで警告は出る。しかし,この警告に気付かず,そのまま偽の証明書を受け入 れてしまうかもしれない。また,ユーザーにHTTPでページを送ってくるかもし れない。多くのユーザーはHTTPでページが表示されても,いつも通りSSLでつ ながっていると考えてしまう危険性がある。

だからさー、なんで「鍵マークを確認しろ」とか「『あの』ダイアログは偽サイトの可能性を示すので 理由のない限りイイエと答えなさい」とか、 なんでそういう基本的なことが書けないのさ……。 「それも甘い」「かもしれない」「考えてしまう危険性がある」じゃねーよ全く。

極端な言い方をすれば、こういう魑魅魍魎なネットワークの状況こそが サイト証明書とPKIを使ったSSLの機構が有効に働く場面なのに……。

ではどうすればよいかというと、(つづきは水曜日) [by kjmさん]

ということらしいのでつづきは木曜日(ほんとかよ)。

キーロガーとソフトウェアキーボード

みずほ銀行、ソフトウェアキーボードの提供などでスパイウェア対策 (Internet Watch)。

………。こういう中途半端な対策を、中途半端さをユーザに認識させずに導入して、 ユーザに偽の安心感を与えるのはむしろ有害だと僕個人的には思います。 確かにごくごく非常に単純なタイプのキーロガーには効きますけど、 例えば HTTPS の暗号化前のデータとか、ブラウザコンポーネントへの入力とか 吸われたらどうしようもないじゃんねぇ。 「6桁中4桁」にしたってほとんど意味無いしね。まぁ「共有する秘密情報」を増やさずに 小手先でやるにはこれしか無かったんでしょうけど。

まぁこういう小手先の対策を取るときに、少なくとも何に有効で何に有効でないかを はっきりと示してくれれば、まぁ「やらないよりまし」という評価もできると思うんですが、 一般的にその点全くなってないからねぇ。

ちなみに同じソフトキーボードでもソニー銀行の 告知の方は、

キーボードの操作履歴が残らないため、 入力情報を記録してパスワードなどを盗用するタイプの スパイウェアに対して、通常のキーボードに比べ安全な入力方法です。

となっていて、まぁみずほに比べれば正確に書いていると思いますが、 発展したスパイウェアに盗まれたときの防衛線を張っているというべきか……。

「スパイウェアの存在下ではどんなことやっても所詮は小手先です。 一応考えられることはやりますけど、究極的にはどうしようもありません。 そういうのが自分で心配な向きにはATMまで足をお運びください」 とはっきり告知するのが業者の責任だと思うが、そこまではソニー銀行もやってないんだよな。

本日のツッコミ(全1件) [メッセージを送る]

ゆーな [前も話したけどオンラインバンク系使うなら、DoCoMoからかとおもいますよ。銀行<->DoCoMo間はオンラインで直..]


2005-08-03

[tDiary] tdiary-mode と preview

tDiary と tDiary-mode を使って7ヶ月が経って、不便だなぁと感じるのは preview ができないこと。場合によっては 全世界にエラー画面を晒しつつバグ取りする羽目になるので、 なんとかしたいと思っている。

手法はいくつか考えたんだけど……、安易な方法はことごとく 自分で書いた CSRF 対策コードに引っ掛かるな(笑)。 対策に引っ掛からなくてかつセキュリティ的に問題のない方法をなにか考えないとなぁ。


2005-08-04

[Security] お約束の追記

火曜日のやつの結論は、これ だったわけですが、正直こういうオチ(全然違うところからリリースがでる)は予想していなかったな。 ……書くと予告してしまった以上書きますよ、はい。

別にこの方法をとったところで危険になるわけではないのでいいんですが、 なんか所々でずれてるよなぁ。

結論としてやばい方に間違ってはいないけど、議論の過程に問題があるこういうのを 批判するのは非常に難しいわけですが。

  1. 偽DNSサーバを気にするなら、偽ルータとか偽DHCPサーバとか気にしなきゃいけない ものが山ほどある(かつ、実例も山ほどある)のであって、IPアドレスを直接指定する ことにより回避できるセキュリティ上の脅威はほとんどない。
  2. むしろ必要なのは VPN サーバの認証であって、括弧書きで省略してある 項目が非常に重要。(ちなみに、相互認証のうちこの件でなりすまし防止に 特に重要なのはサーバ認証がされていること。クライアント認証の必要性は なりすまし防止ではなく、VPN接続先のネットワークの安全性確保の為の要件。)
  3. そして、SSH (port forwarding を含む) や SSL (HTTPS) を正しく利用することに よっても同等の安全性を確保できる。どこのホストにアクセスしているかすら 隠さなければいけない (けど中継サーバのIPアドレスはばれてもいい) 状況でない限り、これらのプロトコルを素直に使えば十分。

もちろん、素の HTTP の安全性を(完璧でないにせよ)上げるためには VPN、SSH port forwarding、SSL proxy などの利用が必要だが、 先日指摘した記事にあった「SSL は安全でない」は正しくないし、サーバ認証の存在を 無視して SSL を安全でないとするならば、VPN も同様に危険であるといえる。

で、ここで僕としては、「情報漏洩が十分にやばいコンテンツに関しては、既に SSL になってるもんねぇ」、 と言いたいわけですが、実際は『ログイン画面は非暗号化ですが、送信先は暗号化されています』 の問題があるな orz 心当たりのある人は早くなんとかしてくれ……。

実際 (NAT中継入り) 偽ルータ+DHCPサーバは、日本のブロードバンド黎明期に某ADSLプロバイダで クライアントの設定ミスで大々的に導入されてたことがあったようですが、 身の回りでも数年前に(やっぱり設定事故で)くらって酷い目にあったなぁ。 あのときは、謎のIPアドレスからSSHログインがあるって大騒ぎになったんだよな。 ちなみに、その時の原因は悪名高き Windows XP の自動設定ブリッジでした。ぷんぷん。


2005-08-06

[Misc] Google で遊んでみる

久々に、 自分の名前(日本語)で検索してみた。

トップが自分の公式ホームページ(いまだに大学にある)になるのはいいのだが、 取得したっきり放置状態の出身研究室独自ドメイン taplas.org になってしまった(笑)。 取った当時は個人的にも一般的にも独自ドメインへの移行万歳だったのだが、 フィッシング的な話題がでてきて、サイトの真正性が重要になってきた今ではだいぶ考え方が変ったなぁ。

ついで、広島市民病院の膠原病科に同名のお医者さんがいるらしい。

ついで出身研究室のホームページ、この間の tDiary の JVN、出身学科の博士論文一覧、 大昔の DOSEMU 日本語化パッチ、tDiary.org のアナウンス、昔のバイト先での仕事が IPSJの賞を受けたときのバイト先のページと続く。同名の旧陸軍の指揮官もいたらしい。

でもって、1997年に 中村正三郎氏にメールを送っていたことが判明したのだが、何書いたんだっけなぁ。 セキュリティがらみだったのは確かなのだが思い出せない(汗)。まぁ該当記事見れば 想像はつくが。

さすがにこの当時のメールはもうどこかにしまい込んでしまって取り出せないな。


2005-08-08

[Misc] ふぁっしょんばとん

えー、mixi の友人から↑こんなものまで廻ってきましたが……それって食えるの?

真面目な話、全く拘ってないからねぇ……。 大抵はややカジュアル寄りな襟つきのシャツと普通の仕事向きなズボンの組み合わせ。 高いものは買ってないけど、極端に安いわけでもないらしい……。 就職してからは2着2万円ちょいくらいで買ったジャケットをその上から羽織ってます。 ま、ノーネクタイな仕事場なら普通な服装かな?

でもって仕事でもプライベートでも服装が全く変わらない……。ジーンズとかTシャツとかは外では着ないなぁ。 色合いの相性は気にする方だけど、いつも腰に SHARP Zaurus SL 入りのカメラバッグを ぶら下げてるので台無しです(笑)。

というわけで残念ながら全く面白みがないです(苦笑)。

これでも研究所の中だと中庸からややフォーマル寄りなので、なんともいい職場だ :-)。

バトンは別に廻さんでもいいらしいので *1 ここで止めときますが、 「をれこそは!」と一筆認めたい人がいたらかってに コメント欄かトラックバックに自分で書き込んで持っていってくれっす。

っ[ ばとん  |5|4|3|2|1]

*1 チェーンメールみたいで気持ち悪いなーと思っていたのは事実。 廻してくれた人もそれは知ってて気にしてくれてるみたい。


2005-08-09

[Rail] 失敗に学ぶ

セキュリティホールmemo からのネタなのになぜか鉄ネタ :-)。

失敗学がしなやかで強い組織を作る (SAFETY JAPAN 2005)。 上越新幹線の死傷者なしの脱線事故が「大成功」だという判断 は強く同意。あれはかなり奇跡的な条件が重なった事象だったし、死者が出ても不思議ではなかったけれど、 同時にちゃんと阪神大震災の教訓を生かした橋脚補強が功を奏した「成功事例」だったと思う。 「人事を尽くして天命を待つ」と良く言うけど、その通りだろう。 高架橋の柱が落ちてたら99%間違いなく死亡事故になっていたわけで、 その補強によって50%なり90%なりに死亡危険度を低減した結果が、 死者0という奇跡を呼び込んだと評価すべきだろう。

「安全神話」って、マスコミが非常に好んで使いたがる単語だけど、 言うのは簡単だよねぇ、というのも前から思っていたところ。 日本の主流のマスコミの論調って、新幹線とかには「神話級」の奇跡的な安全を要求するんだよねぇ。 「人事をちゃんと尽くしたか」を評価すべきなのに、 過程を見ずに結論を極端に見ることでしか物事を理解できないんだよね。 *1

後編も読みごたえあるので是非おすすめ。 とにかく日本人は責任追及が強すぎて思考停止して、原因とか過程に興味が無さ過ぎというのは いつ頃からの傾向なんだろう。「詰め腹を切る」って言葉があるくらいだから、 明治より昔に遡るのは間違いないか……。

僕はむしろ過程を重視して再発を防ぐ方が重要だと考える人間なので、 信楽高原鐵道正面衝突事故の教訓で常設の 「鉄道事故調査委員会」 *2 が発足したのは非常に評価できると思うのだが、 司法警察との連携と独立性の確保にはまだ課題があるように個人的には感じている。 日本では司法取引のような形をとりにくいし、 民意を今すぐに「原因究明優先」とするのも難しいだろうから、立法で 「事故調資料は裁判の検察側証拠には採用しない」 「事故調査委員会の調査は警察の捜査に優先する」くらいの 強権的な担保を持たせてもいいのではないだろうかと思っているのだが、いかがか。

後編の2頁目、「JR東日本 事故の歴史展示館」には興味あるな。 正直重大事故の映像は見たくないけど、こういう訓練を地道にきちっとやることが いざというときに動けるか否かの分水嶺なのだと思う。 実は自分は駅のホームに立つと密かに非常停止ボタンを押すイメージトレーニング *3 はしてたりするのだが (^^;、いざ実際にそういう事例に出会っても体が動かないだろうなぁ、 という気がしている。 *4

ちなみに、2月11日に書いている *5が、中越大震災の時の鉄道の状況の資料として、 ほくほく線の公開資料 も結構参考になる。これを見て、次の事態に備えて自分は何ができるだろうか、 鉄道側はどんな対処をするべきなのか、と考えてみるのもいいかも。

*1 逆に、自分が知らない分野に「人事を尽くしました」と言いきられてしまうと弱いというのは、 「最高レベルの防御(TM)」で話題となった最近の事件なんかもありますね。

*2 このサイトしょっちゅう重くなっているのは何故?

*3 一方で、自分の安全を確保しつつ対処する、というイメージも重要。 新大久保事故の犠牲者は尊い犠牲だったと思うが、あのような不幸な事故を再発しないためにも、 とっさに安全で確実な対処をとれるようにと常日頃イメージを持つことにしている。

*4 この間秋葉原のホームで、列車の閉じた扉に外から傘を挟んでしまった人がいたときは とっさに「手を離して!」とは叫べたけど、あのときの自分の行動も結構反省点はあるなぁ。

*5 D論の審査直前に僕は何をやってたんだ?

本日のツッコミ(全2件) [メッセージを送る]

(わ) [森ビルの調査委員会は確かNHKの番組になってましたよ。簡単にまとめます。 欧州産のアルミ製の回転扉を日本でOEM生..]

おおいわ [番組紹介を見てきました。4月にやっていたんですね。見事に見逃しました。再放送があったら見逃さないようにしないと。 ]


2005-08-10

[Security] Scope

一部で祭になってますねぇ。まぁ話題になっている内容(PW漏洩、個人情報漏洩後の隠蔽工作)が事実だとすると、 祭られても仕方がないのだが。 漏洩してないなら「漏洩してません」と反論すればいいことなので、それができないってことは 漏洩しているんだろうなぁ、と推論されるのは仕方がない所。 こういう予期せぬ事態に対して、組織としてマトモな危機管理体制ができてないってことですね。

僕個人は、脆弱性情報は過去に何らかの危険にユーザを晒した「可能性がある」ならば、 危険に晒されなかったことをログ等で確実に確認できない限り、すべからく公開すべきだと考えています。 IPAの脆弱性情報取扱基準 (Webアプリケーション向け)でも、

「個人情報漏洩等が発生、または発生した可能性がある場合は被害拡大防止のため、事実関係を公表」

となっていますね。まして今回の場合、POP パスワードが漏洩している可能性があるということは、 関係する可能性のあるユーザは緊急にパスワードを変える必要があり、 かつそれにより今後の被害を確実に防ぐことができるわけですから、 一刻も速く「問題があったのかなかったのか、実際漏洩があったのかなかったのか判らないのか」 公開する責務があると考えるのが当然だと思います。 万が一自分で判断できないとしても、悩む前に 「現段階では判らないけど念のためパスワード変えて下さい」とアナウンスするのが妥当かな。

しかし、仮に当初は黙殺・圧殺して握りつぶす方針でいたとしても、 一般ユーザだけでなくネット系マスコミまで動いている段になって、 いつまでもダンマりを決め込んでるのはマイナスにしかならないと思うんだけどなぁ。

追記 (8/10)

まぁ 2ch の煽りもえげつないのは事実なんだけど。今回のバグに関係なさそうな 取引先業者にかたっぱしから質問状ってのはちょっとやりすぎっぽいなぁと個人的には思ったりして。

バグ入りバージョンの公開時間は(たったの)17時間かぁ。 どうせバグ入りのダウンロード数は把握しているんだから、 それなりのリリースを出して最初に正しい対処を取っておけば、 ほとんど何の問題もなく解決して信頼もほとんど落さないで済んだはずなんだけどねぇ。

で、ここまでは前置きだったりする :-)。祭りの野次馬として開発元のサイトにいって、 FAQ見ると、謎の記述が。

> SSL には対応していますか?
対応しております. ただし,携帯電話と弊社サーバ間での通信は暗号化されませんのでご注意ください.後日,携帯電話と弊社サーバ間に関しても SSL 通信に対応いたします.

(;゜д゜)

………。最近過激な言葉づかいは謹むようにと一部に言われてますが、「あふぉですか?」と思わず口からでてしまう。 SSL の意味まったくないやんけーーー。

………とはいえ、上の文章だと一見問題なさげに見えてしまうので、判りやすい日本語に翻訳してみましょう。

> 暗号化通信には対応していますか?
対応しております.ただし,暗号化していません.*1

………今度は判りやすいかな? :-)

Web ブラウザみたいな一般向けの製品、特に暗号を使ったような製品を作るときに、 きちんと所定のセキュリティ機能を実現できないのであれば、 潔く機能を提供しない*2、 というのは、サービス提供者としての最低限の責務だと思います。 ここからSSLの通信内容が情報漏洩したら、この会社は責任取ってくれるんでしょうかね? 携帯会社とセキュアな専用線で通信してれば問題ないけど、 それだったらFAQのこの項にはっきりと「対策してるんで問題ありません」と 書けるもんねぇ。

別にSSL通信機能なんて、後日直す気があるなら、 きちんと実装完成してから公開してもいい物だと思うんですけど、 なんでこんなタコ実装で公開しちゃったんだろうねぇ。

追記 (8/10 23:00)

仕様にSSL通信対応 謳ってるしー。 そういう状態で 『プログラマーズファクトリ、リンクシェアと提携。「scope」でショッピング』(Venture Now) とか言ってるしー。 ひょっとして確信的に不完全な状態で前倒し提供してる? なんかやばげ。

[Security] 携帯フルブラウザと暗号通信

上の記事への追記 (8/11 04:00)。

jig も同じ (Q22) だそうで orz (情報元: 2ch*3)。 どうしてこの業界はこう暗号化の意義とかに無頓着ですか?

どうせ

「SSL なECサイトが使えないと困る」
→「でも SSL は簡単にはサポートできない」
→「平文でいいからとにかく通信できるようにしちゃえ」

とかいう短絡的な発想なんだろうけど、インターネット上を 平文で通信するリスクを許容できるコンテンツなら、 コンテンツ提供者側が最初から http で提供すればいいわけで、 そもそも何故 SSL を使っているのか、 という肝心な点が欠落してるんじゃどうしようもない。 暗号化できないから暗号化している振りだけして平文でいい、なんて論理が成り立つわけがない

解は恐らく3つあって、

  1. SSLはサポートしない (ある意味王道)
  2. 真面目に暗号化通信を実装する
    1. ブラウザ側にSSLを実装し、コンテンツ提供者との SSL 通信のパケットを HTTP 上でトンネルするような独自プロトコルを作る (メモリきつそ〜)
    2. 専用 proxy サーバを信用するという前提の元で、 携帯本体提供の HTTPS 通信機構の上で独自プロトコルで proxy と通信、 proxy で一旦復号してから改めて HTTPS でコンテンツ提供者へ送る。 (1.より安全性に劣るがメモリ&実装節減可能) *4
  3. docomo に金積んで公式コンテンツ化&専用線直結閉域ネットワーク化することで、 平文通信区間の安全性を確保する (富豪的解決)

のどれかでしょうかね。 2-1 は、よく似た機構を携帯向 SSH クライアント が既に実装していたりする。*5

最後の解は、無線区間を追加暗号化なしで流れるリスクが SSL と比較して どの程度のものなのかをちゃんと評価しないといけないけれど、 それが十分にセキュアなら、現状の実装のまま解決できる。

*1 もちろん proxy←→サイト間は暗号化されるんだけど、 proxy 自体がインターネット上にあるのに、それだけじゃ意味がないのは当たり前。

*2 ソフトウェアによっては、利用時に「安全性に問題があります」と 警告をしつこく出しつつ動作させる、ってのは許される可能性がありますが、 Web ブラウザで SSL が正しく動作していない、ってのはそれも許されないレベルだろうなぁ。

*3 「jig もダメ」なんであって、「jig も同じだから OK」なんてことはないからねー。>某スレ480な人

*4 最初は「SSLよりシンプルな独自暗号プロトコルでも 実装しなきゃいけないかなぁ、暗号プロトコルの素人がこれを実装すると、ろくな事にならないのは 容易に想像つくなぁ」と思っていたのだが、この手のブラウザが動く程度に 最近の携帯なら proxy との間は携帯側実装の HTTPS が 使えることが確認できたので、それでいいよね、ということに。 ひょっとすると iアプリの仕様だと全部 SSL にしなきゃいけない 可能性 (←識者に聞いてみるかな) もあるが、まぁそれでも許容範囲だよね。 負荷が問題ならそれこそSSLアクセラレータでも使えばいいし。

*5 なんかQ15に微妙な記述があるけど (^^;


2005-08-13

[Security] AWStats Remote Command Execution Vulnerability (iDefence)

だそうで。……またまたかよ!

元々 Digest 認証を書けていたのだが、気分的にまた滅入ったので、さらに (あまり意味もなく) SSL の内側につっこんでみたりして。 さて、パッチ当てるか……。

→結局 Debian sarge の awstats 6.4 の debianize パッチと、 upstream の awstats 6.5 を持ってきて、 backports の debhelper と1行パッチと組み合わせて 無理やりパッケージを作ってしまった。いいかげん sarge にしないとねぇ。 もっとも、うちの環境では (ShowInfoURL を使う plugin を使っていないので) 問題なかったみたいではある。

しかしなぁ。

     my $function="ShowInfoURL_$pluginname('$url')";
     eval("$function");

こーゆーコード、書いた時点で「やばそっ」と脊髄が反射反応すると思うんだけどなぁ。 もちろん正解 (6.5 の実装) は

      my $function="ShowInfoURL_$pluginname";
      &$function($url);

である。名前間接参照使うってのはいかにも dirty Perl 的で多少気持ち悪い *1 けど、まぁ現APIではそれは仕方ない。

[Security] HTTPの認証手法と攻撃耐性

ついでだからちょっとまとめておこうかなー、と。*2 現状では Apache に auth-int は実装されてない、ってのを前提に見てね。 ○、×は「危険なのが×、安全なのが○」に統一してある。 また、中間者攻撃において、Digest 認証のはずが実はこっそり Basic 認証に差し替った場合は検出できるとする。 あと、パスワードが単純で解読できる、ってのもなしね。

Basic 認証Digest 認証SSL + 認証
authauth-int(なんでも)
盗聴時コンテンツ漏洩×××
リクエスト漏洩×××
パスワード漏洩×
中間者攻撃コンテンツ漏洩×××
コンテンツ差し換え××△(a)
リクエスト漏洩×××
パスワード漏洩×
Method差し換え×
URL差し換え×
entity-body
差し換え
××
他ヘッダ
差し換え
×××
Replay攻撃×△(b)△(c)
おまけCSRF××××
  • (a) オプション (Apache 未実装) の response-auth で保護可能。但し、サーバ側の 選択するオプションなので、クライアントが response-auth が有るはずだ ということを事前に知らない限り、そもそも response-auth の無いデータに 差し換えることで攻撃ができてしまう。
  • (b),(c) 本来は nc-value で防御可能なのだが、Apache では未実装。
  • (b) 同じURLに限られるので、GET では問題なし。POST では問題有り。
  • (c) 同一の URL 及び entity-body に限られる。

ま、当たり前だけど、Basic 認証ではもうなんでもありって感じ。 問題は中間者攻撃が有り得る場合で、auth-int を使っていない場合、 GET/POST を差し換えたり URI を変更したりはできないものの、 entity-body (POST 内容) 自体は差し換えられる。 だから、例えば awstats みたいに

        if ($ENV{'CONTENT_LENGTH'}) {
                binmode STDIN;
                read(STDIN, $QueryString, $ENV{'CONTENT_LENGTH'});
        }
        if ($ENV{'QUERY_STRING'}) {
            $QueryString = $ENV{'QUERY_STRING'};
            # Set & and &amp; to &amp;
            $QueryString =~ s/&amp;/&/g;
            $QueryString =~ s/&/&amp;/g;
        }

こーんな感じの入力処理をしている場合、実質的に QUERY_STRING 相当のデータは 書き換えられちゃったりするんだなぁ、とか。 まぁ、返ってくる HTML の内容とかは普通にやると差し換え放題だから、 そんなことしなくても XSS で攻撃可能だけどねぇ。

一応 auth-int とオプション扱い機能 (a) の組合わせでは保護ができるみたいなんだが、 ブラウザ側も含めて実装されているか疑問が。 そもそも実装できるかどうかも要検討*3

で、まぁSSLは例のダイアログに「はい」と答えない限り、 この表のほとんどの攻撃は自明に防げているのだが、 それにしても CSRF は実際問題結構強力だからねぇ、とか。

Digest 認証は結構複雑で、ちゃんと理解したわけではないので、 「ここは間違ってるんでね?」って指摘は歓迎。

[Comp] The Hidden Boot Code of the Xbox

ええと、まず、何故 [Security] セクションじゃないかというと、 別に MS 以外誰も被害被らないから :-)。……って書くとアンチMSで書いているように見えてしまうが :-) :-)、 そういうわけではなくて、このネタは脆弱性届出制度で言うところの 「その脆弱性に起因する被害が不特定多数の者に影響を及ぼし得」ないものだからである。 最近ホットな Windows Genuine Advantage 回避とか、DVD CSS 回避とか、CCCD 回避とかと 一緒で、「どんどん破れ破れ」とは言わないけれど、所詮は「破られても自業自得」の範疇に収まる話題なので、 CERT/CC とか IPA -- JPCERT/CC ラインとか扱う脆弱性とは別物なのである。

にも関わらず記事を書いているのは、守る方も破る方も純粋に hack ネタとしてけっこうおもしろい からで、守る方は x86 hack として、破る方は物理セキュリティとか暗号系とかのネタとして 面白いと思ったからなのだ。

詳細は記事を読んでもらう 事にするが、まず守る方。メインの BIOS (Xbox Kernel) はFlash Memoryに書いてあるので、 普通そこを書き換えられたら何でもやられてしまう。そこで、それとは別の固定内容の BOOT ROM を discrete 回路として south bridge に仕込んで、そこでflashにイタズラされていないことを検知しようとしている。 で、システム内蔵ROMってすごく高いので、512bytes しか入れられなくて、そこに CPU初期化、PCIデバイス&メモリ初期化、RC4復号、健全性検査をなんとか押し込もうとした。 そうすると、PCI&メモリ初期化以外は収まるんだけど、PCIデバイス初期化はどうしても1000bytes以上になるので、 バイトコードインタプリタを入れて flash に書いてある命令列を読み込むことにした。 で、最後に固定鍵でRC4デコードして、結果が正しければメモリ上の復号されたコードにジャンプして、 駄目なら自害するようなコードをいれたらしい。しかも、隠しBOOT ROMの内容がばれないよう、 自害の直前に BOOT ROM をマップ解除するようなコードまで入れたという念の入れよう。

そこまでが前置きで、破る方の話。まず、RC4 の暗号鍵の取得には、 south bridge の入出力信号を tap して、通信データを解析してしまった(笑)。 そこまでしてただの x86 マシン乗っ取りたいか :-)。

で、解析は一気に進んでしまったのだが、最終的には訴訟回避のために暗号鍵を使わない 攻撃を仕掛けたいらしくて、見つけた欠陥3つ。1つは、自害コードがバグっていて、 ちゃんと自害できないというちょっとお間抜けなバグ。0xFFFFFFFF 番地で丁度 隠しROMを disable して、直後に EIP overflow でCPUが凍り付くかと思いきや、 実は何の問題もなく 0x00000000 のRAMから実行が継続してしまう……って テストしろよ (^^;。x86のその仕様は結構有名だと思うんだけどなぁ。 対策も、直前で 0x00000000 番地に CLI; HLT を書けば済む話だよなぁ。

もう1つは、いかにもやりがちだなぁと思ったバグで、隠しROMを disable する IO ポートはバイトコードインタプリタで書き込めないように保護されているのだが、 実際は一部のビットしかデコードされていないので、別のアドレスに書き込む振り をして書き込めてしまうというもの。なんていうか、ソフトウェアレベルでも この手の「暗黙の仕様の不一致」が原因となるバグって多いので、この部分はあまり 他人事ではなかったなぁ。

3つ目は、暗号鍵が解読されないと思ったらしく、復号結果の検査が単なる magic number だったというもの。で、後期バージョンでは改善されて TEA ハッシュになったらしいのだが、これって 脆弱なんだよね……。ここで可能性が2つ考えられるのだが、1つは単に TEA ハッシュしか 空き領域に収まらなかった可能性、もう1つは、万が一将来 Flash ROM の内容だけ 更新したくなったときのために、backdoor を残してある可能性。まぁ 実際は TEA ハッシュ破るのもそれなりに大変そうなので、前者かなと僕は予想している。

読んだ感じとしては、せめて 1024bytes か 2048bytes 位隠しROMがあれば、 相当強い保護が作れたとは思うんだけどねぇ。あるいは、電子署名検証系 (公開鍵暗号) が入れられれば、 Flash の公式な内容更新を許しつつも第3者の改変ROMは拒絶するようなものも 入れられたと思うのだが、どれくらいの容量が必要かなぁ。

ちなみに、現在の XBox では flash ROM は別のデバイスと統合されて交換不可能に なった一方で、有効な mod chip は相変わらず販売されているらしい。

*1 本当は本物の関数リファレンスを使って &{$ShowInfoURL{$pluginname}}($url) とかやってほしいが、APIが変ってしまう。

*2 途中からワイン飲んで酔っぱらって書いてるので、 ゆる〜い文章になってるな(笑)

*3 1. response body を全部受け取ってからしか 確認できないので、今のブラウザの「受信途中のデータを随時表示する」機能との整合性に 疑問が残る。
2. URI 以外のヘッダの値は保護されないので、例えば悪意の style sheetに差し換えとか、そういう攻撃の可能性は残る。


2005-08-14

[Security] HTTPの認証手法と攻撃耐性 (その2)

その1の続き。何考えたかというと、 Wiki とか tDiary みたいに、書き込んだ内容が最終的には全世界に公開される場合、 原理的には改竄防止とパスワードの秘匿さえ完璧なら、 通信内容自体を全部暗号化する必要って無いんだよね。 *1 というわけで、特に auth-int + response-auth の組合わせでは なりすまし(偽サーバ)攻撃にも対処できるので、 auth-int が完璧に実装されて、nc-value のチェックも真面目にやって、 response-auth の存在も強制できる (正当性を確認しないと受信結果を受け入れないような) なんらかの機構があれば、この手のアプリケーションが SSL を使わなくても (SSL利用時と同程度に)安全に使えるのかなぁと思った次第。

ただ、現実には現状の Digest 認証では無理。 特にパスワード以外のヘッダが保護されないのは はっきり言って欠陥で、いろいろと問題がありまくる気がする。 HTTP Smuggling のような Content-Length 挿入攻撃は response-auth または認証が失敗した際に Keep-alive を強制切断することで 回避できるが、他にも例えば、Refresh: ヘッダとか Content-Type: とか書き換えられると セキュリティ的に結構嫌だよねぇ。

あと、原理的に CSRF に対する防御が難しいような気がする。 特に hidden フィールドに秘密情報を埋める方は、 盗聴可能が前提なので当然安全に行うことができない。 Referer 偽装はヘッダを保護するようにすればいけるかもしれないが。

結局のところ、やっぱり SSL 保護が無難という結論になっちゃうのか?

*1 管理画面には多少の秘密情報があるかなぁとも思ったが、 tDiary に限って言えばツッコミメール送信先とコメントキーフィルタの鍵くらいだよね。 後者は設計を変えて回避可能。


2005-08-19

[Misc] 山のような仕事〜

というわけで、今週は日記ネタは山ほどあったのに、ぜんぜん書く暇がない……。

眠い〜 (=_=)


2005-08-22

[Comp] howm 試験導入

サイボウズとLinuxザウルスとテキストファイルとWikiととかいろいろ使い分けていたのだが、 いよいよ研究実装系のネタと調査研究系のネタと仕事と雑用ととかで頭が爆発して、 いろいろと作業すっぽかしかけたので、 howmを試しに導入してみた。

……いろいろな概念と使い方の対応がよくわからないよ……。

まぁ「ほげめも」 と呼んで使っていた時系列メモの発展系としては悪くないと思うので、 しばらく使ってみようかと思う。

早速 Unison の同期対象にいれる辺りがまぁ自分っぽいというか、Unison で 同期が取れそうなツールを選んで使っているというか。


2005-08-24 *

[Rail] TX開業

いやー、切符買うのに40分とか、入場制限とか、すごいことになってたねぇ。 学生時代だったら遊びに行ってたかもしれんが、特に今週は仕事山積だったんで、 行ってる暇ないっす。

研究所には何人かつくばから通っている人がいるので、早速利用している模様。 やっぱり速いらしいねぇ。

[TX入り口写真]

写真は、開業日なのに入場制限でシャッターを下ろす羽目になってしまった秋葉原駅入口。

[東西自由通路] [東西自由通路] 同じ日には東西自由通路も完成。昭和通り口側へ少し近くなった……かな? なんかまだまだ工事中なのだが、ここも店舗ができるのかな?

[Misc] 自民党総裁@アキバ

各種ニュースサイトなどで既にレポートされている通り、来ちゃったわけです。

そこらじゅうに設置された看板に「午後4時 来たる!」とか書いてあって、 実際はさんざん他の人の話で引き延ばされた挙げ句に5時前になってやっと来たわけですが、 仕事溜りまくってるんで聞いてる暇ないっす……。 まぁ小泉さんが最初に喋ったら、終わった途端に (候補者の話は聞かずに) 大多数の聴衆が帰っちゃうもんねぇ(笑)。

というわけで、純ちゃんを待ち焦がれる群衆の写真でもどうぞ :-)。

実際のところ、うちの研究センターからは駅前広場は見えないわけですが、 建設中のUDXの窓に反射した群衆ってのがちょっと面白かったんで撮ってみました。

とかなんとか言いつつ一応こんなのも撮ってあるわけですが :-)

本日のツッコミ(全2件) [メッセージを送る]

(わ) [上の写真は面白いけど、ピントが窓にあってますね。鏡にうつったオブジェの場合には、AFが効かないのでMFにしないとうま..]

おおいわ [ピント: 言われりゃ当然ですね>距離。 一応コンパクトデジカメの中でもMFとかマニュアル露出とか一通りのことは一応で..]


2005-08-25

[Comp] 落ちてました orz

なんか昼から夕方までずっと落ちてました orz その間にアクセスした人ごめんなさい。

原因はほぼ判りました。本来は CGI に渡るべきでない 特殊なリクエストが FastCGI に渡されるせいで、 CGI への wrapper という形で動かしている FastCGI クライアントが誤動作して、 それ以降の mod_fastcgi との間の通信が ボロボロになっていたようです。なまじ FastCGI にしていたおかげで、 1つの変なリクエストが後のリクエストをぜ〜んぶ巻き添えにしてくれたようで orz *1

それにしても、

./index.rb:103: [BUG] rb_sys_fail() - errno == 0

は無いよなぁ……。まぁこれも FastCGI 対応モジュールの中で落ちている可能性はありますが。

というわけで、多分 tDiary 用 FastCGI wrapper を書き直すべきだな。 暇を見つけてちゃんとした物を書いて contrib しますか……。 *2

*1 ちなみに、やや強引な方法で回避済み。

*2 ついでに CGI モジュールの仕様にもちょっとした問題を見つけたので、こちらも直さないとね。

本日のツッコミ(全1件) [メッセージを送る]

(わ) [思い腰をあげて、ようやく「orz」の意味を調べたのが今日のこと。wikipediaにはお世話になってます。最近、おじ..]


2005-08-26

[Security] 究極の key logger 対策

ソフトウェアキーボードからも情報を盗み出すキーロガーの新種が登場』 (Internet Watch)。

ここ数カ月くらいしょーもない(とか書くとまた怒られるかな?)キーロガー対策が流布しまくっていて、 この辺でも触れていたわけですが、 ついに実物が出てきましたね。

また対策と称していろいろ考えるんでしょうけど、やっぱり 「究極的な意味で、キーロガーに入り込まれたら(あるいは入り込まれる状況では) 何をやっても無駄」ということをはっきりと認知してもらうのが重要だと思うなぁ。 SecureID みたいな完全な One Time Password はかなり有用な技術だけど、 それでもログイン後のセッション鍵を盗み出すとかはいくらでも可能なので、 その時点で偽振込とかされたらアウトなわけですし。

追記 (9/27)

……なんかタイトルが煽りっぽいですけど、まぁ要するに、 「道ばたで拾ったものを食べないようにユーザが気をつけるしかない」 という当たり前のことを何で言えないのかなぁと。

もっと言えば、ブラウザのバグはパッチをがんがん当てるしか無いとして、 .exe ファイルとか得体の知れない ActiveX とかをユーザが安易に実行しちゃうような 各種クライアントの設計を「UI 設計の観点から」見直すとか、 得体の知れない実行オブジェクトを得体の知れるオブジェクトと見分ける方法を がんばってちゃんと啓蒙するとか、そういうことが一番重要ですよね。

実際、SSL の不正警告とか、ActiveX のダイアログとか、ダウンロードとか、 僕らが見ても一見して「ん? 大丈夫か?」って思うような理解困難なダイアログ は多いです。僕らは明らかに問題ない処理というのは判断付くので、 残りは「疑わしきは黒」の原則で対処できますけど、 普通のユーザはそうはいかないですよね。 その辺りユーザ教育を含めて何とかならないかと常日頃思ってます。

[Misc] あとだし日記

ここのところ本当に暇がなくて、撮り溜めた写真がたまりまくっているので、 徐々に放出しようかと。といってもやっぱり暇がないよぉ。

とりあえず、日付の後に * が付いている箇所は、後からの追記です。


2005-08-27

[Security] Virtual Hosting と SSL Negotiation の現状

後輩の日記*1に、 最近の apache-users のメール*2への参照があった。 まぁ、よく言われる「SSL と Virtual Hosting が共存不可」*3という話。

ポート番号を変えるか別 IP 振るかしないと、HTTP over SSL の枠組みではこれは解決できない、はず。SMTP みたく、STARTTLS の機構が入ってればいいのですが(そして、返事によるとそういう仕様は実際にあるっぽい?のですが)、実際に目にしたことがありません。

で正しいわけですが、折角なのでちょっと整理しておくと、僕の把握しているところでは現時点で存在する(僕の知っている)提案は2つで、こんな感じ。

RFC2817: Upgrading to TLS Within HTTP/1.1

まず、「STARTTLS の機構」に相当するのは、RFC2817 で定義された「Upgrading to TLS Within HTTP/1.1」。 クライアントがリクエストを送るときに、 「Upgrade: TLS/1.0」 とヘッダを送っておくと、 サーバが任意で TLS 1.0 のネゴシエーションを開始する。 一方、リクエストで送るデータも含めて暗号化する必要があったり、 平文で返答が送られては困る場合は、 クライアントは最初に「OPTIONS * HTTP/1.1」という 特殊なリクエストを Upgrade と共に送って TLS 化を要求し、 実際に TLS になった時だけ実際のリクエストを送る、という仕掛け。 どちらの場合も Host ヘッダがあるので Virtual Hosting に対応できる。 URL scheme は http をそのまま利用。Apache 2.1 で実装が始まっている模様。

で、一見薔薇色の解決のようだが、重大な欠陥があって、 例えばクレジットカード番号を送ってもらうサービスがある場合に、 サーバ側から「このデータは必ず暗号化してね」と指定する手段がない。 正確には、リクエストを受け取ったときに、「426 Upgrade Required」というヘッダを 返すことで暗号化を要求できるんだが、少なくともリクエストヘッダは送っちゃった後 *4なので、 この時点で暗号化を要求しても手遅れなんだよねぇ。 そういうわけで、HTML などに「このフォームは暗号化が必要」とか指定する機構を追加するか、 新しい URL scheme を定義して区別するとかしないと、現状では使い物にならない。 インターネット全体の方向性としては、暗号化プロトコルのために別 port を使うのは 避ける方向になってきているようで、まぁその流れに沿った仕様ではあるのだが、 少なくとも短期的にはダメ。

Apache Users ML の該当スレッドによれば、特殊な用途には既に使われているそうで、 それは恐らく、

  • 用途が特定される場合には問題が起こらないように上位プロトコルを設計しておけばこれでも十分
  • 本質的にクライアントが勝手に暗号化の有無を決めていい種類のプロトコルなら問題ない

からなのではないかと推測。通常の Web にはどちらも成り立たない *5から使えないねぇ。

RFC3546: Transport Layer Security (TLS) Extensions

でもう1つの解決は、現状の https をそのまま使う方法で、 RFC3546「Transport Layer Security (TLS) Extensions」に ある Server Name Indication 拡張。単純にクライアント側からの TLSネゴシエーションの最初のメッセージにホスト名を含めておくというもの。 現状の TLS 1.0 と互換性もあるし、十分にシンプルな拡張だし、 セキュリティモデルが大きく変わらないので、こちらのほうが少なくとも短期的には 現実的かな。*6

しかし、このRFC の Section 6.1 (Security Considerations: Security of server_name) を見ると、既にこの時点 (2003年6月) で IDN のセキュリティ問題は RFC に書かれるほどには(判っている人には)認識されていたんだねぇ、 といまさらに思ったりする。なんで2005年2月になっていまさら……。

[Misc] 休みの日のお勉強

CRYPTREC のレポートとか 眺めたりしつつ過ごす休日。

セキュリティ関係の仕事って総合力なので、ある事象に関して安全性の判断をしようとすれば、 いろいろなレベルの事を考えて、その最小値を取らなきゃいけない。 例えば、目の前のブラウザに表示されているECサイトを使うことが安全かどうか、といえば、

  1. ローカルなコンピュータのソフトウェア安全性に関する知識(例: ブラウザの動作は健全か、スパイウェアはいないか)、
  2. リモート側のコンピュータのソフトウェア安全性に関して推測できるだけの知識(例: 送ったカード番号は XSS とか CSRF とかで漏洩しないか)、
  3. ネットワークプロトコルの使い方に関して判断する知識 (例: 今繋いでいるSSL接続はちゃんと正しい証明書で保証されているか)、
  4. ネットワークプロトコル自体の知識(例: SSL 3.0 は本当に安全か)、
  5. プロトコルで使われる暗号技術の知識(例: 3DES と AES128 はどっちが安全か、56bit 暗号はどれくらい信用できるか)
  6. 暗号技術で使われる数学の知識(例: 離散対数問題はどれくらい難しいとされているのか)

とか位は考えないと自力では判断できない。 これまでかれこれ8年くらいはソフトウェアセキュリティ(当初は興味、後期は研究対象) に関わってきて、ソフトウェアのことはかなり判断できるようになったし、 うちの大学の研究室はかなり理論的な話(必ずしもセキュリティではないが)に強い人が いたこともあって、論理的思考はだいぶ訓練されたので、プロトコルとかも ある程度は思考できるようにはなってきた。 でも、暗号アルゴリズムそのものとか、その基盤になっている数学的な性質(特に解読困難さの議論)は さっぱりなので、最後の最後で気持ち悪いところが残ってしまっていたんだよね。 勿論ソフトウェアの話を研究とかでして論文を書くだけなら、 「暗号は暗号屋さんが安全にしてくれるだろ」でもいいんだけど、 それだけじゃ探求心は満足できないし、現実にプロトコルの使い方知らずに ライブラリ使ったせいで起こる脆弱性とかあるから、やっぱり 「隣3軒両隣」の分野くらいは知らないと本当の意味で安全なものって作れないんだよね。

今いる職場はソフトウェア・暗号・プロトコル・物理・量子など、 あらゆる関連分野の専門家が集まっている。 他の類似機関と比べても全分野を横断的に取りそろえている機関は なかなかないみたいで、センターの売りの1つにもなっているのだが、 実際に僕にとって、ちゃんと隣接分野を判っている人 (それもトップレベルの人)がいるのは非常に心強い。

というわけで、勉強を兼ねて週末になるとそういうものを読んでいたりするのであった。 いろいろと知識の浅かった部分が明らかになるなぁとか、 また微妙なものに気付いてしまったりとか、 *7 いろいろと得るものがあるなぁ。

*1 リンク張っていいかな─?……と 書いておいたところ、OKが出たのでリンク化。

*2 しかし、このメールの最後の「Please someone restore my faith that with linux anything is possible.」とかいうコメントを書けちゃう神経はどうよ :-(

*3 正確には、1つのHTTPSサイト+複数のHTTPサイト の共存はOK。

*4 現状の実装だと多分フォームのデータも送ってしまった後になる。

*5 後者に関しては、フォームを見たときにクライアント側が暗号化が必要かどうか判断できないのと、 現状で全通信を暗号化強制なんてクライアント実装はとてもできないから。

*6 実際は、クライアントとサーバの片方だけが対応しているときに、 CN 不一致の扱い方を少し迷いそうだけどね。

*7 例えば、OpenSSL とか Apache などでは「MEDIUM: 128bit鍵 / HIGH: 168bit鍵以上」となっていて、3DES (HIGH) > AES128 (MEDIUM) という評価になっているんだが、 ディスクが潤沢 (256オーダ) にあれば 3DES は 2108.2 オーダで解読できる (この間素人頭で考えたのよりさらに小さいね) らしいので、 条件設定によれば逆転する。実際、電子政府推奨暗号リストでは、3DES は「当面の利用」の条件付きになっている。

本日のツッコミ(全1件) [メッセージを送る]

某後輩 [>リンク張っていいかな─? いいですよー。 ]


2005-08-30

[Misc] クロック周波数

申請書書いたり、ネクタイ絞めて某所に出張したり、戻って申請書書いたり。むちゃくちゃ疲れた……。

ここ1年くらい、脳にもクロックが埋め込まれてるんじゃないかと感じることがある。 本人全く意図してないのに、秒針の進む速度が遅いときと速いときで感覚的に倍くらい (ちょっと大袈裟) 違ったり*1、同じ単純作業するのにかかる時間が本当に倍くらい違ったり。

某知能テストゲーム *2なんかでも 明らかに5割くらい解ける問題数が違うにも関わらず、制限時間が来るまで 本人は普段より解答速度が遅いことに気が付いてなかったり *3 して、 なんかクロック周波数が低下しているなーと思う瞬間と、 逆に今日はクロックがやたらと速いなぁと思う絶好調の日がある。

……今ですか? 当然時計が3倍くらい(嘘)の速度で回って見えます。 忙しいのはいいことだとは思うけど、さすがにへとへと。

*1 不思議なことに、音楽のいわゆる bpm の方はあまり影響受けないんだよな、少なくとも人の演奏を聞いている限りは。

*2 ちなみに現在1993g。

*3 しかも、本人は「お、調子いいぞ?」とか思っていて結果を見て「あれ?」とズッコケる。

本日のツッコミ(全1件) [メッセージを送る]

ゆーな [日によって寝起きの心拍数が違うらしいですよ ]


大岩 寛 (おおいわ ゆたか) <yutaka@oiwa.jp.nospam ... remove .nospam> .

Copyright © 2005-2014 Yutaka OIWA. All rights reserved.
Posted comments and trackbacks are copyrighted by their respective posters.

記事の内容について (Disclaimer / Terms and Conditions)