アカウント名:
パスワード:
DLL Injection をどうやって防いでいるのか技術的な手法が気になる。
Firefoxならソース見られるはずなので、頑張ればわかるかと…
＃私にゃ無理
このあたりでしょうか。コメント書いてあるので若干参考になります。ntdll.dll が見えなくなるので、そのため ntdll.dll に定義されているすべての関数が使えない→ライブラリ「も」ロードできない、という感じでしょうか。（すいません、このあたりの仕組みがあまり詳しくないのですが。）
https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18... [mozilla.org]
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を注入するタイプは防げないと思うけど、現在確認されてる中ではそんな例は無いって事なのかな？
すごい参考になる。ntdllレベルのフックで実現してるのか……
> 現在確認されてる中ではそんな例は無いって事なのかな？自力で注入する場合はDLLインジェクションじゃなくてコードインジェクションと呼ぶ。DLLインジェクションする場合、DLLインジェクション用の小さいコードをコードインジェクションで入れることもある。ので、注入自体はよく行われているし簡単にできる。ただ、依存するAPIの名前解決をOSがやってくれないので、注入したコードから他のDLL(OSの機能含む)が使いにくい。ので、DLLで入れるほうが楽。楽なだけでその処理を組み込む事も可能だし、何なら難読化の余録で自前になってることもままある。
この話題はそういうソフトを完封する事よりも、ブラウザ界はそういうソフトを許容していないって姿勢を示す意味のほうが大きいように感じる。インジェクションを阻害すること自体はサンドボックス云々でも起こりうるので、副作用での阻害じゃなくて主目的で排除しているんだ、モラルがあるなら入ってくるな、的な。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
DLL Injection をどうやって防いでいるのか (スコア:0)
DLL Injection をどうやって防いでいるのか
技術的な手法が気になる。
Re: (スコア:0)
Firefoxならソース見られるはずなので、頑張ればわかるかと…
＃私にゃ無理
Re: (スコア:2, 参考になる)
このあたりでしょうか。コメント書いてあるので若干参考になります。
ntdll.dll が見えなくなるので、そのため ntdll.dll に定義されているすべての関数が使えない→ライブラリ「も」ロードできない、という感じでしょうか。
（すいません、このあたりの仕組みがあまり詳しくないのですが。）
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で入れるほうが楽。
楽なだけでその処理を組み込む事も可能だし、何なら難読化の余録で自前になってることもままある。
この話題はそういうソフトを完封する事よりも、
ブラウザ界はそういうソフトを許容していないって姿勢を示す意味のほうが大きいように感じる。
インジェクションを阻害すること自体はサンドボックス云々でも起こりうるので、
副作用での阻害じゃなくて主目的で排除しているんだ、モラルがあるなら入ってくるな、的な。