もしExConfig2の書式を誤った場合どうなる - 秀丸エディタマクロ作者会議室 - スレッド10074, 2023/02/08

もしExConfig2の書式を誤った場合どうなる

fzok4234 さん　23/02/08 12:00

さて、「ファイルタイプ別の設定」の一部の項目に対応するレジストリ上の ExConfi
g2 値について
ですが、マクロ等からこれを編集する際に誤って無効な値を書き込んでしまった場合、
秀丸エディタが
保護違反などで強制終了して該当のタイプのファイルを開けなくなってしまう危険性
はあるのでしょうか?

特にスペルチェックの色は
https://www.maruo.co.jp/hidesoft/4/x09930_.html#9935
にあるように変則的な値を書き込む必要があり、ユーザーがマクロ上でのこの値の導
出ロジックの
実装を誤る可能性が大きいと思われます。

RE:10074 もしExConfig2の書式を誤った場

秀丸担当 さん　23/02/08 16:27

バイナリ情報を誤った形で書き換えると、何がおこるかわからないので、非常に危険
です。
最近いろいろJSON化している部分がありますが、以前にご提案いただいたように、フ
ァイルタイプ別の設定などもJSONでできたらいいです。
ただ強調表示直接指定モードように起動時に直接読み込む設定としてあると、既にレ
ジストリや、持ち出しキットのiniファイルもあって、さらにJSONとなると大変です。
起動時じゃないときも含めると、設定ファイル用の.hmeregの形式もあります。

colormarker文を"{..."から始まる書き方にするとJSONでまとめて書けますが、これ
と同じような感じでマクロからの操作用にconfig文でconfig "{..."みたいに書けた
らいいかもしれないと思っています。
（互換性に問題があったらconfigjsonとかにするかもしれないですが）

JSON直接だと一気に切り替えて移行とか大変ですが、config文JSONだったらとりあえ
ずconfig文で書き換え可能な部分＋スペルチェックとか、部分的に実装していくこと
ができるのでやりやすそうです。

RE:10075 もしExConfig2の書式を誤った場

fzok4234 さん　23/02/09 07:27

回答ありがとうございます。

> バイナリ情報を誤った形で書き換えると、何がおこるかわからないので、非常に危
>険です。

とのことですが、このバイナリ値の解釈の際に値の範囲が有効であるかどうかの最低
限のチェックを
ちゃんと行った上での、「レジストリを書き換えたユーザーの意図しない動作になる
危険性」という
意味でよろしいでしょうか? 即ち、例えばスペルミスの波下線の色の 4 byte の値が
#RRGGBB の範囲を
超えていたら、
　・デフォルト値の #000000 に置き換えて処理を続行する。
　・エラーメッセージを出して処理を中止する。
　・例外を throw して保護違反扱いにする。
といった安全策をちゃんと講じた上でのユーザーの意に反した動作になる、というこ
とでしょうか?

それとも、このような安全策すら一切行わずに値をいきなり実行ロジックに流し込ん
でいるために、本当に
秀丸エディタが暴走してしまう危険性があるのでしょうか? もしその場合なら、最悪
のケースとして攻撃者が
レジストリのバイナリ値に任意の実行コードを書き込んで、バッファーオーバーフ
ローを起こさせてこれを
実行させることも可能なのでしょうか?

もし後者に該当しているならば、速やかに何らかの対策をお願い申し上げたいところ
です。尤も、根本的な
問題解決の方法は設定の保存形式をバイナリ値から JSON などのより安全な形式に移
行することですが、

> ただ強調表示直接指定モードように起動時に直接読み込む設定としてあると、既に
>レジストリや、
> 持ち出しキットのiniファイルもあって、さらにJSONとなると大変です。
> JSON直接だと一気に切り替えて移行とか大変ですが、

とおっしゃられているように、アップデートの際の互換性維持のために移行作業が大
変なものとなるため、
当面はバイナリ値への保存を継続することになります。しかしその場合、もしバイナ
リ値の解釈時の
安全性確保全く行っていないならば危険な状態が継続するため、速やか対策を講ずる
必要があります。

