Synology NASのPHP2Shell、DSM更新だけでは直らない

DSMを最新にしただけでは、SynologyのNASのPHP2Shellは閉じません。修正版が出ているのは、「パッケージ センター」から入れたPHPとアプリのほうです。

Synologyは10月31日に勧告Synology-SA-26:14を改め、DSM 6.2〜7.1向けのSynology CalendarとMail Stationの修正版を加えました。29日までに古いDSMのPHPを更新して閉じた会社も、見直しておきたい改訂です。

古いDSMの対応は、31日の改訂まで見る

勧告は、10月22日の初版から3回改められました。

気をつけたいのは、プレスリリースと勧告で書き方が違う点です。リリースは10月29日の更新までで、31日の追加は載っていません（11月2日確認）。PHPを更新すれば依存するパッケージは自動で再起動して解決する、という説明もリリースのものです。

ただし、同じリリースの注記によると、Mail Stationはパッケージ センターで手動の更新が要ります。Calendarも、勧告の表には修正版の番号があります。確認の基準は、リリースではなく勧告の表に置くのが確実でしょう。

PHP 7.4.33は、末尾の番号まで見る

本家のPHPが修正版を出したのは、8.2系以降です。7.4、8.0、8.1の最終版はそれぞれ7.4.33、8.0.30、8.1.34で、php.netではサポート終了の扱いです。IPAも、8.1以前はサポート終了を迎えていると注意を促しています。

ところがSynologyは、この3つの系列にも修正版を用意しました。版の番号は本家の最終版のままで、変わるのは後ろのビルド番号だけです。同じ「7.4.33」でも、DSM 7.2以上なら7.4.33-0131以上が修正版で、それより前は未修正となります。

PHP 8.1以降はDSMの版で分かれません。修正版は8.1.34-0120、8.2.35-0171、8.3.36-0051、8.4.27-0051です。

つまり、Webから見える「PHP 7.4.33」の表示だけでは、修正の有無は分からないはずです。版の番号で判定する外部の脆弱性スキャンなら、更新のあとも検出が残るかもしれません。判断の材料は、パッケージ センターのビルド番号になります。

一方、PHP 7.3に修正版はありません。勧告の文面は「No fix will be provided」で、理由はサポート終了です。本家のサポートが終わった7.4、8.0、8.1は手当てして、7.3で線を引いた形です。7.3に頼るアプリは、新しいPHPへ切り替えるか、止めるかの二択になります。

今回の修正は、サポートを終えたDSMへの特別な対応でもあります。SynologyはDSM 7.2、7.1、7.0、6.2をend-of-lifeと呼んでいて、次の脆弱性でも同じ手当てがあるとは限りません。修正版が出たことを、古いDSMを使い続ける理由にはしないほうがよさそうです。

もっとも、DSMを上げるときはパッケージの確認が要ります。リリースノートによると、PHP 7.3、7.4、8.0はDSM 7.3で、PHP 8.1とMail StationはDSM 7.4でサポートの対象から外れました。上げる計画があるなら、アプリが使うPHPの系列も一緒に決めておくと、作業の当日に慌てません。

DSMの中のPHPがスキャンに出たら

DSMの中にも、システム用のPHPがあります。Synologyは、外からアクセスできるモジュールを含まない設計で、悪用の危険は非常に低いと評価しました。修正は後のDSMの更新に回し、その理由に、脆弱性スキャンの結果とコンプライアンスの状況をそろえることを挙げています。

したがって、スキャンの報告書にPHP2Shellの行が残っても、急いで消せるものではなさそうです。DSMのリリースノートで最も新しいのは10月12日のUpdateで、PHP2Shellの公表より後のDSMはまだ載っていません（11月2日確認）。

ISMSの審査や取引先の点検で聞かれたら、Synologyの評価と修正の予定を、例外の理由として記録しておくと説明がつきます。修正の入ったDSMが出たら、その記録を閉じます。

もっとも、この評価はDSM内蔵のPHPの話です。Web Stationなどの対象パッケージは別で、例外にはできません。

対象になるNAS、対象外のNAS

対象は、PHPに依存するパッケージを入れたNASです。Synologyが挙げたのは10個です。Calendar、IDrive、Joomla、KodExplorer、Mail Station、MediaWiki、phpMyAdmin、vtigerCRM、Web Station、WordPress。

バックアップの担当者が気にするHyper Backupは、影響なしです。Synology Driveも対象外ですが、名前の似たIDriveは他社のパッケージで、こちらは対象に入ります。

Node2Shellの名前で知られるBrotliの脆弱性も、気にしすぎなくてよさそうです。10月29日の勧告SA-26:15では、12の製品のうち影響があるのはSynology Chat Clientだけで、修正は作業中です。

急ぎ度は、NASの使い方で分かれます。次の表は編集部の目安です。

最後の行の会社にも、DSM本体の確認は残ります。SynologyのNASを狙うランサムウェアの件は、C3RB3Rの記事でご覧いただけます。

QNAPのNASも使う会社は、ここまでの手順をそのまま当てはめられません。10月22日の勧告QSA-26-18では、修正の中心はQTSやQuTS heroなどOSの更新で、24日に解決済みとなりました。22日にはQNE向けのQSA-26-19も出ています。

パッケージ センターから始める手順

1. 部署や拠点で買ったNASも含めて全台を洗い出し、DSMの版を記録します。
2. 「パッケージ センター」のインストール済みの一覧で、対象の10個とPHPの有無を見ます。版は末尾の番号まで控えます。
3. 社外から開けるパッケージがあれば、ルーターのポート転送やリバースプロキシ、QuickConnectを先に閉じます。
4. PHPとパッケージを、表の版以上に更新します。Mail Stationは手動です。
5. 社外から開けていたNASは、更新の前に置かれたファイルがないか、Web Stationの公開フォルダーとログを確認します。更新しても、置かれたファイルは消えません。

NASは台帳に機器として載っていても、中で動くアプリまでは載っていないことが多いものです。手順2で控えた一覧を、そのまま台帳の列に足しておきませんか。次に同じ形の脆弱性が出た日に、部署を回って探し直さずに済みます。