| « Apple Software Updateが「新しいアプリケーション」の「アップデート」方法を修正 | スクリプトインジェクション対策の特集 - gihyo.jp » |
GoogleのPython採用と脆弱性情報の関係
GoogleがカスタムアプリケーションのホスティングにPythonを採用しました。これにより多くのセキュリティ研究者の研究対象がPythonに向けられ、PHPで報告されていたような問題がセキュリティ脆弱性して多数レポートされるようになるのではないか、と予想していました。
さっそくセキュリティ脆弱性が多く発見されるライブラリの一つであるzlibライブラリにお馴染みの脆弱性が報告されています。
CVE-2008-1721
Integer signedness error in the zlib extension module in Python 2.5.2 and earlier allows remote attackers to execute arbitrary code via a negative signed integer, which triggers insufficient memory allocation and a buffer overflow.
ImpactCVSS Severity (version 2.0):
CVSS v2 Base score: 7.5 (High) (AV:N/AC:L/Au:N/C:P/I:P/A:P) (legend)
Impact Subscore: 6.4
Exploitability Subscore: 10.0
負の整数が指定された場合が考慮されていないので攻略コードを埋め込まれた圧縮ファイルで任意コードが実行できるようです。よくあるタイプの脆弱性です。
しばらくは色々レポートされる事だと思います。
追記：
ところでこの脆弱性は未パッチです。
http://www.python.org/download/
の最新リリースは、現時点(4/14)でも、2/22日リリースされた2.5.2になっています。このページにはパッチへのリンクもありましたが、この脆弱性とは全く関係ないページが表示されていました。コメントにも書きましたが開発者がセキュリティに大きな注意を払っていない事を前提に対策を考える方が良いです。これは何もPythonやPHPに限った事ではありません。
参考
http://www.atmarkit.co.jp/news/200804/08/appengine.html
関連：
http://blog.ohgaki.net/php-1
http://blog.ohgaki.net/lamp
http://blog.ohgaki.net/lamp-p-php-perl-python-ruby
http://blog.ohgaki.net/lamp-4
追記：
予想通りの展開です。任意コード実行の脆弱性のCVEが公開されています。
http://blog.ohgaki.net/python-2-5-2
http://blog.ohgaki.net/python-2-5-3
This entry was posted on April 11th, 2008 at 14:51:09 and is filed under Security, Python
Permalink
4 comments
Python のキュリティ脆弱性レポートが増えなかったりしたら、それこそ PHP 立場ないね。
- pythonにはPHPのセキュリティ問題として多数レポートされている、ファイルセーフ機能が無いこと
などから幾つか出てくると思いますが、どんどん脆弱性が出てくる、といった状況は予想していません。その辺りは誤解の無い様に。
Googleのサービスでは、さすがに危険すぎるのでファイルやメモリにアクセスできる機能は全て無効になっており、突きどころも少なくなっています。これも脆弱性のレポート数に影響するだろうと思います。
このエントリの脆弱性のように基本の「き」ができてないような脆弱性がある、ということは他にいろいろある可能性が高い、と推測するには十分だと思います。
# 実際、画像ライブラリにも任意コード実行が可能な脆弱性が最近
# 見つかっています。あまり使われないライブラリだそうですが
# 言語コアとして添付されている物だったと思います。
研究対象としてはGoogleのサービスを攻撃できる脆弱性が最も面白いとは思いますが、例によって内部仕様は公開されていません。これが理由であまり研究対象にならない可能性もあります。どうなるか注目です。
追記：日本語が変だったので編集しました。
例えば、記憶に新しいところでは、PHP 5.2からリクエストの処理がRFC準拠ではなくなり、Perl/Python/Javaと同じ仕様になった部分があります。（ヌル文字の取り扱い）これにより、mod_securityによるセキュリティ対策が簡単にバイパスできるようになってしまいました。
Perl/Python/Javaアプリは最初からリスクがあったのですが、以前はより安全であったのにPHP 5.2からリスクを追加するような仕様変更を行うのは基本を守っていない、と考えられても仕方ないです。
# 当然ですが、このmod_securityの問題
#（本来は言語／アプリの問題なのですが）
# は既に対策済みです。
要するにみんなセキュリティ対策が万全ではないのです。開発者はあまりセキュリティの事は考えてない、と思っておく方が安全です。
これも誤解を招きそうな書き方ですね。
「セキュリティの事を考えてない」という事はないとは思いますが、「セキュリティに対する影響が考慮不足」だったり、「分かってはいるけどリソースが不足」であったり、「知ってはいたが単純ミス」があったりする事を織り込んで対処する方が安全であるし、そうあるべきだと考えています。
具体的には「脆弱性がある事を前提にアプリケーション／システムを構築／運用する」する事が大切だ、ということです。クロスサイトスクリプティング（スクリプトインジェクション）限定ですが、ちょうど技術評論社のサイトにスクリプトインジェクションに脆弱性であった場合でも被害を最小限するTIPS等を記事として連載中です。
http://gihyo.jp/dev/serial/01/php-security
Comment feed for this post