仮に、上記のバッファーオーバーフロー攻撃が可能だったならば重大な脆弱性であり、
いつでも
秀丸エディタを悪用する攻撃が発生しうる状態です。また、全く攻撃の兆しが無いと
きでも
IPA などの公的機関やトレンドマイクロなどのセキュリティアプリのベンダーから秀
丸エディタの
使用中止の勧告が出される可能性もあります。

RE:10076 もしExConfig2の書式を誤った場

でるもんたいいじま さん　23/02/09 09:09

でるもんた・いいじまです。

> > バイナリ情報を誤った形で書き換えると、
> > 何がおこるかわからないので、非常に危険です。
>
> とのことですが、このバイナリ値の解釈の際に
> 値の範囲が有効であるかどうかの最低限のチェックを
> ちゃんと行った上での、「レジストリを書き換えたユーザーの
> 意図しない動作になる危険性」という意味でよろしいでしょうか?

いちいち質問する前に、安全な場所で試してみればいいのですよ。

一例。
HKEY_CURRENT_USER\SOFTWARE\Hidemaruo\Hidemaru\Default
というキーの中に「Tab」というDWORD値があって、私の場合は通常、ここは8になっ
ています。

秀丸を全終了して、常駐秀丸も終了して、それからここの値を0xFFFFFFFF、つまり-1
に書き換えます。
それから秀丸を起動して、タブキーを打ってみたら、1回打つごとにタブではなく、
スペースが1個入力されました。
0xFFFFFFFC（＝-4）でも同様に試してみると、タブを打った際にスペースが4個入力
されました。

ここまでの実験で、どうやら内部的には「タブキーでスペースn個を打つ」という設
定を -n で表現しているらしい、ということが容易に推測できます。

では、ここに 0x80000000、つまり-2^31を入れたらどうなるか。
当方の環境では、タブキーを数回打ったら秀丸が落ちました。

ここまでの情報を踏まえると、「32bit版ではなく64bit版の秀丸で同じ実験をしたら、
0x80000000の場合に別の結果が出るのでは？」という予想も当然つきます。

というわけで、ExCofig2 についても「推して知るべし」と私は判断します。

ただ、例示された「色データ」の場合、単純にRGB値だけ存在可能な仕様にするなら
残りの8bitを0でマスクすればいいだけのことですし、あるいは、秀丸の場合は当該
の余剰バイトを00から01や02に変えると特別な意味を持つことになっていますから、
少なくともそこについては大丈夫なはずです。

☆　☆　☆

> 根本的な問題解決の方法は設定の保存形式をバイナリ値から
> JSON などのより安全な形式に移行することですが、

確かに安全ですが、それをやると処理が数十倍、あるいは数百倍以上遅くなりますよ？
今の我々が「遅いと言ってもたかが知れている」と言い切れるのは、CPUの性能がほ
ぼ理論限界近くまで上がっていて、かつ、処理すべき設定データの量がそれに比べて
ごくわずかだからです。
どんな環境でもテキストデータ化が完全無敵、というわけでは決してない、というこ
とは忘れないでいただきたいです。

どんなアプリでも事情は同じで、特に「処理の途中経過」をファイルにそのまま書き
出すということは頻繁に行われています。そのデータを再利用する際にいちいち厳密
なバリデーションが強制されるのであれば、いっそのこと再利用せずに最初からやり
直したほうがよっぽど効率的、ということになります。

もちろん、プロセッサのハードウェアレベルでそういうセキュリティ機能を持たせる、
という話は既にいろんなところで研究が進んでいることでしょう。

☆　☆　☆

> 仮に、上記のバッファーオーバーフロー攻撃が可能だったならば
> 重大な脆弱性であり、いつでも秀丸エディタを悪用する攻撃が
> 発生しうる状態です。

そもそも私なら、秀丸をターゲットにした攻撃は計画しません。
日本に数億台あるWindowsマシンの中で、秀丸がインストールされている環境は数百
万かせいぜい1000万、2000万程度でしょうし、全世界で数十億あるWindowsマシン全
体の中では極めて小さな割合です。そして当然ながら、国内のマシンを直接狙ったら
すぐに足がつきます。海外のマシンを何重にも踏み台にする、という戦略を考えると
現実的ではありません。

