バグ修正によるバグ

悲しい事例がありました。
Ghostscriptというソフトウェアがあります。
これはPostScript/Portable Document Format (PDF)インタプリタです。
こう聞くとそんなものもあるんだ、と感じるくらいの人も多いかもしれませんが、いろいろな場所で使われています。
プリンタに文書を出力する際にフォーマットを適合させるような場面で使われることがありますし、逆にプリンタに出力しているようにして操作した結果をPDFとして出力するような場合にも使われる機構です。
このため、Ghostscriptはこれをそのままエンドユーザが利用するという場面よりも、エンドユーザが使っている裏側で意識せずに使っていることがよくあるソフトウェアの一つです。

このGhostscriptの最近の更新で悲しい事例がありました。
こんな感じで進みました。

• 機能拡張した
  pipeを使えるように機能拡張がありました。
  これによって特定の使い方をした際に、自由度が上がり、これまで以上に便利に使えるようになりました。

   

• patchの実装
  意図しない使い方ができることがわかりました。
  追加実装したpipe処理の機構の処理対象文字列の内容確認機能が十分でなく、意図しない使い方ができることがわかりました。
  対応するためのコードが追加されました。

   

• patchのpatchの実装
  修正するための実装変更がさらに問題を含んでいたことがわかりました。
  さらに対応するための機構の改善が検討され、新しいものが実装されました。

関係者でない立場で外から見て文字にしてしまうとこのくらいになってしまいますが、Ghostscriptのgitのコミットログを見ていると、中の人たちが大変なことになっていたことが想像できます。

これはどこででも起こりうる問題です。
最近ですと、WordPressプラグインのバグ修正周りで起きた特権昇格の事例がありましたし、MOVEitのコマンドインジェクションに絡む連続パッチの事例もありました。
プログラム作成に限らずに考えると、なにかの問題に対応しようとして急いで変更した結果、別の問題を含む状態にしてしまったことがすぐにわかって大変な目にあった、という経験がある人は、もしかしたら少なくないのではないでしょうか。

利用者の立場では、修正を速やかに適用することを心掛けることは頑張れば実施できそうです。
実装者の立場では、問題がわかった際には速やかにそれに対応したものを提供したいという心理が働くのが普通だと思います。
しかしここで少し落ち着き、「他にも同様のコーディング上のミスがまだありそうか、また、私たちがすでに知っているバグを引き起こすために他にどのようなトリックが使用できるのか」を自問する取り組みを試みてみてください。
なかなかに難しい状況である場合もあると思いますが、結局はこういう取り組みが全体の質の向上や問題の最小化につながってくのだと思われます。

参考記事（外部リンク）：Ghostscript bug could allow rogue documents to run system
commands
nakedsecurity.sophos.com/2023/07/04/ghostscript-bug-could-allow-rogue-documents-to-run-system-commands/