今回も恥ずかしい記録です。
結論だけ先に書きますと、2025/9/24現在、ソースコードでは問題は解決しています。
ただし、0.9.4より新しい版はバイナリでは配布されていないため、LibreHardwareMonitorのソースコードからビルドする必要があります。
結論は以上です。
以下は恥の記録です。
さて、LibreHardwareMonitorさんとWindows Defenderさんにはいつも大変お世話になっております。
先日の2025年9月23日のWindows Defenderの定義体の更新以降、突如として2024年11月から全く手を加えていないLibreHardwareMonitor 0.9.4さんを指さして急に指弾するようになってしまいました。
まず始めはLibreHardwareMonitor.sysがVulnerableDriver:WinNT/Winring0.Gだから削除したよ、というメッセージから始まりました。
半可通なわたくしはWinring0という文字列だけ見てわかった気になりました。
WindowsというOSでは、ハードウェアの情報を得るためのドライバがカーネル空間で動作する必要があり、それはRing0という最上位の特権で動作しているということを承知していたからです。LibreHardwareMonitor さんはまさにRing0という特権を用いたハードウェアの情報を収集するツールですので必要不可欠な機能です。
ですが、カーネルへの攻撃への絶好の橋頭堡になるので、マイクロソフト社さんとしては自社で管理できないRing0で動作するドライバが憎くてたまらないのはよくわかりますが、なぜ急にいまさらWindows Defenderさんが問題視したのかよくわかりませんでした。
そこで、これはたま～に、しかしまれではない誤検知かしら？とおもって、まずはWindows Defenderさんに落ち着いてもらうように「Windows セキュリティ」の設定画面からLibreHardwareMonitor さんのVulnerableDriver:WinNT/Winring0.Gのブロックを許可して再起動してみました。
そして再起動すると、今度はWindows DefenderさんがLibreHardwareMonitor.sysに対して Trojan:Win32/Vigorf.Aだと主張し始めました。
うーん。「Trojan:Win32/Vigorf.A」って誤判定の時にやたらと見かけるのですが・・・Winring0.Gを許可したら今度は別件でトロイの木馬だっていうのは少々ただ事ではない気がします。
まあとにかく、LibreHardwareMonitorさんは実績もあるし余人をもって代えがたいかけがえのないプログラムなのでLibreHardwareMonitorさんがインストールされているフォルダを丸ごと無視してくれるようにWindows Defenderさんにお願い(設定)しました。
すると、今度はさらに、 C:\Windows\SystemTemp\ というフォルダにできるテンポラリファイルがTrojan:Win32/Vigorf.Aだと主張し、排除し始めました。
このテンポラリファイルはおそらくLibreHardwareMonitorさんが起動時にLibreHardwareMonitor.sysを自動生成してインストールする際に生成されるものと見受けられました。
ただし、それでもLibreHardwareMonitorさんそのものは動作するのですが、毎度毎度脅威を検出したといわれてはログが汚染されて意味を成しません。
本当の脅威に遭遇した場合にオオカミ少年のおとぎ話のごとく無視してしまう可能性を考えるとこれは実に好ましくありません。
だからといって、C:\Windows\SystemTemp\を監視対象から除くなんてことをしたら、それこそセキュリティリスクどころの話ではなくて Windows Defender さんにいてもらわなくたって結構です、と言っているようなものです。とてもうべなえません。
これは困ったことになりました。
ダメもとでgithubのLibreHardwareMonitorさんのサイトにバージョンが上がってないかな～?と、見に行ってみるとやっぱりまだ0.9.4のままでした。
仕方ない・・・とにかく毎回LibreHardwareMonitor.sysを自動生成させばないように改造をしよう・・・と思ってソースを見てみると・・・そこにはごく最近の修正として Swap WinRing0 to PawnIO #1857 とのコミットコメントが。
あらっ?
LibreHardwareMonitorさんはRing0層にアクセスするためのライブラリとして、WinRing0.sys(の64bit版)を採用していて、それをわざわざPawnIO.sysに変えたってことのように読めます。
ここまでわかればさすがの鈍いわたくしもよくわかりました。
LibreHardwareMonitor.sysの実態はWinRing0.sysだったのですね。
WinRing0.sysで検索するとあっさり原因が判明しました。いろんな記事に影響を受けるプロジェクトにLibreHardwareMonitorがあるとあっちこっちに記述されています。
新しいWinRing0.sysならば問題はないのですが、古いWinRing0.sysには脆弱性が発見されていたそうでして、その版を使用していたようです。
Windows Defenderさんは誤検知でもなんでもなく、きちんと脆弱なプロセスを指摘くださっていたのでした。
そして、LibreHardwareMonitorの開発者の皆様は先日対応してくれていたわけでした。
結果として、Windows Defenderさんに加えた除外指定はすべて排除でき、相変わらずWMI対応の、まさしく余人をもって代えがたいLibreHardwareMonitorさんを使い続けることができることとなりました。
原因が分かっただけでなく、自分で何もしなくてもすでに対策されていて、しかもそれがほんとに最近だったという運の良さにほくほくしながら、こうしてまた一つ、恥ずかしい記録を残すことになりました。
以上、恥の記録でした。
こんなことに二時間もかかってしまい、自分の生産性の低さにほとほと呆れます。
ここまでお読みいただき、誠にありがとうございました。
0 件のコメント:
コメントを投稿