それにそもそもの大前提として、特定のユーザーのHKCU内にある秀丸のExConfig2を
書き換えられるということは、
「そのユーザーのHKCU全体を自由に書き換えられる」
「ExConfig2に投入したいデータをファイルシステムに送り込める」
ということを意味します。

とすれば、わざわざ秀丸を狙わなくとも、
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
あたりを書き換えるのが手っ取り早いでしょう。
Windows10にはデフォルトでcurl.exeがありますから、これを使って（もちろん他の
方法でも可能です）自作のバイナリをどこかのサーバーからダウンロードさせて実行
すれば、管理者権限の確認が不要な作業はいくらでもやり放題です。

ついでにいうと、秀丸はマクロでレジストリを直接書き換えることもできますし、マ
クロから任意の実行ファイルを起動することもできますので、そちらが想定している
ような方法でのセキュリティを実現するには「マクロの完全排除」が絶対条件になり
ます。現にMicrosoft Officeではそれに近いことを既に行っていますが、果たして秀
丸でも同じ方法が可能でしょうか？

☆　☆　☆

なので結局、

> 全く攻撃の兆しが無いときでも
> IPA などの公的機関やトレンドマイクロなどの
> セキュリティアプリのベンダーから秀丸エディタの
> 使用中止の勧告が出される可能性もあります。

という心配は全くの杞憂と考えます。

例えていうなら、
「玄関が施錠されていない」
「金庫も施錠されていない」
という状態の金庫は空き巣の餌食になる、という事実のみを根拠として
「その型式の金庫は危ない、使ってはいけない」
という主張を繰り広げるのと全く同じロジックのように私には思えます。

RE:10077 もしExConfig2の書式を誤った場

秀丸担当 さん　23/02/09 12:13

だいたいでるもんたいいじまさんの言われる通りだと思います。
Tabは確かにおかしかったです。ご指摘ありがとうございます。
修正させていただきます。
チェックするのはいろいろなケースがあると思います。
設定ダイアログで決定するときのチェックだったり、マクロで操作するときのチェッ
クだったりなどもあります。
文字列は特に注意してます。
JSONにしたら安定性は増すと思いますが、１つ１つについてもしチェック漏れがある
としたら、JSONで大丈夫になるとも言えず、おかしいものはやっぱりおかしい結果に
なる可能性はあると思います。

RE:10077 もしExConfig2の書式を誤った場

fzok4234 さん　23/02/09 15:32

> 確かに安全ですが、それをやると処理が数十倍、あるいは数百倍以上遅くなります
>よ？
> 今の我々が「遅いと言ってもたかが知れている」と言い切れるのは、CPUの性能がほぼ
> 理論限界近くまで上がっていて、かつ、処理すべき設定データの量がそれに比べて
>ごく
> わずかだからです。
> どんな環境でもテキストデータ化が完全無敵、というわけでは決してない、という
>こと
> は忘れないでいただきたいです。

確かに、環境設定を読み込むときにテキストデータよりも整数や byte 配列等の生の
バイナリデータの方が、文字列解析のオーバーヘッドが無いので高速になります。だ
が、
その処理速度を気にする必要がある場面はほとんど無いように思えます。というのは、
秀丸エディタが環境設定を読み込むのは起動時や動作環境等の設定ダイアログを開く
とき
位で、四六時中レジストリを読み続けているわけではないと考えられるからです。よ
って、
多少読み書きのオーバーヘッドが増えても環境設定の保存方法を見直す価値は充分あ
ると
みられます。

> どんなアプリでも事情は同じで、特に「処理の途中経過」をファイルにそのまま書
>き出すと
> いうことは頻繁に行われています。そのデータを再利用する際にいちいち厳密なバ
>リデーションが
> 強制されるのであれば、いっそのこと再利用せずに最初からやり直したほうがよっ
>ぽど効率的、
> ということになります。

