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

No.10074

fzok4234 さん　23/02/08 12:00　[ コメントを投稿する ]

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

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

[ △ ]

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

No.10075

秀丸担当 さん　23/02/08 16:27　[ コメントを投稿する ]

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

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

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

[ △ ]

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

No.10076

fzok4234 さん　23/02/09 07:27　[ コメントを投稿する ]

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

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

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

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

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

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

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

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

[ △ ]

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

No.10077

でるもんたいいじま さん　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の書式を誤った場合どうなる

No.10078

秀丸担当 さん　23/02/09 12:13　[ コメントを投稿する ]

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

[ △ ]

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

No.10079

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

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

[ △ ]

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

No.10080

秀丸担当 さん　23/02/09 16:19　[ コメントを投稿する ]

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

[ △ ]

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

No.10081

fzok4234 さん　23/02/09 16:32　[ コメントを投稿する ]

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

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

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

[ △ ]

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

No.10082

fzok4234 さん　23/02/09 16:49　[ コメントを投稿する ]

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

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

[ △ ]

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

No.10083

でるもんたいいじま さん　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にシェアを奪われましたし、OpenSSLも最近ver3.0が出ましたし、ISC BINDにも既に対抗馬が存在します。

☆　☆　☆

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

[ △ ]

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

No.10084

でるもんたいいじま さん　23/02/09 21:52　[ コメントを投稿する ]

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

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

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

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

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

☆　☆　☆

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

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

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

[ △ ]

[ 新規に投稿する ]