LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠

誤解を招く記事 – LAMPセキュリティを強化する4つの方法で紹介した記事ように、最近「言語を替えるとセキュリティが向上する」といった間違った認識が広まりつつあるように思えます。

結論からいうと、セキュリティに関連する機能が同等な言語であれば「言語を替えるとセキュリティが向上するいう考え」は妄想です。言語を替えても、正しいセキュリティ知識を持ち合わせた開発者が開発しないと、危ないアプリケーションが簡単に作れます。

ちょうど良い証拠となるPloneのCVEエントリが公開されています。PloneはPythonで記述されたCMSです。私も利用したことがありますが、なかなかよくできているCMSです。出来立てのCMSではなく何年も前から実用されています。フレームワークとしてPythonのWebシステムよく利用されているZopeを利用しています。

本家： http://plone.org/
日本語サイト: http://plone.jp/

さて、以下が本題の言語を替えてもセキュリティが向上しない証拠となるCVEです。

CVE-2008-1396

Plone CMS 3.x uses invariant data (a client username and a server secret) when calculating an HMAC-SHA1 value for an authentication cookie, which makes it easier for remote attackers to gain permanent access to an account by sniffing the network.

日本語訳
Plone CMS 3.xは認証に利用するHMAC-SHA1ハッシュ値を計算する際に、固定のデータ（クライアントのユーザ名とサーバの秘密文字列）を利用しているため、ネットワークスニファリング（盗聴）によりリモートの攻撃者が容易に恒久的なアクセスを取得できます。

解説
一言でいうと「一度盗聴してしまえば後から何度でも同じユーザ権限でアクセスできる」ということです。認証に利用するハッシュ値が常に同じ値になる設計は、お粗末な設計であったと言われても仕方ありません。恐らく認証コードを設計した開発者はチャレンジレスポンス形式の認証方式を知らなかったのだと思われます。チャレンジレスポンス形式の認証は少しセキュリティを勉強した方なら知っている認証方式です。

折角SHA1ハッシュを利用して認証の安全性を向上させようとしているにも関わらず、セキュリティの基礎知識不足が原因で本来ハッシュを利用して達成できる使いきりにできる認証情報が固定化されていることが問題とされています。

本来達成すべき事の半分以下した達成していませんがハッシュを利用している部分は評価できます。しかし、後に紹介するCVE-2008-1393、CVE-2008-1394の脆弱性でこの努力も台無しになっています。

CVE-2008-1395

Plone CMS does not record users’ authentication states, and implements the logout feature solely on the client side, which makes it easier for context-dependent attackers to reuse a logged-out session.

日本語訳
Plone CMSはユーザの認証状態を保持せず、ログアウト機能をクライアント側で実装しています。この為、コンテクストに依存した攻撃者がログアウトしたセッションを利用することを容易にしています。

解説
ログアウトしたつもりがログアウト出来ていなかった、という脆弱性です。「クライアント側だけでログアウトしたことにしている」のは重大なセキュリティ上の欠陥です。私のセキュリティセミナーをお聞きいただいた方は「ログアウトは必ず実装しなければならない」と話していたことを覚えていらっしゃる方も多いと思います。ログアウト機能は認証機能の基本機能であり、セキュリティ上非常に重要な機能であることは議論の余地はありません。このような重要な機能がクライアント側だけ（恐らくクッキーを利用していると思われますが、確認していません）で処理されているのは重大な設計上の問題です。

CVE-2008-1394

Plone CMS before 3 places a base64 encoded form of the username and password in the __ac cookie for all user accounts, which makes it easier for remote attackers to obtain access by sniffing the network.

日本語訳
Plone CMSバージョン3以前は全てのユーザアカウントに対して、BASE64でエンコードされたユーザ名とパスワードを__acクッキーに保存していました。これにより、リモートの攻撃者はネットワークを盗聴することにより容易にシステムにアクセス可能でした。

解説
「BASE64でエンコードされたユーザ名とパスワード」を送信するのは「テキストでユーザ名とパスワード」を送信するのと同じです。絶対に行ってならないことです。パスワードはそれが仮にSHA512でハッシュ化されたパスワードであっても、絶対にクッキー等に保存して利用してはならない情報です。セキュリティの基本中の基本です。ちなみに、この問題はネットワークを盗聴しなくても簡単に悪用できます。共用PC等からクッキーファイルをコピーする等の方法でユーザアカウントを盗むことも可能です。

CVE-2008-1393

Plone CMS 3.0.5, and probably other 3.x versions, places a base64 encoded form of the username and password in the __ac cookie for the admin account, which makes it easier for remote attackers to obtain administrative privileges by sniffing the network.