もし、レジストリ値が「処理の途中経過」であるならば、ユーザーはそれをみだりに
書き換えては
ならないということになります。この場合、レジストリの直接編集は秀丸担当から明
示的に
禁止されるかサポート対象外の行為として扱われるはずです。

しかし実際には、
https://www.maruo.co.jp/hidesoft/4/x09930_.html#9935
の対応に見られるように、レジストリの直接入力は公式に認められているとみられま
す。

そうであれば、ユーザーが直接入力したレジストリ値も設定ダイアログからの入力や
マクロ関数の
引数と同列の扱いとなるため、無効な値を排除するバリデーションはきちんと行われ
るべきと
考えられます。

> とすれば、わざわざ秀丸を狙わなくとも、
> HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
> あたりを書き換えるのが手っ取り早いでしょう。
> Windows10にはデフォルトでcurl.exeがありますから、これを使って（もちろん他
>の方法でも可能です）
> 自作のバイナリをどこかのサーバーからダウンロードさせて実行すれば、管理者権
>限の確認が
> 不要な作業はいくらでもやり放題です。
>
> ついでにいうと、秀丸はマクロでレジストリを直接書き換えることもできますし、
>マクロから
> 任意の実行ファイルを起動することもできますので、そちらが想定しているような
>方法での
> セキュリティを実現するには「マクロの完全排除」が絶対条件になります。現にMi
>crosoft Officeでは
> それに近いことを既に行っていますが、果たして秀丸でも同じ方法が可能でしょう
>か？

Run キーに書かれた不正なコマンドラインや不正な秀丸マクロなら、比較的容易に発
見できるため、
ユーザー自身での対処やセキュリティアプリでのブロックを行いやすく、それほど大
きな問題では
ないでしょう。一方、REG_BINARY値に実行コードを埋め込んでバッファーオーバーフ
ローで
実行させるようなケースでは、事前発見が困難なため、大きな問題となります。

RE:10079 もしExConfig2の書式を誤った場

秀丸担当 さん　23/02/09 16:19

レジストリの書き換えについては、ずっと昔のヘルプから独自に調べてenvchangedし
てくださいとか書いてるくらいなので、あまり大それたことは言えないのですが、サ
ポート対象外と思ってもらったほうがいいです。
もしあいまいな状態がだめということであれば、サポート対象外なので書き換えるの
はやめてくださいということになります。

RE:10078 もしExConfig2の書式を誤った場

fzok4234 さん　23/02/09 16:32

> チェックするのはいろいろなケースがあると思います。
> 設定ダイアログで決定するときのチェックだったり、マクロで操作するときの
> チェックだったりなどもあります。
> 文字列は特に注意してます。
> JSONにしたら安定性は増すと思いますが、１つ１つについてもしチェック漏れが
> あるとしたら、JSONで大丈夫になるとも言えず、おかしいものはやっぱり
> おかしい結果になる可能性はあると思います。

現行のレジストリ値の扱いの時点で、読み込み時のバリデーションを行っている
場合とそうでない場合とが混在しているとみられますが、ユーザーが両者を
区別出来るようにした上で、バリデーションが行なわれていない危険な項目に
ついては、ユーザーによる直接編集はサポート対象外とする代わりに、 config 文等で
必ず設定可能にする、というように運用方針を変えたほうが良いと思いますが、
どうでしょうか。

そもそも現時点において、config などで設定出来ない項目を直接レジストリ操作で
対処する行為自体、公式に認められたことなのでしょうか?

RE:10080 もしExConfig2の書式を誤った場

fzok4234 さん　23/02/09 16:49

>レジストリの書き換えについては、ずっと昔のヘルプから独自に調べてenvchanged
>してくださいとか書いてるくらいなので、あまり大それたことは言えないのですが、
>サポート対象外と思ってもらったほうがいいです。
>もしあいまいな状態がだめということであれば、サポート対象外なので書き換える
>のはやめてくださいということになります。

行き違いになったようですが、承知いたしました。ただ、config での JSON 指定が
実現することを願うのみです。

RE:10079 もしExConfig2の書式を誤った場

でるもんたいいじま さん　23/02/09 20:58

でるもんた・いいじまです。

