コンピュータセキュリティのことを考えるとShellcode（シェルコード）のことを忘れる訳にはいきません。Shellcodeとはバッファーオーバーフローを利用してコンピューターに任意コードを実行させるコードの総称です。そもそもは/bin/shなどのシェルを奪うコードが主だったので、この種のコードはShellcodeと呼ばれています。現在はシェルを奪う物だけでなく、他の操作を行う物もShellcodeと呼ばれています
Shellcodeを作る方は、山があるから登るのと同じで、Shellcodeが作れるから作る、のだと思います。
私個人はShellcodeを作ること、使うことに全く興味はないです。しかし、Shellcodeとそれを利用した攻撃は、防御の為に興味を持っています。簡単に今どきのShellcodeはどのようになっているのかまとめます。
OpenSSLにメモリを自由に参照できるhearbleedと呼ばれるバグ（CVE-2014-0160）がありました。概要はTechCruchで解説されています。昨日は対応に追われたエンジニアも多いのではないでしょうか？OpenSSLを利用したシステムの場合、影響がある可能性があります。詳しくは
http://heartbleed.com/（英語サイト）
で解説されています。
PHP Advent Calender用のエントリです。
PHPのセッション管理は非常に簡単です。セッションをsession_start()で開始して$_SESSION配列を使うだけです。便利で簡単なセッションモジュールですがセッションアダプションに脆弱であるため、一般に言われてる「ログインする時にはsession_regenerate_id()を呼ぶ」コーディングではセッションアダプションに脆弱になってしまいます。
まずは危険性と対策を紹介します。 もっと読む
久しぶりにPHPプロジェクトに貢献すべく、私が確認したセキュリティ上の問題をPHP Security Response Teamに送りました。
具体的な対応については準備が整ってからにしますが、まずは大まかな感想だけ書きます。
PHPのセキュリティは随分改善された、とお墨付きをScanの報告書「Open Source Software 2008」で貰っており、バッファオーバーフロー等の欠陥コード減っているのは事実です。Month of PHP Bug (MOPB)でセキュリティレスポンスチームのセキュリティ意識も改善されたと思っていました。
まだメールのやり取りをしている段階なので断定できませんが、セキュリティに対する意識の改善は十分では無いと言えるようです。
詳しい状況や事情、セキュリティの問題などは8月の終わりくらいには書けるかも知れません。
LAMPセキュリティを強化する4つの方法
http://enterprisezine.jp/article/detail/311
書いてある情報は有用な事も記載されていますが、偏狭な視点からの記述により誤解を招く記事になっていると考えられます。著者はセキュリティの専門家ではないようなので仕方ないかも知れませんが、間違った認識は有害です。
# 原本は読んでいません。もしかすると日本語訳にも問題があるのかも知れません。
IPAのドキュメントでは大規模開発にはJava, .NETをお勧めしているようですがTomcatのページにはこのような記載も。
Apache Tomcat 3.x and 4.x, we strongly encourage users to use the latest stable version of Apache Tomcat whenever possible. We recognize that upgrading across major version may not be a trivial task, and some support is still offered on the mailing list for users of old versions. However, because of the community-driven support approach, the older your version the less people would be interested or able to support you.
http://tomcat.apache.org/
つまり3.x, 4.xユーザは早く6.xに乗り換えてねと言う事です。PHP4の状況と同じですね。
そして現行の3.3.xの最新版に未パッチ(私が見た情報には詳しい記述がなかったので詳細は分かりません。もうすぐパッチはリリースされるのかな?)のXSS脆弱性があるようです。IPA的にはJavaは良いけどTomcatは大規模開発には使うなと言う事なのかな?
MoPBの邦訳をしていたので「例えば大規模開発にPHPは使用しない」（IPAのページが見つけられなかったので正確な言い回しでは無いかもしれません）と言う表現に一役買っているとも言えますが、私としてはどうもドングリの背比べに見えるのですけどね…
機会がある毎に、言語やフレームワークでより安全なWebサイトが作りやすくはなっても、言語やフレームワークで安全性を保証できない、と言っています。「○○言語利用しているので安全です」とか「○○フレームワークを利用して構築しているので安全です」とは言えないことは明らかです。バージョンアップについても状況は違っても似たような状態だと思います。
Stefanさんのブログに書いてあったので気がついたのですが
http://cvs.php.net/viewvc.cgi/php-src/ext/session/session.c?r1=1.417.2.8.2.35&r2=1.417.2.8.2.36
に結構面白いコミットがされています。CVS版なので正式リリースになるかは不明です。成り行きはがどうなるかは興味深いです。
MOPBで解説されていたセッションIDにインジェクションができる問題を修正しようとブラックリスティングで対応させようとしたようです。ブラックリスティングより暗号化した方が安全性と互換性を確保するのが簡単なのですがZend社の社員によるコミットだったのですがZend Platformとの互換性も維持できないパッチになっているようです。Stefanさんのブログを見るとかなり皮肉な書き方であることが分かります。このような文面になった背景にはZend社の社員により「PHP開発者に知らせず脆弱性を公開した」とあらぬ言いがかりを付けられためだと思います。
非常に古いPHPの場合、セッションIDには好みの文字列が設定できたのですが最近のPHPは
\r\n\t <>’\”\\
が不正な文字として登録されています。\r\nはヘッダスプリティング、<>'”\はXSSに明らかに利用できるので不正としても仕方ない文字ですが、
()@,;:[]?={}&%
も新たに不正な文字に加えられたました。:はZend Platformでも使っている文字だそうです。
備考： セッションIDに管理用の文字列を付け加えるのは珍しいことではありません。負荷分散や分散されたサーバ間でのデータ共有など様々な用途に管理用の文字列を付け加える場合があります。
暗号化による対処の方がシンプルかつ安全な対策だと思います…
ところで、単純にクッキーだけでセッションIDを使っている場合には問題は発生しません。つまりsession.use_trans_sid=0, session.use_only_cookies=1でPHPを使っていれば現在のPHPを使っていてもここで問題としている不具合には影響されません。
http://blog.php-security.org/archives/84-PHP-5.2.3-released….html にも書いてあるのですが、PHP 5.2.3ではchunk_split()が直っているハズだったのですが直っていませんでした。
Fixed an integer overflow inside chunk_split() (by Gerhard Wagner, CVE-2007-2872)
直したつもりが整数オーバーフローが発生するコードになっており、ヒープオーバーフローが発生します…
CVSには修正コードがコミットされています。
http://cvs.php.net/viewvc.cgi/php-src/ext/standard/string.c?r1=1.445.2.14.2.60&r2=1.445.2.14.2.61
Fix chunk_split fix – avoid using floats
Fix money_format – don’t give strfmon more arguments then supplied
Fix str[c]spn integer overflow
他のセキュリティFIXもあるのでPHP 5.2.4のリリースは近い(?)かな…
Cのコードを読める方なら気が付くと思いますが、整数オーバーフローによりdestバッファに十分なメモリが割り当てられない問題に対してint型の変数とINT_MAXを比較、符号のチェックをしても意味がないのは明白です。（負の値になった時しかチェックしていないので対策になっていない）
この指摘に対してBogusだとかFUDだとか言われるのは非常に心外だと思います。セキュリティ問題に対して正しい姿勢や理解を持っていない開発者と話をするのはかなりの疲労を伴う作業だ、という事がStefanさんのブログからは分かります… 文面からも最近フラストレーションが溜まっているような気もします。コードをチェックするStefanさんがいるPHPといないPHPでは安全性に大きな違いが発生すると思います。Hardened-PHPやMOPBをサポートするにはPayPalによる寄付もありますが応援メールも有効です。（こういうメールは英語が下手でも問題はないです）
もう何年か前になりますがStefanさんがPHPプロジェクトへの貢献を始めたころ「整数オーバーフローの修正はセキュリティ脆弱性なのでそのことを明記すべき」と指摘した事がありました。信じがたいかもしれませんが「攻撃可能かどうか分からないし脆弱性でなく普通のバグ修正だ」と主張する開発者がいたためPHPのこの手のヒープオーバーフローセキュリティ修正は「fixed crash」とCVSログに書いてあるだけの場合が多く、NEWSファイルにも記載されない事が当たり前になっていました。
MOPBでPHPのセキュリティホールばかり書いているので「PHP本体のコード、最低だね」と思われているかも知れません。他の言語でも「最低」なコードは探せば いくつでも見つかると思います。今日、full-disclosureに投稿された記事です。
Description:
The source of python contain a various modules, the zlib module contain a minigzip tool, ( * minigzip is a minimal implementation of the gzip utility. ).
Source error:
the error was found in:
– void file_compress(file, mode)
because the use of strcpy() is inapropriatly—
#define MAX_NAME_LEN 1024
[..]
void file_compress(file, mode)
char *file;
char *mode;
{
local char outfile[MAX_NAME_LEN];
FILE *in;
gzFile out;strcpy(outfile, file);
strcat(outfile, GZ_SUFFIX);
—the function file_compress() was called by main() function.
Proof of concept:
if you want test the vulnerability try:
$ minigzip `perl -e “print ‘A’x1050″`— starcadi
教科書に書いてあるstrcpy()スタックバッファオーバーフローに脆弱です。固定バッファ＆長さチェック全くなし…. そう言えばMOPBでもこれとほぼ同じ脆弱性が解説されています。偶然なのか、関連があるのか興味があるところです。
（備考：もしかすると作者はファイル名が関数にわたるまでに開いてみるので長すぎるファイル名は渡せない、と考えたのかも知れません。作者のシステムではMAX_NAME_LENとシステムの最大パス名が同じだったのかも知れません。いずれにせよ、危険なコードを書いてしまう考え方です）
モジュール作者の能力の問題もあるかも知れませんが、スクリプト系言語とは言えプログラミング言語なので「自分で自分の首を絞める」ようなコードには対応していない場合も多いと思います。バッファオーバーフロー脆弱性を使わなくてもスクリプトだけでいくらでも悪意をもった行為が行えます。言語なので多少のバッファオーバーフローくらいは問題にならない、と考えている開発者も多いと思います。言語とその言語のモジュール型ライブラリにどの程度のセキュリティを達成させるか?微妙な問題です。
しかし、一つ一つは小さな問題（このPythonの脆弱性も重要度としては「中」レベル）でもスクリプト系言語とそのモジュールはメモリ管理エラーが無い方が望ましいと思います。小さな脆弱性でも組み合わせて重大な影響を与える攻撃が可能になる場合は多いです。Pythonの場合、バッチではなくGUIアプリケーションも多いのでユーザがZIPファイルを開いたら、攻撃コードが実行された（例えば、4321ポートで接続を待つ）などとなりかねないです。Webの場合も同じようにZIPファイルを扱うアプリには、同様の攻撃が行えるかも知れません。
PHPの場合、特殊で多くの共有型Webホスティングサービスで利用可能である事、「自分で自分の首を絞める」コードにもある程度対応してしまっている事から問題を複雑にしています。この結果、PHPの場合は他の言語よりも高いレベルのセキュリティを求められていると思います。
以前、mod_phpと悪意を持った外部プログラムを組み合わせて利用するとApacheのログの読み書きが自由に行える脆弱性が公開されていました。アドバイザリではmod_phpだけ記載されていましたが、この脆弱性もmod_phpに限ったことではありません。mod_python, mod_perl, mod_rubyでも同じ事が可能です。
Month of Python/Perl/Ruby Bugs (Python/PerlはMOPBですね）してくれないかな…
MOPBでPHPの脆弱性ばかり書いているので書いておきます。
critical: Arbitary code execution and denial of service CVE-2007-0774
An unsafe memory copy in the URI handler for the native JK connector could result in a stackoverflow condition which could be leveraged to execute arbitary code or crash the web server.
Affects: JK 1.2.19-1.2.20
Source shipped with: Tomcat 4.1.34, 5.5.20
MOPBでPHPのセキュリティ問題ばかり書いているので書いておきます。
Multiple cross-site request forgery (CSRF) vulnerabilities in TKS Banking Solutions ePortfolio 1.0 Java allow remote attackers to perform unspecified restricted actions in the context of certain accounts by bypassing the client-side protection scheme.
出典：CVE-2007-1332
Multiple cross-site scripting (XSS) vulnerabilities in TKS Banking Solutions ePortfolio 1.0 Java allow remote attackers to inject arbitrary web script or HTML via unspecified vectors that bypass the client-side protection scheme, one of which may be the q parameter to the search program. NOTE: some of these details are obtained from third party information.
出典：CVE-2007-1331
これ、よく見ると銀行用のアプリケーションですね。
「Javaで作っているので安全」と言える訳はありません。「ORMを使っているので安全」と言える訳でもありません。当然、「○○フレームワークを使っているので安全」とも言えません。「Javaを使っているのでコード実行されない」と言う事もありません。JSPをインジェクトして実行できてしまったWebアプリもあります。
Webアプリの安全性は言語やフレームワークだけでは確保できません。
常識ですよね。と言いたいところですがNRIセキュアテクノロジーズによると常識とも言えないと思われます。
http://www.atmarkit.co.jp/news/200607/27/nri.html
先日、Java用のWebアプリ入門書を見ていたら間違った（とまでも言わなくても無用な制限を付ける）セキュリティ確保の方法が紹介してありました。Javaで構築されたWebアプリに使い辛い物が多いのはこういったノウハウが広まっているからなのでしょう。
MOPBでPHPの脆弱性ばかり書いているので他の脆弱性も書いておきます。
Miles Egan discovered that mod_python, when used in output filter mode, did not handle output larger than 16384 bytes, and would display freed memory, possibly disclosing private data. Thanks to Jim Garrison of the Software Freedom Law Center for identifying the original bug as a security vulnerability.
出典：USN-430-1
MOPBでPHPの脆弱性ばかり書いているので書いておきます。
Multiple unspecified vulnerabilities in WebAPP before 0.9.9.6 have unknown impact and attack vectors. NOTE: This information is based upon a vague initial disclosure. Details will be updated after the grace period has ended.
出典：CVE-2007-1259
WebAPP before 0.9.9.5 allows remote attackers to submit Search form input that is not checked for (1) composition or (2) length, which has unknown impact, possibly related to “search form hijacking”.
出典：CVE-2007-1187
Summary: WebAPP before 0.9.9.5 does not “censor” the Latest Member real name, which has unknown impact.
出典：CVE-2007-1186
The (1) Search, (2) Edit Profile, (3) Recommend, and (4) User Approval forms in WebAPP before 0.9.9.5 use hidden inputs, which has unknown impact and remote attack vectors.
出典：CVE-2007-1185
The default configuration of WebAPP before 0.9.9.5 has a CAPTCHA setting of “no,” which makes it easier for automated programs to submit false data.
出典：CVE-2007-1184
WebAPP before 0.9.9.5 allows remote authenticated users to spoof another user’s Real Name via whitespace, which has unknown impact and attack vectors.
出典：CVE-2007-1183
全ての今月の脆弱性情報です。多すぎるので全てを書いていません。言語に関わらずCMSには脆弱性が多いです。すべてのCMSユーザはセキュリティ情報に常に注目するべきです。
追記：後で見てみると「CAPTCHA設定がデフォルトOFFなので…」とありますね。これでCVEを作るとなるとかなりの数のWebアプリが脆弱… 生成されるCAPTCHAイメージがOCRに脆弱（PEARのCPATCHAなど）… などCVEが大量に作れます。放っておくとこのブログも海外からのコメント・トラックバックSPAMが毎日数百… 確かに今時CAPTCHAは必須ともいえます…
MOPBでPHPの脆弱性ばかり書いているので他の脆弱性も書いておきます。
Miles Egan discovered that mod_python, when used in output filter mode, id not handle output larger than 16384 bytes, and would display freed memory, possibly disclosing private data. Thanks to Jim Garrison of the Software Freedom Law Center for identifying the original bug as a security vulnerability.
出典：USN-430-1