日本語訳
Plone CMS 3.0.5および恐らく他の3.x系バージョンは、BASE64エンコードされた管理者アカウントのユーザ名とパスワードを__acクッキーに保存していました。これにより、リモートの攻撃者はネットワークを盗聴することにより容易に管理者権限でシステムにアクセス可能でした。

解説
CVE-2008-1394とほぼ同じ脆弱性です。しかし、管理者アカウントの問題だけが別エントリになっているのは特別な意味があると思われます。CVEが別であることから推測すると、まさかとは思いますが、全てのユーザセッションのクッキーにBASE64エンコードされた管理者アカウントのユーザ名とパスワードを保存していた可能性があります。

まとめ

これらのCVEとして上げられているセキュリティ問題は新しい問題ではありません。「今時こんな脆弱性が！」と思える脆弱性ばかりです。

言語を替えても、適切なセキュリティ知識がないと安全なアプリケーションは作れないことは、優れたエンジニアでなくても直感的に理解できるはずです。言語はただの道具にしか過ぎません。言語を替えると自動的により安全なアプリケーションが作れるようになる、といった趣旨の発言は技術者として恥ずかしいことなので止めましょう。

最後に、Python/Zopeで作ったWebシステムだけにこういう例がある訳ではありません。皆同じです。Ploneユーザの方、早くバージョンアップしましょう。

追記：
最近追加されたPloneのCVEで漏れている物がありました。

CVE-2008-0164

Multiple cross-site request forgery (CSRF) vulnerabilities in Plone CMS 3.0.5 and 3.0.6 allow remote attackers to (1) add arbitrary accounts via the join_form page and (2) change the privileges of arbitrary groups via the prefs_groups_overview page.

複数のCSRF脆弱性だそうです。

http://plone.org/about/plone/

 Very large, active development team

    * Over the past twelve months, 84 developers contributed new code to Plone.
    * This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Ohloh, which lists most of the major open source projects in the world.
    * Over the entire history of the project, 219 developers have contributed.

Mature, well-established codebase

    * The first lines of source code were added to Plone in 2001. This is a relatively long time for an open source project to stay active, and can be a very good sign.
    * A long source control history like this one shows that the project has enough merit to hold contributors's interest for a long time.

と言うことですが、Webプログラミングに慣れていないと思わぬ落とし穴にハマるものです。

追記：
Perlのスクリプトで長い間利用されていると思われるものでも、セキュリティ対策が行われていないケースも少なくありません。ちょうど良い一例が出てきました。2008/4/1にCVEが登録されました。ちなみにクロスサイトスクリプティングに対するセキュリティアドバイザリは2000年2月に発表されています。Perlだけではありません。これが現実です。

http://www.gnbnet.com/cgi/readme/designform.html

改定履歴：
2008/02/16 Ver3.9 【重要】
mail欄などに任意のjavascirptを入力することで悪意あるコードが実行されてしまうセキュリティホール修正。
Ver3.xをご利用の方はindex.cgiを差し替えてご利用ください。また、それ以前のバージョンをお使いの方もスクリプトのバージョンアップをお願いします。

2006/01/29 Ver3.8
送信完了メッセージの文字化けバグ修正。

2006/01/26 Ver3.7
時間挿入。テンプレートファイルの入れたいところにで時間が表示されます。

2005/12/12 Ver3.6
メールアドレスチェック（セキュリティホール）修正。前バージョンをご利用の方はindex.cgiの差し替えのみでOKです。また、本文内に「”」を入力するとプレビューモードを使用した場合、メールが途中で途切れてしまうバグ修正。

2005/02/28 Ver3.5
メール誤送信用URLをノーチェックでできるように変更。

2004/02/22 Ver3.4
メールの送り先を複数指定した場合、サーバによっては送れない現象を修正。プレビュー画面の改行が無効になるバグを修正。

2003/11/13 Ver3.3
送信者へのコピーメール送信時に送信元のアドレスを管理人のものにするか送信者のものにするか選択できるように変更。スパム防止のため、デザインファイルでの設定可能項目より「メール宛先」削除。（preset.cgiでのみ指定できます。）メールの送り先を複数指定できるように変更。

2003/08/12 Ver3.2
管理者へのメール送信の際、fromアドレスがnobodyになってしまうバグ修正。

2003/07/15 バージョンアップ。
プラットフォーム取得ルーチンはfutomi’s CGI Cafeさまより再配布許可を得てパッケージさせて頂いております。

2003/05/27 バージョンアップ。
ダイレクトアクセスでの無記入メール送信防止機能追加。送信フォームごとcgiで稼動させるように変更。（必須入力エラー時の再入力防止）

2002/11/06 メールアドレス必須でない場合に送信エラーが出るバグを修正

2002/09/07 配布開始