前回 hidesoft.4:10077 の時は少々急いでいたので、荒っぽい表現があったかもしれ
ません。
それについてはここでお詫びします。

で、また長くなりそうですが…

☆　☆　☆

> 確かに、環境設定を読み込むときにテキストデータよりも整数や byte 配列等の生の
> バイナリデータの方が、文字列解析のオーバーヘッドが無いので高速になります。
>だが、
> その処理速度を気にする必要がある場面はほとんど無いように思えます。というの
>は、
> 秀丸エディタが環境設定を読み込むのは起動時や動作環境等の設定ダイアログを開
>くとき
> 位で、四六時中レジストリを読み続けているわけではないと考えられるからです。
>よって、
> 多少読み書きのオーバーヘッドが増えても環境設定の保存方法を見直す価値は充分
>あると
> みられます。

確かにこれも正論だとは思います。
レジストリよりもテキストファイルのほうが、fzok4234さんの懸念しておられるバイ
ナリコード・インジェクションのリスクが圧倒的に低いというのは確かです。
（シェルコマンド・インジェクションはどうだろ…Windowsの場合は元々あまり心配
が要らないかな？）

「処理速度を気にする必要がある場面はほとんど無い」特にこの点には100%同意しま
す。

---- ここからしばらく、細かい各論が続きます。急ぎの方は飛ばしてください。 ----

次に、実際に他のエディタを見てみると、たとえばvimはテキストファイルに設定を
記入します。Emacsに至っては、「特定の名前のマクロプログラムを起動時に自動で
実行する設計になっているので、個人設定はすべてそのマクロの中に書いてくれ」と
いう方針で既に何十年もの（もしかして昭和の昔からの？）歴史があります。

一方でテキスト形式の場合の懸念点として、
①そのテキストを記録したファイルは、どこのフォルダに、何という名前で保管する
のか？
②設定ファイルの存在が素人ユーザーにも丸見えだけど、知らずに削除したり破壊し
たりするリスクはないのか？
という点がまず最初に思い浮かびます。実際、UNIX系OSの世界では、このあたりに起
因するトラブルは日常茶飯事です。

ただしこの2点については、「Windows(XP以降)＋秀丸」に限った場合には、次のよう
にすんなり解決するはずです。

①%APPDATA%\Hidemaruo\Hidemaru\config.general.json あたりが順当。
※実際すでに、秀丸パブリッシャーで使用するテンプレートは %APPDATA%\Hidemaruo
\HMPV\ に配置されています。今のところレジストリにも色々と情報が入っていますが。

②%USERPROFILE%\AppData フォルダにはデフォルトで隠し属性がついており、それな
りに知識のあるユーザーが意図的に「隠しand/orシステム属性のついたファイル・フ
ォルダも見えるような各種操作」をしない限り、心配はないと考えられます。

☆　☆　☆

その次の問題点は、もし「ユーザー自身の手作業で、あるいは第三者作成のスクリプ
ト等で、設定ファイルを書き換える」という運用を想定するのなら、「万一、文法違
反等でデータが読み込めず、それによってエディタが起動不能になった場合に、その
状況からどうやって正常動作に復旧させるのか？」を事前に考えておく必要があると
いう点です。

このリスクへの一般解は、私の知る限りでは3つです。
①特定のコマンドラインオプションつきでアプリを起動した場合は、設定ファイルを
無視して強制的にデフォルト設定で動作する、という機能を組み込んでおく。（例：
emacs -q）
②別のエディタ、特にOS標準搭載のエディタを使って手作業で復旧する。（UNIXなら
vi、Windowsならメモ帳。）
③使えなくなった設定ファイルを一旦リネームし、新たに作り直してから、壊れてい
ない情報だけを抜き取って新しいファイルに反映させる。
…残念ながらどれも、超のつく初心者ユーザーに実行させるのは無理です。

ちなみに、
④何も考えず、壊れた設定ファイルを削除すれば元通りになるはず。
という考えも出てきますが、これすら、%APPDATA% は隠しフォルダであってユーザー
が日常的に操作する場所ではない、という前提と矛盾します。

