第2回セキュアコーディング勉強会まとめ [ PowerPoint ]

Download Report

Transcript 第2回セキュアコーディング勉強会まとめ [ PowerPoint ]

第2回セキュアコーディング勉強会
まとめ
セキュアコーディング勉強会
まとめ まっちゃだいふく
1
はじめに
 セキュアコーディング勉強会 第弐回
 日付:2008年05月30日(金曜日)
 時間:19時15分~21時15分
 場所:アバンティホール会議室
 PerlのTaintモード(AzureStone)
 RealVNCから学ぶローカライズのセキュアコーディング
(hashy)
今回も全体を通して、アットホームな雰囲気な会でした。
参加者が、発表者の内容や技術的フォローを行ったり、経験談
を話して頂いたり、こたつを囲んでいる雰囲気な勉強会でした。
2
PerlのTaintモードについて#1


問題提起者:AzureStone
安全にプログラムを動かすには?
Perlには標準でTaintモード(汚染モード)という機能が内包されている
ソースの一行目(シェバング)で-Tを付けると利用可能
#!/usr/bin/perl -T
 実行プログラムの外部から来たデータはすべて汚染されていると判断して処理す
る
(プログラムによるセキュリティ強化ガイドにて知った)
 例えばWebアプリケーションの場合で入力って?










クエリストリング(POST/GET/Cookieとか)
※厳密言うとこれも環境変数
環境変数
セッションID(※厳密に言うとこれもcookieもしくはGET Request)
データベース(DBI)…
ファイルハンドル
use hogehoge; → @INC(Perlライブラリの検索パス)
特殊変数
その他のアプリケーションまたプログラム



system関数に渡す引数→ system(“cat /etc/hosts”);
環境変数
ファイルハンドル
3
PerlのTaintモードについて#2
 ユーザが入力したデータにしか目がいっていなかったり・・・
作っている場合、ユーザ入力データにしか目がいかなかったりする
 汚染されているなら、除去せよ


環境変数でforeachで回すと色々みれる
使わない物は、delete $ENV{PATH}したりする
 使うPATHを設定する
 Taintモードは万能?


正規表現なので、間違えるとダメ
Taintモードを実行すると関連モジュールが動かない場合がある
 use IO::Handle;
 use POE;

Taintモードで動かなかったら?!
 BEGIN{}句を使用する(※動的パッチとして扱う)
 Tripletailで作っていたが、Taintモードで動作しなかったが、作者に対
応してもらえた!


モジュールで対応してもらった(除去コードや検査コードを作者に連絡した)
結果TripletailはTaintモードで動くようになった
4
PerlのTaintモードについて#3
 質疑応答
 RedhatとかCentOSは最初に入っているVimは省略版、リッチ
版を入れるとHAPPYになれるw
 Mail=~○○の正規表現を.*にしたらどうなるのか?
 正常終了!(Taintチェックを外れる)
 Taintチェックは機械的チェックを挟んでいるかしかチェックしない
 続きは、perldoc perlsecで!!!




どうすればTaintedかどうか、Taintでなくなるかが記述されてる
機械的な処理チェックなので、正規表現にマッチであればチェックは通過
する
use Safe;もあるらしいがAzureStoneさん勉強中(ラクダ本)
出力段階のチェックも必要
 シェバングな注意点w
 #!/usr/bin/perl –wとかはまだ良い
 #!/usr/bin/perl –Uとかある….
 -Uは-Tの反対
 -Uのプログラムはプログラマを信用しない方がよい
5
PerlのTaintモードについて#4
 以前CGIでは#!/usr/bin/perl -Tを付けるのが一
般的との話があった
 昔は、 #!/usr/bin/perl -w –Tを付けましょうと言ってい
た
 #!/usr/bin/perl -wはuse warning;と同じ意味
 次回以降のAzureStoneさんの課題
 use Safe;とか
 IO::Handle;とか
 BEGINの書き方とか
6
PerlのTaintモードについて#補足
 「セキュアコーディング勉強会 第弐回で勉強してきました。 AzureStone SecureCoding memo - セキュアコーディン
グ」
http://securecode.g.hatena.ne.jp/azurestone/2008
0603/1212156333
 プログラミングPerl 第3版 VOLUME 2
 http://www.oreilly.co.jp/books/4873110971/
 Safe - Compile and execute code in restricted
compartments - search.cpan.org
 http://search.cpan.org/~rgarcia/Safe-2.16/Safe.pm
 perlsec - perldoc.perl.org
 http://perldoc.perl.org/perlsec.html
7
RealVNCから学ぶローカライズのセキュアコーディング#1
 講師:hashy
 ローカライズとは
 各国の環境に合わせた変更行うこと
 一般的なローカライズはメニュー・画面・ヘルプを母国語に
翻訳すること
 必要に応じてソースコードを修正すること
 RealVNCでは・・・

英語環境では動くけど日本語環境では問題がある

“パッケージの内容を表示“すると、Resourceの中にリソース情報が入っている

English.lprojをコピーしてjapanese.lprojにする

ダイアログや文字情報が入っている

Preferenceを見ると英語の情報が出てくる

ラベルを変えてやると変更可能

Interface Builderで動かす
 MacOSXの場合
 Windowsの場合


ResouceHackerで実行状態のリソース情報を編集可能
リソース情報を変えているだけ
8
RealVNCから学ぶローカライズのセキュアコーディング#2
 RealVNCのローカライズ
 プログラムが国際化されていない
 RealVNCでクリップボードの対応
 なぜか、クリップボード転送する内容がASCIIコードでフィルタリ
ングされている
 RealVNCをサービスとして登録して実行することで、RealVNCを
管理者権限で実行可能?
 JVNで見ても脆弱性情報ないなぁ・・・・
 日本語パッチではASCIIコードフィルタリングを外している
影響は???
 日本語をコピペしたい・・・・
 Shift_jisだけどそのままでよい?
 クライアント・サーバ双方にエンコーディング情報を持っていない
といけない・・・
 VNCはXプロトコルをWindows同士でもできることが前提
9
RealVNCから学ぶローカライズのセキュアコーディング#3
 まとめ
 国際化するときには注意
 便利性と脆弱性
 日本語環境対応パッチの危険性(特にリソースだけをい
じっている場合)
 パッチ公開されている場合はソースを読める人はソースを
読んでみんなでいいものを作っていきましょう
 管理者権限で動作するプログラムに対する改変はリスクを
伴う
10
参考情報
 第二回セキュアコーディング勉強会に参加したよ Hatena::Group::securecodetri::hashy1126
- セキュアコーディング
 http://securecode.g.hatena.ne.jp/hashy1126/20
080601/1212302480
 資料
 http://hashy.jp/slide/20080530securecode_locar
ize.pdf
11
セキュアコーディング勉強会について
 「セキュアコーディング」
 http://securecode.g.hatena.ne.jp/
 セキュアコーディング勉強会 第壱回
 http://securecode.g.hatena.ne.jp/keyword/2008
%2d03%2d21
 セキュアコーディング勉強会 第弐回
 http://securecode.g.hatena.ne.jp/keyword/2008
%2d05%2d30
12
最後に
 今回の講師、hashyさん、AzureStoneさんありがと
うございました。
 また金曜日夜という時間帯の中参加いただいた皆様
ありがとうございました。
 次回は、2008年07月頃に予定していますのでよろ
しくお願いいたします。
13