今年の2月にSAMLライブラリの脆弱性が報告されていたことを覚えている人も居ると思います。
この脆弱性はXMLコメント（<!– –>）の取り扱いの違いによって、本来のユーザーではない攻撃者を認証してしまう事が問題であったとしています。
攻撃用の文字列サンプルは以下のような物です。
<NameID>user@example.com<!—->.evil.com</NameID>
攻撃が可能になる理由はXMLコメントの取り扱いの違いにあります。
これにより攻撃者が別のユーザーに成り済ませてしまう問題が発生しました。1
Python 2.7.14が2017/9/16にリリースされました。Pythonの開発はバージョン3系に移行しており、2系はセキュリティ修正のみのリリースになっています。とは言ってもモジュールの変更を見るとバグフィックスやドキュメント修正も含まれているようです。
Python 2.7.14のリリースはソフトウェアセキュリティの基本を学ぶには良い題材になります。
コンピュータで数値を正確に扱うのは「実は結構難しい」です。つまり「コンピューターは数値を正確に扱えない」という事です。「コンピューターが数値を正確に扱えない？！何を言ってるんだ？！」と思った方は是非読んでみてください。
Googleがクラウドコンピューティングの言語としてPythonを採用したのでセキュリティ研究家が脆弱性を調査し、今年はPythonの脆弱性が多く報告されるはず、とこのブログで予想しています。また新たな脆弱性が報告されているので書いておきます。
今回は整数オーバーフローが多いので、整数オーバーフローを中心に調査したのだと思われます。
Python 2.5.3以上でないと穴だらけと言えますが….
http://python.org/download/
と言った状況のようです。
しかし、予想通りとはいえ数が多いですね。
CVE-2008-3144
Multiple integer overflows in the PyOS_vsnprintf function in Python/mysnprintf.c in Python 2.5.2 and earlier allow context-dependent attackers to cause a denial of service (memory corruption) or have unspecified other impact via crafted input to string formatting operations. NOTE: the handling of certain integer values is also affected by related integer underflows and an off-by-one error.
CVE-2008-3143
Multiple integer overflows in Python before 2.5.2 might allow context-dependent attackers to have an unknown impact via vectors related to (1) Include/pymem.h; (2) _csv.c, (3) _struct.c, (4) arraymodule.c, (5) audioop.c, (6) binascii.c, (7) cPickle.c, (8) cStringIO.c, (9) cjkcodecs/multibytecodec.c, (10) datetimemodule.c, (11) md5.c, (12) rgbimgmodule.c, and (13) stropmodule.c in Modules/; (14) bufferobject.c, (15) listobject.c, and (16) obmalloc.c in Objects/; (17) Parser/node.c; and (18) as…
CVE-2008-3142
Multiple buffer overflows in Python 2.5.2 and earlier on 32bit platforms allow context-dependent attackers to cause a denial of service (crash) or have unspecified other impact via a long string that leads to incorrect memory allocation during Unicode string processing, related to the unicode_resize function and the PyMem_RESIZE macro.
CVE-2008-2316
Integer overflow in _hashopenssl.c in the hashlib module in Python 2.5.2 and earlier might allow context-dependent attackers to defeat cryptographic digests, related to “partial hashlib hashing of data exceeding 4GB.”
CVE-2008-2315
Multiple integer overflows in Python 2.5.2 and earlier allow context-dependent attackers to have an unknown impact via vectors related to the (1) stringobject, (2) unicodeobject, (3) bufferobject, (4) longobject, (5) tupleobject, (6) stropmodule, (7) gcmodule, and (8) mmapmodule modules.
最近CVEのコピー&ペーストが続いていますがこのブログに書いていた予想通りの展開なのでまたコピーです。
コアとはいえあまり重要ではない箇所の脆弱性ですが、Python 2.5.3にリモートコード実行の可能性がある脆弱性がレポートされています。
CVE-2008-1679
Overview
Multiple integer overflows in imageop.c in Python before 2.5.3 allow context-dependent attackers to cause a denial of service (crash) and possibly execute arbitrary code via crafted images that trigger heap-based buffer overflows. NOTE: this issue is due to an incomplete fix for CVE-2007-4965.
Impact
CVSS Severity (version 2.0):
CVSS v2 Base score: 6.8 (Medium) (AV:N/AC:M/Au:N/C:P/I:P/A:P) (legend)
Impact Subscore: 6.4
Exploitability Subscore: 8.6Access Vector: Network exploitable , Victim must voluntarily interact with attack mechanism
Access Complexity: Medium
Authentication: Not required to exploit
Impact Type: Provides unauthorized access, Allows partial confidentiality, integrity, and availability violation , Allows unauthorized disclosure of information , Allows disruption of service
直したつもりが直っていないのはよくある事です。直したはずだったCVE-2007-4965は以下の通りです。
CVE-2007-4965
Overview
Multiple integer overflows in the imageop module in Python 2.5.1 and earlier allow context-dependent attackers to cause a denial of service (application crash) and possibly obtain sensitive information (memory contents) via crafted arguments to (1) the tovideo method, and unspecified other vectors related to (2) imageop.c, (3) rbgimgmodule.c, and other files, which trigger heap-based buffer overflows.
備考：古いブログですが公開し忘れしてい分です。
PHP5/PHP6の開発もPython 3000 (Python 3.0)のようになれば素晴らしいのですが、難しいでしょうね…
後方互換性は非常に重要です。今まで動いていたプログラムがバージョンアップしたら動かなくなる、と言う事態は開発者であれば誰でも避けたいものです。しかし、後方互換性を重視するあまりツジツマが合わなくなる事がよくあります。時間と共に合わなくなったツジツマはだんだんと大きくなっていきます。最初のうちは合わないツジツマはあった方が良い物ですが、だんだんと使い辛いものなっていきます。
些細な事ですがPHPの場合、古い関数の命名規約は「thisisfunctionname」と単語の区切りを付けないルールでしたが今のルールは「this_is_function_name」と単語を_で区切るルールになっています。この為、システムにデフォルトで含まれる基本的な関数であっても2つの命名規約に則った関数名が使われています。PHPには関数のエイリアス機能があるので新しい命名規約に則った関数名と古い関数名両方が存在しても問題無く利用できる機能があります。にも関わらず新しい命名規約に則った関数は作られていません。（と言うより反対する人がいるので作れなかった）クラス名や関数名も最近の言語に習って大文字・小文字を区別する方が良いと思いますが、これも実現できませんでした。（PHP5開発の際に議論されたが却下）
代わりにPHPプロジェクトが選択している仕様変更の手順はメジャーバージョンアップ、マイナーバージョンの度に徐々に少しずつ仕様を変更していく手順を取っています。strtotimeが失敗した場合の戻り値が-1からfalseに変更されたのもその一例です。
Python 2.xとPython 3.xが描いているようなアップグレードが言語として理想的なアップグレードの一つだと思います。