この制約を抱えたまま、fzok4234さんの最終目標である「自分自身でありとあらゆる
設定を自由にいじりたい」という御希望を無条件で実装してしまうとなると、大多数
の初心者ユーザーさんに無用なトラブルを抱えさせることになります。

それを回避しようとして
⑤アプリやその設定の破損を診断・復旧するための専用アプリを別途用意する。
とするのであれば、そもそも現状の方式、すなわちレジストリ上のバイナリデータは
テキスト形式よりも容易に修正できるはずであり、元々の「テキスト化の意義」が根
底から失われることになります。

---- 細かい各論は一旦ここまで。本筋に戻ります。----

> レジストリの直接編集は秀丸担当から明示的に
> 禁止されるかサポート対象外の行為として扱われるはずです。
>
> しかし実際には、
> https://www.maruo.co.jp/hidesoft/4/x09930_.html#9935
> の対応に見られるように、レジストリの直接入力は公式に認められているとみられ
>ます。

既に hidesoft.4:10080 で担当さんから公式見解が出ていますが、現状は次の通りと
考えてます。

①原則として、レジストリの直接編集はサポート対象外である。将来もし仕様変更が
必要になった場合には、サイトー企画さんの一存によっていつでも非互換・不可逆な
変更が発生しうる。

②現状で、レジストリ直接編集以外の代替手段が存在しないケースは確かに多々ある。
かといって、そのような代替手段の追加実装作業を無制限かつ完全無償で引き受ける
ことは、ユーザー層の分布を考えると経済合理性に適合しない。
その一方で、上級ユーザーのニーズも極力、汲み上げたい。
よって、ある程度の情報提供だけはするが、レジストリの直接編集は「黙認」「ユー
ザーの自己責任」という形で妥協したい。

③そのような事情なので、レジストリの編集は「中のカラクリと、万一の場合の復旧
手順。この2つを両方ともきちんと理解しているユーザー」でなければ手を出すべき
でない。

＃日本語だとどういう表現が定番なんだろう…英語の
＃定型句を借りるなら「strongly discouraged であり、
＃当然 should not でもあるが、決して prohibited では
＃ない」という状況です。

この3箇条は何も秀丸に限った話ではなく、Windows本体や標準アプリの挙動を変更す
るためのレジストリ変更についても、全く同様の運用です。
この一点のみを槍玉に挙げてMicrosoftを叩く論客は、少なくとも私の知る限り、ど
こにもいません。
（そもそも、この運用が気に障るような人は「Windowsなんて使うな」と断言しますw）

---- また細かい各論に入ります。----

> Run キーに書かれた不正なコマンドラインや不正な秀丸マクロなら、
> 比較的容易に発見できるため、ユーザー自身での対処やセキュリティ
> アプリでのブロックを行いやすく、それほど大きな問題では
> ないでしょう。

どうでしょう。Run キーを狙うのは攻撃方法としては一番単純ですが、実際問題、そ
の部分すらノーガードになっているマシンは世界中に山ほどあります。少なくとも数
億台という単位で。

また、Run キーに関しては「安全」と「自由」が常にトレードオフになります。
針を「安全」側に完全に振り切る例としては、たとえば企業や官公庁などで重要機密
（特に軍事機密）を扱うマシンであれば、グループポリシーか何かで「そもそも個人
別のRunキーは全面的に無効化する」という設定が行われるでしょう。

＃ちなみに、「特定のWindowsアプリが必要だけど、
＃WindowsOS自体は必要ない」という状況なら、
＃Wineなども選択肢に上がります。
＃その話はさすがに今回の本論から外れるので、
＃ここでは省きます。

一方、Windowsマシンの大半は「自分のマシンの管理者は自分自身」という状態のは
ずです。
だとすると、自作のスクリプトをRunキーに投入したいという需要は当然あるでしょう。
セキュリティアプリがどんなに進化しても、悪意の「ある」スクリプトと悪意の「な
い」スクリプトとの判別を「一切のfalse positiveも、一切のfalse negativeもなく、
完璧に」行うことは原理的に不可能です。

