次世代Webカンファレンス 2019:HTTPSセッションが面白かった

以前から気になっていた「次世代 Web カンファレンス 2019」を、ようやく聴きに行くことができました。

たくさんのトークがありましたが、ここではHTTPS (hashtag: #nwc_https)をメモしておきます。なお、このセッションが間違いなく一番アツく、一番面白かったです!

以下、当日参加した、もしくは動画を見たという前提でのメモなので、見てない人はぜひ見ましょう。

PKI

「低レイヤから行きましょう」ということで、はじめはPKI絡み。Symantecのdistrustと、日本のGPKIの話でした。

トーク中に何度か出てきましたが、認証局(厳密にはCAとRAを分けて書くべきですが、どうせみんな一緒なので敢えてこの文章では分けてません。念のため)の基本要件となるCA/Browser ForumのBaseline Requirementsというドキュメントがあります。証明書を扱われる方は一読を。

Symantecのdistrust事件

細かい経緯は既に多く書かれているので省略します。

現在、Google ChromeおよびFirefoxでは、Symantecおよびその関連会社の発行したSSL証明書を利用したWebページは、エラーとなって表示できません。ここでは、Symantecの関連会社であるThawteとGeotrustの例がありましたので紹介しておきます。

これらのページをGoogle ChromeもしくはFirefoxで開くと、証明書エラーとなります。

f:id:ozuma:20190114232041p:plain

なおこのエラー画面のために、FirefoxChromeも、どちらもわざわざ固有のコードを埋め込んで実装しています。特にChromeFirefoxと違いブラウザ内にトラストストアを持っていないので、本来はOSの「信頼されたルート認証局」をトラストアンカーにするのですが、わざわざこのためのエラーコード NET::ERR_CERT_SYMANTEC_LEGACY を定義して証明書をチェックしています。

net_error_list.h:

// The certificate chained to a legacy Symantec root that is no longer trusted.
// https://g.co/chrome/symantecpkicerts
NET_ERROR(CERT_SYMANTEC_LEGACY, -215)

一方、Safari, InternetExplorer, Microsoft Edgeは通常通り表示されます。Googleのdistrust宣言に乗っていないからですね。

f:id:ozuma:20190114232947p:plain

ただしEdgeは将来Chromiumベースとなるため、将来は同じ挙動となります。その頃にはもう、Symantecの証明書はこの世に残っていないと思いますが。

トークでは皆さん遠慮して言ってなかったのですが、たかが(と敢えて書きます)一企業に過ぎないGoogleがdistrust宣言をすることで、巨大CAをあのようにいとも簡単に潰してしまうことが本当に正しいのか。私としては、むしろ「Google怖い」というのが素直な思いです。

この先、未来永劫Googleが正しい判断をして正しい行いをする保証などどこにもありません。Chrome/Chromiumが寡占状態になったとき、Googleに敵対する企業が認証局ビジネスをやっていたら……それでもGoogleは公正にふるまい続けるでしょうか。私にとっては、Certificate Transparencyと合わせて、「Google怖いな」という思いをすり込まれた思い出が残ります。

GPKI

こちらも、詳細はブログにまとめられている方がいらっしゃるのでそちらを紹介します:

GPKIは日本政府謹製の認証局でしたが、そちらの運用が上手く回っておらず、Firefox(というかmozilla)の信頼するroot CAから外されてしまったというものです。ここで問題視されたのは、失効処理(Revoke)です。

Baseline Requirementsでは、認証局は自身の発行する証明書に問題があるのではという報告を受けた場合、24時間以内に調査を実施し、問題があれば失効させなければいけません。しかしGPKI側は、「いや、どうせ待ってればExpireして失効するから、そのままにしておくという」という回答をしてしまいました。これでは認証局として適切な運用がなされていると判断できないため、GPKIはMozillaにroot CAと認められませんでした。

ただこの時のメールのやりとりを見ていると、担当者の方を責める気にはとてもなれません。私もかつてSIerで官公庁周りのシステムを触ったことがありますが、本当に神経を使いますし、そう簡単においそれとシステム変更などできません(証明書入れ替え、という定型作業であっても)。

GPKIがかつて使われていたところは現在、その多くはセコムの証明書を使うことで落ち着いています。実際、認証局の運用をわざわざ官庁でやる必要は感じられませんし、その費用を考えたらセコムから買った方が安いでしょうから、合理的な判断だと思います。

ちなみにアメリカの例では:

となっています。NSAがLet's Encryptというのは面白いですよね。

これからの認証局

司会のjxckさんからは、これからCAはどんどん減っていってしまうのではという意見が出ました。これはmozaic.fmでもおっしゃってましたね。EV証明書もなくなっていくかもしれない、認証局はとても高いセキュリティレベルが求められてちょっとでもミスると徹底的に叩かれる、このような状態で新規参入したいところも無いだろうし寡占状態となるのでは、と。

しかしこれに対して、むしろCAは増えている、というのはちょっと驚きでした。そういえば、確かにAmazonも始めていた。そしてGoogleですが……これはトークでも触れられていましたが、WebブラウザもOSも作っており、Webサービスもやっている企業が、認証局もやるというのはちょっと「おかしい」よなと私も思います。

あとEV証明書については、Stripe Inc、というキーワードだけ挙げておきます:

TLS 1.3

TLS 1.3については、確かに後方互換性を確保するために、これまでに無いパターンで大規模実験しながら作っていたなぁという感想です。実際、導入に乗り気であったFacebookは、わざわざ https://www.tls13.facebook.com/ というTLS 1.3テスト用の環境を用意しました。(これを使っていた人、どのくらいいるかな。RFCドラフト段階でテストするために作られたので、かなり前からあります)。

NW経路途中のファイアウォールやロードバランサなどのアプライアンスを引っくるめ「ミドルボックス」と呼びますが、これで叩き落とされないようにするため、TLS 1.3は一部にちょっと変なところがあります。

f:id:ozuma:20190114235756p:plain

例えばTLS 1.3のServerHelloは、Handshake時のVersionを0x0303(TLS 1.2)と応答します。ただしsupported_versionsというExtensionをくっつけて、この中でVersionを0x0304(TLS 1.3)と指定します。これは、一部のミドルボックスでServerHelloに素直にTLS 1.3と指定すると通らないことが分かったためです。このように、見る人が見ると「ツギハギ」に見えないことも無いのですが、そのぶんTLS 1.3は強力な後方互換性を持っています。

TLS 1.2は、そのまま残す。そしてTLS 1.3は改良していって、TLS 1.4, TLS 1.5...となっていくんじゃないかな」というの初耳で、なるほど~と思いました。一つの理由は、kjurさんのおっしゃったようにIoTデバイスなど。そしてもう一つの理由として、4maさんが強調されていましたが、セキュリティは常にalternativeが必要という観点。

これから先、TLS 1.3のプロトコル自身に致命的な脆弱性が見つからないとも限りません。だから何かが見つかってしまった場合、スイッチするために選択肢は最低2つ無いといけない。TLS 1.2はその命綱として生き続けるでしょう。

ちなみにTLS 1.3利用率の伸びは、kjurさんの作られているSSL Pulseをグラフ化したページで見ることができます。

TLS 1.3は現在10%ほどで、ほとんど横ばいです。ほぼFacebookトラフィックではないか、とのこと。

※上記↑、kjurさんより指摘いただき、「上記SSL Pulseのグラフはトラフィック数ではなく、サイトの数となります」とのことでしたので修正します。

SXG(Signed HTTP Exchange)

これも初めて聞いたときは、「怖い! Googleを批判する記事を、Chromeがわざとエラー出すことできる!」と真っ先に思った技術です。(私は陰謀論者なので、すぐにGoogleと陰謀を結びつけてしまうのです。ただのクセなのであまり本気に取らないでください)(こういう注意を入れないと、面倒な世の中なので)

確かにCDNからの配信でかなりアドバンテージあるとは思うのですが……。証明書がExpireしそうになったときの更新など運用面が、これまでからまるっきり違ってくるので、普及するとどういう世界になるのか正直よく分かりません。

参考リンクとして以下を挙げておきます。Turing Complete FMは面白いのでメッチャおすすめ。

量子コンピュータ

詳しく無いので、jovi0608さんのこのツイートが面白いので貼って済ませます。

素因数分解ができるのでRSA暗号が崩れるというのは有名な話ですね。AESなど対象暗号で、充分bit数を上げれば大丈夫、というのは理解があやふやだったので助かりました。

その他

ごはん

おひるご飯は重要です。大学周辺の飲食店は日祝休みとなるため、靖国通りまで出て前から気になっていた「黄金の塩らぁ麺 ドゥエイタリアン」というラーメン屋に行きました。

f:id:ozuma:20190115001359j:plain

ラーメン屋ですが店内はイタリアン風で、生ハムにチーズたっぷり、オリーブオイル仕立てのラーメンでした。チーズ好きな人は大歓喜でしょうが、私は、なんというか、アレですな、ラーメンは横浜に限りますな。

信頼

最後にjovi0608さんが信頼(Trust)について強調されていたので、誤解される方が出ないよう少し書いておきます。

少なくとも現在、たとえEV証明書であっても、「信頼」はあくまで技術用語としての信頼(すなわち、ある証明書を、ルート認証局の証明書からのチェインでちゃんと検証できる)という意味以上は持ちません。これは誤解を招かないように、CA/Browser ForumのEV SSL Certificate Guidelinesでも、Section 2.1.3の"Excluded Purposes"で、「EV証明書で目的としないこと」という節をわざわざ設けて説明しています。

このSectionでは、EV証明書のSubjectへ以下の4つを保証することを、EV証明書では目的としていない(だから、誤解すんナよお前ら)」と明記されています。

  1. That the Subject named in the EV Certificate is actively engaged in doing business; (実際にビジネスを行っていること:つまり、フィッシング目的などペーパーカンパニーではないこと)
  2. That the Subject named in the EV Certificate complies with applicable laws; (法律に準拠していること)
  3. That the Subject named in the EV Certificate is trustworthy, honest, or reputable in its business dealings; (信頼できる公正な商取引を行っていること)
  4. That it is “safe” to do business with the Subject named in the EV Certificate. (ビジネスを行って「安全」な相手であること)

(4は1-3で内包される気もするので、ちょっとしつこいですね)

ペットボトル

学生さんへのメッセージですが、見ての通りみんな普通にペットボトル置いてガブガブ飲んでいます。変なマナー講師の言うことを真に受けるのはやめましょう。

終わりに

大変に楽しくエキサイティングなトークでした。聞きに行って良かったです。発表者の皆さま、ありがとうございました。

すみだセキュリティ勉強会2018その3を開催しました

また前から日が空いていまいましたが、すみだセキュリティ勉強会2018#3を開催しました。

私の発表は「Data Privacy Day - Googleを使わず1日過ごしてみる」です。

Chrome 69では、「google.comへのログイン」と「Chromeへのログイン」を曖昧にする変更が議論を呼びました。この話題に絡めてGoogleがどれだけ情報収集を行っているかの解説と、昨今のPrivacy重視のプロダクトの紹介として、DuckDuckGo, ProtonMail, brave browserあたりの紹介です。特にProtonMail, ProtonVPNは、FirefoxがProtonVPNを採用したこともあり、今後伸びていくプロダクトではと思っています。

Privacy重視のWebサービスは、当然のことながら行動ターゲティング広告を行うプロダクトに比べると、どうしても不利な情勢にあります(主に資金面で)。ということで、躊躇無く課金して応援して行きたいものです

また、発表いただいた@saiyuki1919さん、@morihi_socさん、そしてお越し頂いた皆様、ありがとうございました。

HTMLのid属性に日本語は使えるのか

先日、東京五輪ボランティア応募サイトを検証したら予想以上にヤバかった(語彙力)という記事を読んでいたところ、日本語をid属性に使うことが槍玉に挙げられていました。

しかし日本語だろうがギリシャ語だろうがASCII文字だろうが、Unicodeの1文字であることに変わりはありません。最近は多言語対応が十分に進んでおり、今さらASCII文字しかダメなんて時代遅れなこと本当にあるの? と思い少し調べました。

先に結論

id属性に日本語を使うことは何も問題ありません。

調べてみる

件のボランティアサイトは、HTML 5で記述されています。 f:id:ozuma:20181005115319p:plain ということで、W3CのサイトでHTML 5の仕様書を確認してみましょう。現在の最新版は、HTML 5.2です。

id属性

id属性は、DOMのところに記述があります。

ここでid属性の制限は以下のように定義されています。

When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element’s tree and must contain at least one character. The value must not contain any space characters.

つまり、

  • id属性は一意でなければならない
  • 最低1文字でなければならない
  • 空白文字を含んでいてはならない

以上が制限です。

さて、このような技術文書を読む際は、用語の定義に注意が必要です。ここでは無造作にcharacterという単語が使われていますが、この文書でのcharacterにはどういう制限があるのか、定義の確認が必要です。

HTML 5のcharacterとは

characterの定義は、「2.1.6. Character encodings」に書かれています。

In this specification, the term character, when not qualified as Unicode character, is synonymous with the term Unicode code point.

このように本仕様書では、"character"という用語は、(「Unicode文字」と書かれていない場合は)Unicodeコードポイントを意味すると書かれています。日本語には当然Unicodeコードポイントが割り当てられていますから、characterに該当します。よって、id属性に日本語を使うことは仕様上なんら問題ありません。

Ghostscript脆弱性とImageMagick/GraphicsMagick、そしてGoogle Project Zero

Ghostscriptの脆弱性が、Google Project ZeroのTavis Ormandy氏により公開されました(CVE番号はまだ無し)。openwallのoss-securityメーリングリストにもクロスポストされたので、こちらを見た方も多いでしょう。

基本的な情報は以下のJPCERTアナウンスから出ているので、ここではもうちっと細かいTopicsをいくつかまとめます。

概要

PostScriptは、単なるドキュメントファイルの一型式ではなく、描画コマンドなども利用できるプログラミング言語です。そのためGhostscriptには、-dSAFERという「キケンなこと」ができないようにするモードがあります。ところが、この-dSAFERを付けていても任意コード実行が可能な穴があった……というのが今回の脆弱性のキモです。

脆弱性のパッチは、開発元のArtifex Softwareから既に提供されています。正式な次バージョンのリリースは9月になるようです。

ただ、上記Project ZeroのTavis氏の発言によると、この修正は不十分であり、また現在Fuzzerを回しておりまだまだ見つかりそうだとのことから、さらなる追加修正が入りそうです。

ImageMagickも対象である

今回の脆弱性はGhostscriptの脆弱性ですが、ImageMagickもGhostscriptに依存しているため影響を受けます。そのためWebアプリでユーザに画像をアップロードしてもらう等、画像処理をImageMagickで行うプログラムではすべて対応が必要です。

実際、以下のようにImageMagickで細工したPSファイル(VU-332928.ps)を扱うとLinuxコマンドが実行されており、脆弱性の影響を受けることが分かります。
なお以下の例では、idコマンドを実行しているので、uid等が表示されています。もちろん、もっとヒドいこともできます。

$ convert VU-332928.ps test.png
uid=1000(ozuma) gid=1000(ozuma) groups=1000(ozuma),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
convert: `%s' (%d) "gs" -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 "-sDEVICE=pngalpha" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-r72x72" -g612x792  "-sOutputFile=/tmp/magick-GrMdTtj4--0000001" "-f/tmp/magick-4q5WILKb" "-f/tmp/magick-th3RM7bj" -c showpage @ error/utility.c/SystemCommand/1890.
convert: Postscript delegate failed `VU-332928.ps': そのようなファイルやディレクトリはありません @ error/ps.c/ReadPSImage/832.
convert: no images defined `test.png' @ error/convert.c/ConvertImageCommand/3046.
$ 

気をつけないといけないのは、この脆弱性はPSファイルを読み込んでパースした時点で発生するということです。具体的には、ImageMagickでconvertをしていなくても、identifyでファイルタイプ判別のみに利用していても、脆弱性の対象となります。下記でも、ファイルに仕込んだidコマンドが実行されてしまっています。

$ identify VU-332928.ps 
uid=1000(ozuma) gid=1000(ozuma) groups=1000(ozuma),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
identify: `%s' (%d) "gs" -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 "-sDEVICE=pngalpha" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-r72x72" -g612x792  "-sOutputFile=/tmp/magick-ItbgeaDQ--0000001" "-f/tmp/magick-59biIgLS" "-f/tmp/magick-KUgSVrTU" -c showpage @ error/utility.c/SystemCommand/1890.
identify: Postscript delegate failed `VU-332928.ps': そのようなファイルやディレクトリはありません @ error/ps.c/ReadPSImage/832.
$

また、例えばPythonのライブラリであるPythonMagickでは、Image()メソッドでファイルを読み込むだけで発動します。つまり以下のように、ファイルを読み込むだけで何もしないスクリプト脆弱性の影響を受けます。

#!/usr/bin/python

# coding=UTF-8
import PythonMagick
img = PythonMagick.Image("VU-332928.ps")
ozuma@ubuntu17:~$ ./vul.py VU-332928.ps 
uid=1000(ozuma) gid=1000(ozuma) groups=1000(ozuma),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),118(lpadmin),128(sambashare)
Error: /ioerror in --showpage--
Operand stack:
   --nostringval--   1   true
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   1874   1   4   %oparray_pop   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1215/1684(ro)(G)--   --dict:0/20(G)--   --dict:78/200(L)--   --dict:88/91(L)--
Current allocation mode is local
Last OS error: Broken pipe
GPL Ghostscript 9.21: Unrecoverable error, exit code 1
$

ImageMagickでの対策は、JPCERT等からアナウンスされている通り、policy.xmlで処理を禁止するファイルを指定することです。

具体的には、以下のようにPS/EPS/PDF/XPSを禁止することになります。ちなみにPS2PS3とは、PostScript Level 2とLevel 3です。

<policy domain="coder" rights="none" pattern="PS" />
<policy domain="coder" rights="none" pattern="PS2" />
<policy domain="coder" rights="none" pattern="PS3" />
<policy domain="coder" rights="none" pattern="EPS" />
<policy domain="coder" rights="none" pattern="PDF" />
<policy domain="coder" rights="none" pattern="XPS" />

GraphicsMagickでの対策

GraphicsMagickも内部でGhostscriptを利用しているため本脆弱性の影響を受けます。以下のように、identifyするだけでidコマンドが実行できてしまっています。convertも同様に脆弱性の影響を受けます。

$ ./gm identify VU-332928.ps 
uid=1000(ozuma) gid=1000(ozuma) groups=1000(ozuma),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
./gm identify: "gs" "-q" "-dBATCH" "-dSAFER" "-dMaxBitmap=50000000" "-dNOPAUSE" "-sDEVICE=pnmraw" "-dTextAlphaBits=4" "-dGraphicsAlphaBits=4" "-r72x72" "-g612x792" "-sOutputFile=/tmp/gm8OJn56" "--" "/tmp/gmBWNNro" "-c" "quit" (child process quit due to signal 13).
./gm identify: Postscript delegate failed (VU-332928.ps).
./gm identify: Request did not return an image.
$

さてImageMagickと対比されることで有名なGraphicsMagickですが、policy.xmlに除外ファイルを書けば済むImageMagickと違い、こちらの対策は厄介です。
なぜなら、GraphicsMagickには、ImageMagickのようなpolicy.xmlファイルによる除外機能が無く、除外ファイルを一括指定できないためです(この辺、素直にImageMagickの設計をパクればいいのに……ってみんな思ってる。たぶん)。

GraphicsMagickでは、代わりにdelegates.mgkというファイル修正で対策が行えます。これは、GraphicsMagickのメーリングリストで、メンテナのBob Friesenhahn氏も話題に挙げています。

具体的には、以下のパスにあるdelegates.mgkファイルを修正します。

lib/GraphicsMagick-X.X.XX/config/delegates.mgk
 (X.X.XXの部分はバージョン番号)

まずは現在の状態を確認するために、-listで見てみましょう。

$ ./gm convert -list delegate
Path: /home/ozuma/local/GraphicsMagick-1.3.30/lib/GraphicsMagick-1.3.30/config/delegates.mgk

Delegate             Command
-------------------------------------------------------------------------------
     cgm =>          "ralcgm" -d ps < "%i" > "%o" 2>/dev/null
   dcraw =>          "dcraw" -c -w "%i" > "%o"
     dot =>          "dot" -Tps "%i" -o "%o"
     dvi =>          "dvips" -q -o "%o" "%i"
     eps<=>pdf       "gs" -q -dBATCH -dSAFER -dMaxBitmap=50000000 -dNOPAUSE
                      -sDEVICE=pdfwrite "-sOutputFile=%o" -- "%i" -c quit
     eps<=>ps        "gs" -q -dBATCH -dSAFER -dMaxBitmap=50000000 -dNOPAUSE
                      -sDEVICE=ps2write "-sOutputFile=%o" -- "%i" -c quit
     fig =>          "fig2dev" -L ps "%i" "%o"
     hpg =>          "hp2xx" -q -m eps -f `basename "%o"` "%i" && /usr/bin/mv
                      -f `basename "%o"` "%o"
    hpgl =>          "hp2xx" -q -m eps -f `basename "%o"` "%i" && /usr/bin/mv
                      -f `basename "%o"` "%o"
     htm =>          "html2ps" -U -o "%o" "%i"
    html =>          "html2ps" -U -o "%o" "%i"
    ilbm =>          "ilbmtoppm" "%i" > "%o"
    mpeg =>          "mpeg2decode" -q -b "%i" -f -o3 "%u%%05d"; gm convert
                      -temporary "%u*.ppm" "miff:%o" ; rm -f "%u"*.ppm 
     pdf<=>eps       "gs" -q -dBATCH -dSAFER -dMaxBitmap=50000000 -dNOPAUSE
                      -sDEVICE=epswrite "-sOutputFile=%o" -- "%i" -c quit
     pdf<=>ps        "gs" -q -dBATCH -dSAFER -dMaxBitmap=50000000 -dNOPAUSE
                      -sDEVICE=ps2write "-sOutputFile=%o" -- "%i" -c quit
     pnm<= ilbm      "ppmtoilbm" -24if "%i" > "%o"
     pnm<= launch    "gimp" "%i"
     pnm<= win       "gm" display -immutable "%i"
      ps<=>eps       "gs" -q -dBATCH -dSAFER -dMaxBitmap=50000000 -dNOPAUSE
                      -sDEVICE=epswrite "-sOutputFile=%o" -- "%i" -c quit
      ps<=>pdf       "gs" -q -dBATCH -dSAFER -dMaxBitmap=50000000 -dNOPAUSE
                      -sDEVICE=pdfwrite "-sOutputFile=%o" -- "%i" -c quit
      ps<= print     "no -c -s" "%i"
   shtml =>          "html2ps" -U -o "%o" "%i"

このように、各形式に対して実行するコマンドテーブルが用意されています。ここから、Ghostscriptの実行コマンドである"gs"を含むものを全部消してやればいいわけです。

delegates.mgkの中から、以下のようにgsコマンドが使われている部分をすべて削除します。

...(省略)...
  <!-- Read monochrome Postscript, EPS, and PDF  -->
  <delegate decode="gs-mono" stealth="True" command='"gs" -q -dBATCH -dSAFER -dMaxBitmap=50000000 -dNOPAUSE -sDEVICE=pbmraw -dTextAlphaBits=%u -dGraphicsAlphaBits=%u -r%s %s "-sOutputFile=%s" -- "%s" -c quit' />

  <!-- Read grayscale Postscript, EPS, and PDF  -->
  <delegate decode="gs-gray" stealth="True" command='"gs" -q -dBATCH -dSAFER -dMaxBitmap=50000000 -dNOPAUSE -sDEVICE=pgmraw -dTextAlphaBits=%u -dGraphicsAlphaBits=%u -r%s %s "-sOutputFile=%s" -- "%s" -c quit' />

  <!-- Read colormapped Postscript, EPS, and PDF  -->
  <delegate decode="gs-palette" stealth="True" command='"gs" -q -dBATCH -dSAFER -dMaxBitmap=50000000 -dNOPAUSE -sDEVICE=pcx256 -dTextAlphaBits=%u -dGraphicsAlphaBits=%u -r%s %s "-sOutputFile=%s" -- "%s" -c quit' />
...(省略)...

修正できたら、もう一度gm convert -list delegateを実行して、gsコマンドが使われない状態であることを確認してください。
なお、これはImageMagickもそうですが、そもそもPS/EPS/PDF/XPSファイルが扱えなくなってしまう問題が発生しますので、サービスによっては多大な影響が発生する点に注意してください。

その他の対策としては、そもそもGhostscriptをアンインストールしてしまう、gsコマンドの実行権限を落としてしまう、などの荒技も一応考えられますね。

ファイル形式をチェックしてファイル入力時点でブロック

保険的対策として、画像処理をするプログラムに渡す前に、ファイル形式をチェックしてPS/EPS/PDF/XPSならばエラーとして弾く、というのも有効です。なお、別の入力経路があるかもしれないことと、ファイル形式を偽装する攻撃手法があるので、あくまで保険的対策です。

しかしこの際、どのようにファイル形式をチェックするかは注意が必要です。

まず、当然のことながら拡張子で判断してはいけません。拡張子を.jpgとした悪意のあるPSファイルをアップロードされたら、チェックをすり抜けて試合終了です。

じゃぁImageMagickのidentifyを利用して画像形式を判別して……と思いつきそうですが、冒頭に記載した通り本脆弱性はidentifyしただけで発動します。また、今後も出るであろうGhostscript+PSファイルの脆弱性も、PostScriptファイルの性質からして、おそらくidentifyするだけで発動します。

ではどうすればいいか……正攻法の一つには、WAF(Web Application Firewall)の利用が挙げられます。例えばSaaS型WAFのScutumは対応が早く、8月23日時点で対応していました。

一方、プログラマとして対応する場合は、例えばPythonには、mimetypesというモジュールがあり、このguess_type()メソッドを利用することでMIME Typeが判別できます。これで「application/postscript」等を叩き落とせばいいですね。(2018/08/27追記:mimetypesモジュールは、拡張子を見るだけなのでダメでした。ご指摘いただいた id:penult さん、ありがとうございます。)
一方、プログラマとして対応する場合は、fileコマンドを使ったり、magicファイル(ややこしいですが、ImageMagickとは関係なく、ファイルタイプ判別のmagicファイルのこと)を利用する言語ごとのファイル形式判別ライブラリを使うと良いでしょう。例えばPythonには、python-magicというモジュールがあります。

なお、このように特定のファイル形式を叩き落とす場合は、ブラックリスト型ではなくホワイトリスト型の設計とするのが基本です。例えば画像アップローダのサービスならば、はじめから受け付ける画像形式を決めて(例えばjpg/png/gifのみ等)、それ以外は全てエラーとする、とすべきです。意図しない画像形式がアップロードされた時の誤作動を防ぐことができます。

今回のゼロデイ公開について

Google Project Zeroは、いわゆる「90日ルール」を設定しています。これは、発見した脆弱性をベンダへ通知した後に90日のdeadlineを設定し、修正されない場合は強制的に脆弱性を公開するというものです。

実際にどう運用されているかは、チケットを見てみると分かりやすいかと思います。

上記ポストの最後に、以下の文があります。

This bug is subject to a 90 day disclosure deadline. After 90 days elapse or a patch has been made broadly available, the bug report will become visible to the public.

さて今回、Ghostscriptを開発しているArtifex Software社は、Google Project Zeroから報告を受けたけど90日以内に直せなかったのでしょうか? これは事実関係がどこにも書かれていないので推測でしかありませんが、「そもそも報告を受けていない」と捉えるのが自然です。

Artifex Software社は現在既にパッチをリリースしていますが、そのアナウンスの最後に以下のような文章を掲示しています。

Artifex takes security issues very seriously and strongly encourages responsible and coordinated disclosure of vulnerabilities. Developers should be given the opportunity to fix security problems in advance of public disclosure.

(意訳)Artifex Softwareは、セキュリティ情報を非常に重要なものとして取り扱っています。頼むからいきなりZero-Day公開しないで、ちゃんと猶予をくれ。

https://artifex.com/news/ghostscript-security-resolved/

さて、今回のゼロデイ公開は、Google Project Zeroの以下のポストです。

こちらの"Reported"は、2018-08-21になっています。うーん、90日ルールはどこへ行ってしまったのでしょうか。

Google Project Zeroは、マネージャーのParisa Tabriz氏が先日のBlack Hat USA 2018でKeyNoteを努めました。セキュリティに対する熱い思いを語り、Google Project Zeroの理念を語っていた姿に感動した私は、正直「むむむ?」というフクザツな気分です。

脆弱性を事前通知したのかどうか、はっきりしないため誤解があったらすみません。

(何かあれば加筆する)