/dev/kmem
と/dev/mem
がシステムのメモリ(つまり、未加工のRAM)へのアクセスを提供することを理解しています。カーネルで/dev/kmem
を完全に無効にできること、および/dev/mem
のアクセスを制限できることも知っています。
メモリに直接アクセスできることは、開発者やハッカーにとって役立つ場合がありますが、/dev/mem
を介してメモリにアクセスする必要があるのはなぜですか。私の知る限り、カーネルでは無効にすることはできません(/dev/kmem
とは異なります)。悪用されたり悪用されたりする可能性のある未加工のメモリにアクセスすることは、問題を求めているように思えます。
実用的な使い方はありますか?ユーザープログラムが適切に機能するために必要ですか?
Undermining the Linux Kernel:Malicious Code Injection via/dev/mem これらの2つの箇条書きが含まれているというタイトルの、Scale 7x 2009のスライドデッキがあります。
誰が必要ですか?
- Xサーバー(ビデオメモリと制御レジスタ)
- どせむ
これまでに検索で見つけたすべてから、これらの2つの弾丸は合法的な使用のためのフロントランナーであるように見えます。
/dev/mem
および/dev/kmem
を無効にした場合でも、メモリがダンプされることに注意してください。 man proc
を見て、/proc/kcore
を明らかにしてください。システムの物理メモリです。非常に優れたフォレンジックツールキット rekallには既にこれを行うツールがあります ;メモリ(および/boot
ファイル)をダンプして、分析できるようにします。
実際のところ、 buntuはデフォルトで/dev/kmem
を無効にします :
/dev/kmem
の最近の使用法はありません。これは、攻撃者がカーネルルートキットをロードするためにそれを使用することを超えています。CONFIG_DEVKMEM
は "n"に設定されています。/dev/kmem
デバイスノードは、Ubuntu 8.04 LTSからUbuntu 9.04まで存在しますが、実際にはカーネル内のどこにも接続されていません。
Ubuntuは /dev/mem
をアプリケーションで必要とするため を無効にしません。
一部のアプリケーション(Xorg)では、ユーザー空間から物理メモリに直接アクセスする必要があります。このアクセスを提供するために、特別なファイル
/dev/mem
が存在します。以前は、攻撃者がrootアクセス権を持っている場合、このファイルからカーネルメモリを表示および変更することが可能でした。CONFIG_STRICT_DEVMEM
カーネルオプションは、非デバイスメモリアクセスをブロックするために導入されました(元々はCONFIG_NONPROMISC_DEVMEM
という名前)。
/proc/kcore
を無効にする方法は?カーネルの構築時にCONFIG_PROC_KCORE
を有効にしないでください。
/dev/mem
を無効にするにはどうすればよいですか?まあ、man mem
を見ると、その作成方法の詳細がわかります。
mknod -m 660 /dev/mem c 1 1
chown root:kmem /dev/mem
rm -rf /dev/mem
だけを実行できるはずです。 CONFIG_STRICT_DEVMEM
を有効にしないことで、カーネルのビルドフェーズ中に無効にすることができます。
/dev/kmem
を無効にする方法は?カーネルのビルド時にCONFIG_DEVKMEM
が有効になっていないことを確認してください。
/proc/kcore
、/dev/mem
、/dev/kmem
を無効にして、暗号化されたスワップパーティションを使用したり、スワップをまったく使用しなかった場合はどうなりますか?さて、 あなたの記憶はただ凍結される可能性があります そしてその方法でアクセスしました。この攻撃を防ぐにはどうすればよいですか? RAMを暗号化します。どのようにRAMを暗号化しますか?できません。 詳細はTRESORを参照してください 。
ご存知のように、_/dev/mem
_は実行中のシステムの物理メモリへのアクセスを提供します。 _/dev/kmem
_は、カーネル仮想メモリへのアクセスを提供します。これらの両方のキャラクターデバイス 永続的に無効にすることができます カーネル構成オプションを介して(コードは最も信頼できる情報源であるため、参照として使用されます)。以下の最初の2つのオプションの設定を解除すると、対応するデバイスが無効になります。
CONFIG_DEVKMEM
_ :_/dev/kmem
_がブート時に作成されるかどうかを決定しますCONFIG_DEVMEM
_ :_/dev/mem
_がブート時に作成されるかどうかを決定しますCONFIG_STRICT_DEVMEM
_ :_/dev/mem
_が存在する場合、アクセスが制限されているかどうかを判別しますディストリビューションによっては、現在のカーネル構成は_zless /proc/config.gz
_またはless /boot/config-$(uname -r)
などを使用して確認できます。
_/dev/mem
_の最初の意図thinkは memory-mapped 周辺機器との相互作用をサポートすることでした。これらの仮想デバイスを利用できることによる明らかなセキュリティ上の影響(たとえば、攻撃者がその場で別のプロセスのメモリやカーネルにパッチを当てることができる)は、少なくとも10年間知られています。 _/dev/mem
_へのアクセスの制限はメインラインカーネルでサポートされています 2008年の初めから 、_/dev/kmem
_もオプションです その頃から も。
10年前、X
は_/dev/mem
_に依存していたようですが、これはまだ正しいとは思いません。 X
が_/dev/mem
_を必要としているという主張をテストするために、昨日、ラップトップから仮想デバイスを削除しましたが、それ以来、一見完璧に機能しています。 2017年にはこれらのデバイスは実際には使用されないようです研究および開発以外では。
セキュリティの観点から、これらのデバイスを削除することをお勧めします。 remote攻撃者は、昇格された特権を使用して、そのアドレス空間外のメモリを読み取ることができることに注意する必要があります。他のユーザースペースアプリケーションのメモリには、 _/proc/<pid>/mem
_ を使用してアクセスできます。カーネルメモリには _/proc/kcore
_ を使用してアクセスできます。
システムに最初から/dev/mem
を含めていません。私はGentoo Linuxを使用しているので、このLinuxディストリビューションでは、Linuxカーネルを含むすべてのパッケージを実際に自分でビルドするため、これは驚くに値しないかもしれません。
X.org X11を使用している場合でも、/dev/mem
がないために問題が発生することはありませんでした。ちょうど今日、パッケージx11-drivers/xf86-video-vesa
の- emerge が、次のように/dev/mem
が必要であることを示すメッセージを出力することに気づきました。
* This driver requires /dev/mem support in your kernel
* Device Drivers --->
* Character devices --->
* [*] /dev/mem virtual device support
XServer のVESAドライバーを意図的にインストールしなかったため、またはフォールバックとしてのみインストールした場合でも、実際に使用する必要がなかったため、気付かなかった–今まで。
しかし、これはa)X11が/dev/mem
をもう必要としないこと、およびb)を証明します。 とにかく、一部のX11ビデオドライバーはまだ機能します。
特定のハードウェア用の新しいビデオドライバーは、ほとんどの場合、それがなくても機能します。現代のX.org-X11(Gentooではx11-base/xorg-server
)が suid root である必要もないように、これが進行状況のようです...