アカウント名:
パスワード:
wget --header="Range: bytes=18-18446744073709551615" [target]/welcome.png
で起こると言うことは、範囲チェックが甘くて変なメモリをアクセスするんだろうけど、HTTPをパースするなら物凄く変なリクエストが来て未知の不具合が顕在化する危険性はこれからも高いと思う。問題はカーネルモードでそれが起こると全体を巻き込んでフリーズする事だから、カーネルモードにサンドボックスを創れないのだろうか。
通信がネットワークドライバで独立していると考えれば、HTTPをパースして結果を返すのはメモリ処理で完結してハードウェアの状態遷移を伴わないのだから、
PAGE_FAULT_IN_NONPAGED_AREA
が起こってもHTTP.sysを再起動するかパージする機構ができるのではないかと思ってしまう。
とにかく、カーネルモードでHTTPを処理するのなら、基本的にHTTP.sysを信用しない構造にして欲しい。
※HTTP.sysだと直感的に機能が判りにくいのでHTTPD.sysとかにしてくれないかな。
> カーネルモードにサンドボックスを創れないのだろうか。
MS-DOSみたいなごく原始的なOSを除けばサンドボックスはすでに実装されているよ。ちなみにユーザーモードという名前がついている。
HTTP.sysの大きな目的の一つがカーネルモードとユーザーモードの切り替えコストを発生させずに処理を高速化することだから、ユーザーモードを使うならHTTP.sysの存在意義が薄れてしまいます。IIS 6.0の概要 [atmarkit.co.jp]なので
という疑問になりました。
今回の様なメモリ処理で完結している場合は、その様なモジュールの居場所としてリング1とかリング2が低コストで使えないのだろうか、とか、リング0のままでもメモリディスクリプタテーブルを必要最小限の物に切り替えて安全性を高められるのではないかと考えました。
カーネルモードとユーザーモードの切り替えコストは要するにサンドボックス境界をまたぐコストなわけだが。
> その様なモジュールの居場所としてリング1とかリング2が低コストで使えないのだろうか、とか、リング0のままでもメモリディスクリプタテーブルを必要最小限の物に切り替えて安全性を高められるのではないか
そんなARMはもちろんx64ですらほとんど廃止された化石のような機能群を持ち出されても。
Singularity [wikipedia.org]という、静的検証で安全なマネージドコードをカーネルモードで動かす、Microsoftの実験的OSはありますね。Linuxでも、一応eBPFという仮想マシンを内蔵していますが、安全性はどうなのだろうか?
ていうか、TCP/IPはともかくHTTPをカーネルでパースされてもなぁ……という感じ。OSで提供するとしてもユーザーランドで動くライブラリで十分な気しかしない。
サーバもといサービス・デーモンにd付けるのはUNIX文化で、プロトコルとしてはHTTPなのだからそこは問題ないと思う。自分もクライアントとしてのWindowsでも起きる話かと思ってびっくりはしたけど。
"server"版WindowsじゃなくてもIISモドキHTTPサーバーは標準で入れられるから影響受ける場合もあると思います。対象製品にclient版Windowsも入ってますし。普通はわざわざ有効にしないと思うからおそらくは問題ないと思われますが。
自分用ファイル置き場サーバーで建ててたことあったなあ。今はもうDropboxとかOneDriveとかクラウドサービスで事足りてるけど。
HTTPのクライアントって意味で、Server版でないWindowsって意味ではないです。非Server版でもIISが入れられるのは知ってますが、仰るとおり一般には有効にしない機能ですね。
長々と何を書いているのかと思ったら、HTTP.sysがカーネルモードで動いているのに文句を言っているってことか。最近はOSの起動時からHTTPを処理する必要があるから、カーネルモードで動作するHTTPモジュールも必要なんだろうけど、確かに、IISがHTTPリスクエストをパーズするのにカーネルモードは不要な気もするな。ユーザランドで動くHTTPモジュールもあってもよさそうに思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
HTTP.sysを信用するな (スコア:5, すばらしい洞察)
で起こると言うことは、範囲チェックが甘くて変なメモリをアクセスするんだろうけど、HTTPをパースするなら物凄く変なリクエストが来て未知の不具合が顕在化する危険性はこれからも高いと思う。問題はカーネルモードでそれが起こると全体を巻き込んでフリーズする事だから、カーネルモードにサンドボックスを創れないのだろうか。
通信がネットワークドライバで独立していると考えれば、HTTPをパースして結果を返すのはメモリ処理で完結してハードウェアの状態遷移を伴わないのだから、
が起こってもHTTP.sysを再起動するかパージする機構ができるのではないかと思ってしまう。
とにかく、カーネルモードでHTTPを処理するのなら、基本的にHTTP.sysを信用しない構造にして欲しい。
※HTTP.sysだと直感的に機能が判りにくいのでHTTPD.sysとかにしてくれないかな。
Re:HTTP.sysを信用するな (スコア:3, おもしろおかしい)
> カーネルモードにサンドボックスを創れないのだろうか。
MS-DOSみたいなごく原始的なOSを除けばサンドボックスはすでに実装されているよ。ちなみにユーザーモードという名前がついている。
Re:HTTP.sysを信用するな (スコア:1)
HTTP.sysの大きな目的の一つがカーネルモードとユーザーモードの切り替えコストを発生させずに処理を高速化することだから、ユーザーモードを使うならHTTP.sysの存在意義が薄れてしまいます。IIS 6.0の概要 [atmarkit.co.jp]
なので
という疑問になりました。
今回の様なメモリ処理で完結している場合は、その様なモジュールの居場所としてリング1とかリング2が低コストで使えないのだろうか、とか、リング0のままでもメモリディスクリプタテーブルを必要最小限の物に切り替えて安全性を高められるのではないかと考えました。
Re: (スコア:0)
カーネルモードとユーザーモードの切り替えコストは要するにサンドボックス境界をまたぐコストなわけだが。
> その様なモジュールの居場所としてリング1とかリング2が低コストで使えないのだろうか、とか、リング0のままでもメモリディスクリプタテーブルを必要最小限の物に切り替えて安全性を高められるのではないか
そんなARMはもちろんx64ですらほとんど廃止された化石のような機能群を持ち出されても。
Re: (スコア:0)
Re: (スコア:0)
Singularity [wikipedia.org]という、静的検証で安全なマネージドコードをカーネルモードで動かす、Microsoftの実験的OSはありますね。
Linuxでも、一応eBPFという仮想マシンを内蔵していますが、安全性はどうなのだろうか?
Re:HTTP.sysを信用するな (スコア:1)
ていうか、TCP/IPはともかくHTTPをカーネルでパースされてもなぁ……という感じ。
OSで提供するとしてもユーザーランドで動くライブラリで十分な気しかしない。
サーバもといサービス・デーモンにd付けるのはUNIX文化で、プロトコルとしてはHTTPなのだからそこは問題ないと思う。
自分もクライアントとしてのWindowsでも起きる話かと思ってびっくりはしたけど。
Re: (スコア:0)
"server"版WindowsじゃなくてもIISモドキHTTPサーバーは標準で入れられるから影響受ける場合もあると思います。
対象製品にclient版Windowsも入ってますし。
普通はわざわざ有効にしないと思うからおそらくは問題ないと思われますが。
Re: (スコア:0)
自分用ファイル置き場サーバーで建ててたことあったなあ。
今はもうDropboxとかOneDriveとかクラウドサービスで事足りてるけど。
Re: (スコア:0)
HTTPのクライアントって意味で、Server版でないWindowsって意味ではないです。
非Server版でもIISが入れられるのは知ってますが、仰るとおり一般には有効にしない機能ですね。
Re: (スコア:0)
長々と何を書いているのかと思ったら、HTTP.sysがカーネルモードで動いているのに文句を言っているってことか。
最近はOSの起動時からHTTPを処理する必要があるから、カーネルモードで動作するHTTPモジュールも必要なんだろうけど、
確かに、IISがHTTPリスクエストをパーズするのにカーネルモードは不要な気もするな。
ユーザランドで動くHTTPモジュールもあってもよさそうに思う。