それと、秀丸マクロに関しては少なくとも、「日本市場と縁がないセキュリティアプ
リ」によるマルウェア検知は期待できません。
そういう状況の開発チームが「ヒューリスティクスによるマルウェア検知」を安易に
発動すると、false positiveだらけで使い物にならなくなるはずです。

---- 各論ここまで。----

> 一方、REG_BINARY値に実行コードを埋め込んでバッファーオーバーフローで
> 実行させるようなケースでは、事前発見が困難なため、大きな問題となります。

うーむ。確かに事前発見は困難ですが…そもそも「どんな素性の攻撃者が」「どんな
相手をターゲットにして」「どんな成果を上げる目的で」「どんな手口による攻撃
を」仕掛けるシナリオのもとで、秀丸の設定情報が「いちばん最初の攻撃目標」にな
りうるのでしょうか。

前回の投稿でも指摘しましたが、もし、アタッカーがターゲット側の秀丸の設定を攻
撃できる状況であれば、そもそもそのターゲットのHKCU全部が既に丸裸になっている
はずです。
とすれば、秀丸を狙うよりも遥かに効率的な、そして遥かに確実な攻撃方法がいくら
でもあります。
丹念に探せば、他のアプリの脆弱性だって大量に見つかるでしょう。

もうひとつ、仮にバッファー・オーバーフローが生じうるとしても、「ユーザー本人
がランダムノイズをうっかり混入させる」という行為によっては決して、「どこの誰
だか知らないけれど、誰もがみんな知っている」ような特定の第三者にマシンを乗っ
取られることはありません。
問題の「第三者」が意図的に設計したバイト列を正確な並び順で、かつ、バイナリ
データの特定の範囲内の場所のみに、投入することによってはじめて成立します。

…ではそもそも、誰がどんな方法を使えば、ターゲットのHKCUを丸裸にできて、それ
なのに、もっと劇的に強力な攻撃手段は使えない、そういう状況になるのでしょうか？
たとえばもし、「ターゲットのマシンを直接触ってマルウェアを仕込む」という方法
が可能ならば、大抵の場合は管理者権限での作業が可能なはずです。
その状況なら極端な話、「USBメモリやCD-Rあたりをターゲット機にマウントして、
あとは何回かマウスをクリックするだけ」という簡単な操作で、何でもできるバック
ドアの設置が完了します。
そのあと「今までのログの消去＆今後のログ取得停止」まで実行してしまえば、被害
発覚時には既に、ほぼ全てが手遅れになっているはずです。

☆　☆　☆

さて。

fzok4234さんの今回の主張は、上記のような「前提条件や想定シナリオを整理する」
という議論を完全にすっ飛ばしたまま、一般論という形で「少々といえども危険は確
かに存在するのだから、徹底的に厳戒態勢を敷け」と闇雲に叫んでいるように思えま
す。

たとえば、現実の生活でこの一般論を杓子定規に適用するのなら、恐らくこうなるで
しょう：
自家用車もバスも電車もすべて、死亡事故の実例が多数存在するからダメ。
徒歩移動でも暴走車に跳ねられる危険がある。よってこれも厳禁。
→結論として、自宅から一歩も出てはならない。
でも、近所の火事が飛び火したり、大洪水が襲ってきたりしたら、どうする？
無差別殺人犯が大型の凶器を持ったまま突然押しかけてきたら、どうする？
飛行機がたまたま自宅めがけて墜落・炎上する可能性も「完全にゼロ」ではないよね？

…ここでもやはり「経済合理性」を判断材料の一つとして採用できるかどうかが重要
なキーポイントになってきます、

☆　☆　☆

最後にいくつか。

バッファー・オーバーフローにつながるようなセキュリティホールは、おそらく高い
確率で秀丸の中に現存しているでしょう。
ただし通常は、ユーザーから「誤った値を投入してしまって、かくかくしかじかの不
具合が起きました」という報告が上がれば即座に、ピンポイントでその部分への修正
が入ります。
実際、私が今朝テストした「Tab」の問題点も既にソースコード上では修正済みとの
ことですので、次のベータ版（順当にいけば9.20β15）からは不具合が再現しなくな
るはずです。

