
FirefoxもサードパーティーDLLをブロックへ 25
ストーリー by hylom
設定で切り替えられるなら良いのでは 部門より
設定で切り替えられるなら良いのでは 部門より
一部のセキュリティソフトや各種ユーティリティツールでは、ブラウザの挙動をコントロールするためにダイナミックリンクライブラリ(DLL)をブラウザのプロセスに読み込ませる行為(「DLL injection」)を行うものがあるが、Firefoxが安定性やセキュリティ、プライバシ強化のためにこういった行為を禁止するという(ghacks.net)。
すでにGoogle Chromeでは2018年にサードパーティによるDLL injectionをブロックしている。Googleによると、DLL injectionによってChromeのクラッシュ数が15%ほど増加することもわかったそうだ。
現在、Nightlyビルドでこの設定が導入されており、一般向けには3月リリース予定のFirefox 66でこの機能が有効になる模様。
フレームワークとしての動作もダメなのか (スコア:2)
起動時に、XULのフレームワークとしてどうさせた場合も駄目になるのだろうか?
原文を読んでも触れられてないのでよくわからなかったが、
もしダメならフレームワークとして動かせなくなるのかな。
Re:フレームワークとしての動作もダメなのか (スコア:2)
XULRunnerに移行するしかないのでは
とりあえず (スコア:0)
拡張用フォルダをファイルに置き換えるとセキュリティ屋を回避できる
flashも、デフォルトでブロックするし… (スコア:0)
各社とも、同じ報告に向かっているんだね。
少しでもセキュリティ脅威が減ればいいが。
DLL Injection をどうやって防いでいるのか (スコア:0)
DLL Injection をどうやって防いでいるのか
技術的な手法が気になる。
Re:DLL Injection をどうやって防いでいるのか (スコア:1)
Re: (スコア:0)
そしたら必要なDLLもロードできなくなるだろ
Re: (スコア:0)
暗黙リンクされるDLLだけで十分とか考えてるとIMEが完全に死ぬ
MS-IMEだけ通したAdobeのSandboxのクソ実装よりひどい
Re: (スコア:0)
Firefoxならソース見られるはずなので、頑張ればわかるかと…
#私にゃ無理
Re:DLL Injection をどうやって防いでいるのか (スコア:2, 参考になる)
このあたりでしょうか。コメント書いてあるので若干参考になります。
ntdll.dll が見えなくなるので、そのため ntdll.dll に定義されているすべての関数が使えない→ライブラリ「も」ロードできない、という感じでしょうか。
(すいません、このあたりの仕組みがあまり詳しくないのですが。)
https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18... [mozilla.org]
https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18... [mozilla.org]
Re:DLL Injection をどうやって防いでいるのか (スコア:4, 参考になる)
FireFoxのAPIフックの部分がこのコードだけだとよくわからないけど、軽く見た感じだと
関数"patched_NtMapViewOfSection"がこのDLLブロックの主要機能を担ってる。
まず、関数"InitializeDllBlocklistOOP"でサスペンド状態で作成されている子プロセス(コメントより推測)内の
"NtMapViewOfSection" APIを関数"patched_NtMapViewOfSection"でAPIフックする。
("LoadLibrary" API等でDLLファイルをメモリに読み込む時に、Windowsによって"NtMapViewOfSection" APIを使ってDLLファイルがメモリ空間内にマップされる)
関数"patched_NtMapViewOfSection"では、まず本来の"NtMapViewOfSection" APIを呼び出す。
そして、読み込まれたファイルと許可条件とを照合して、許可される場合は本来の"NtMapViewOfSection" APIを呼び出した時の戻り値を返す。
不許可の場合は"NtUnmapViewOfSection" APIで読み込んだDLLをアンマップした後、STATUS_ACCESS_DENIEDを返す。
これだとLoadLibrary系のWindowsの機能を使わずに自力でDLLを注入するタイプは防げないと思うけど、現在確認されてる中ではそんな例は無いって事なのかな?
Re:DLL Injection をどうやって防いでいるのか (スコア:2, 興味深い)
すごい参考になる。ntdllレベルのフックで実現してるのか……
> 現在確認されてる中ではそんな例は無いって事なのかな?
自力で注入する場合はDLLインジェクションじゃなくてコードインジェクションと呼ぶ。
DLLインジェクションする場合、DLLインジェクション用の小さいコードを
コードインジェクションで入れることもある。ので、注入自体はよく行われているし簡単にできる。
ただ、依存するAPIの名前解決をOSがやってくれないので、
注入したコードから他のDLL(OSの機能含む)が使いにくい。ので、DLLで入れるほうが楽。
楽なだけでその処理を組み込む事も可能だし、何なら難読化の余録で自前になってることもままある。
この話題はそういうソフトを完封する事よりも、
ブラウザ界はそういうソフトを許容していないって姿勢を示す意味のほうが大きいように感じる。
インジェクションを阻害すること自体はサンドボックス云々でも起こりうるので、
副作用での阻害じゃなくて主目的で排除しているんだ、モラルがあるなら入ってくるな、的な。
Chromeの機能の劣化コピー? (スコア:0)
PEファイルだろうと、アセンブラで書かれたシェルコード風のコード片だろうと、ブラウザのプロセスにコードインジェクションして実行出来るのに、
なんでFireFoxはDLL injectionだけ名指しなんだろう?
Chromeがブロックを発表した時のブログ記事 [chromium.org]を見ると、code全般のinjectionの話になってるのに。
Re: (スコア:0)
上位権限から注入されたら根本的な所では対処不能だし(対タンパ環境ではない)、
そういうのを許容しないって姿勢の提示なんじゃないかね。
それでもやる奴はみんなマルウェアだ、的な。
であれば対処はカジュアルなのだけでいい。
本気でやると互いにルートキット的なものになるイタチごっこの地獄絵図。
マルウェアがルートキットなのはある意味当然だが、
ブラウザが同じ穴のムジナになっては駄目だろう。
そもそもそれで解決するわけではないなんて状況では特に。
# CCCDでソニーはやらかしたけどね。ゲームガード類も似たような感じ。
Firefoxは (スコア:0)
普通のブックマークレットもディフォルトでは動かない。 Chrome では外部リソースを読み込んでなければ動く、Chrome の方が未だマシである。
Re:Firefoxは (スコア:2)
Firefox でブックマークレットが動かなかった覚えないけどなぁ。 Chrome は右クリックからブックマークレット作成できないのなんで。
svn-init() {
svnadmin create .svnrepo
svn checkout file://$PWD/.svnrepo .
}
Re:Firefoxは (スコア:1)
Re: (スコア:0)
CSPで機能拡張が阻害されたり、開発者ツールコンソールでコピペが効かなかったり、アドレスバーにjavascriptスキーム入りの文字列貼るたびにそこだけ消してgoogleに飛ばされたり、貼り付けやブックマークに長さ制限があったり。
ブラウザとセキュリティ設定次第で面倒な挙動が多い多い。
もうめんどくなったらグリモンスクリプトでも書くかとなる。
DLL injectionするセキュリティツール (スコア:0)
やってることの是非はさておき、メモリ管理が極めていい加減な製品が多いのってどうにかならんのかな。
こういう製品を仕込まれるユーザは直接のお客様ではない(苦情を受けることはほとんどない)とはいえ、
業界まるごと病んでるとしか思えない。
セキュリティのために有毒物質飲ませてくるアンチウイルス共 (スコア:0)
ウイルス駆除ソフト作ってるだけのくせに自分たちの書くコードは品質が高くセキュアであると勘違いした奴らによる他ソフトとユーザーへの嫌がらせ
Re: (スコア:0)
シェアの大きい物が変更してくれると、後追いしやすいです。
プラグインのブロックや既定フォントなど、シェアが小さいブラウザが先に変更するとサイト側の対応が遅れるので、ユーザーから使えないブラウザとみられます。
Re: (スコア:0)
Web広告で儲けてるGoogleはGoogle Chromeで広告ブロック機能を使えないようにしようと画策してるみたいだけど、Firefoxは追随しないでほしいなあ。
Googleがウェブ上の広告を非表示にする広告ブロック機能をChromeなどで無効化するための施策を進める
https://gigazine.net/news/20190123-google-block-adblock-chrome/ [gigazine.net]
Re: (スコア:0)
Firefox が頑張ってくれたおかげで、 IE6 の呪いが解けたのに
Re: (スコア:0)
じゃあChromeはEdgeHTMLの後追いってことでいいんですね。つくづく惜しいエンジンをなくしたもんだ