また、過去には担当さんが「調べてみたら少々ヤバいバグでした」と吐露したことが
ありました。そういうバグの中にはもしかしたら、セキュリティがらみのものが存在
していたのかもしれませんが、現在までの約20年間、少なくともJPCERT/CC経由では、
秀丸に関して何らかの情報が流れたという記憶はありません。
ちなみに、もしそういうセキュリティホールが大々的に発覚した場合、「開発元が状
況を把握→修正済のバージョンをリリース→次の定例ニュースでバージョンアップ勧
告を発出」となるのが他社での通例です。サポートが続いている限り、基本的には使
用中止勧告は出ません。

それと、現時点でセキュリティホールを徹底的に洗い出そうと思えば、全く方法がな
いわけではありません。
具体的には、まずは秀丸インストール済のWindows仮想環境を用意して、それを大量
に複製する。
それと前後して、攻撃コード、および、それをレジストリに注入するプログラムを用
意する。
それぞれの仮想環境上で当該プログラムを繰り返し実行し、ありとあらゆる場所に
コードを総当たりで投入して検証する。多数の仮想環境で検査範囲を分担し、同時並
行で動かす。
そういう徹底的な検証をすればたぶん見つかるでしょう。

…でも、秀丸のような「現在進行形で開発中」かつ「ミッションクリティカルではな
い」アプリについて現行バージョンでのテストをしたところで、どれだけの意味があ
るのかは疑問です。
そもそも攻撃を受けるリスクがどれだけあるのか、仮に穴をぜんぶ塞いだとしても見
落としの可能性はないのか、今は大丈夫でも将来どこかにエンバグする可能性を完全
に否定できるのか。
そして、この検査を実施するためのコスト（マシンの調達費用、OS等のライセンス、
電気代、人件費、その他もろもろ）はどれだけ必要か。

※ちなみに、もし「調べてみたらありとあらゆるところが穴だらけで、到底論外」と
いう結論に至った場合は、「スクラッチからコードを書き直す」という結果になるこ
ともあります。有名どころでは、sendmailは他のMTAにシェアを奪われましたし、Ope
nSSLも最近ver3.0が出ましたし、ISC BINDにも既に対抗馬が存在します。

☆　☆　☆

うーむ。予想はしていたけどやはり長くなりすぎた。
一旦ここで。

RE:10081 もしExConfig2の書式を誤った場

でるもんたいいじま さん　23/02/09 21:52

でるもんた・いいじまです。

> 現行のレジストリ値の扱いの時点で、読み込み時のバリデーションを行っている
> 場合とそうでない場合とが混在しているとみられますが、ユーザーが両者を
> 区別出来るようにした上で、

ちょっとこれは無理筋かな、と思います。
少なくとも、サイトー企画さんに「今すぐ全部、タダでやるのが当然でしょ？」と言
えるような簡単な作業とは、到底言えません。

このミッションのためには、「一つ一つの項目すべてについて」「想定される全パ
ターンのイレギュラー値を投入して」「秀丸の起動、当該部分の動作確認、プロセス
終了」「少しでも想定外の結果が出ればソースコードを総ざらいして追跡」「問題が
特定できたら修正して、必要に応じて再コンパイル」をひたすら繰り返すわけで、ざ
っくりまとめて次のような性質を全て兼ね備えたものになります。
　　・作業量と所要時間が途轍もなく膨大
　　・内容のほとんどは単純作業の繰り返し
　　・細部まで見落としの許されない精密作業

こういう悪条件満載の仕事は、私なら1億円積まれても断ります。
（5億、10億、あるいはそれ以上を積まれても、
　今度は別のリスクが生じるので結局断ります^^）

☆　☆　☆

その一方で、この検証作業を
「サイトー企画さんではなく、fzok4234さんの手弁当で」
「期限は特に設けず、スキマ時間で可能な範囲で」
実行することは十分に可能なはずです。

…挑戦してみるおつもりはありませんか？

一方的に質問と要求だけを繰り返すよりも、ご自分の手で事実を一つ一つ発掘してい
くほうがよっぽど生産的だと思うのですが、いかがでしょう？