パスワードを忘れた? アカウント作成
1392 story

コンソールプログラムでWindows 2000がハングアップ 38

ストーリー by Oliver
緊急停止用の仕様です 部門より

odaken 曰く,"ニュースグループfj.os.ms-windows.programming一連の投稿によると、コンソールプログラムで簡単にWindows 2000がハングアップするかリブートするそうです。さぞかし巧妙なセキュリティーホールをついたものと思いきや、なんとprintf("\t\b\b")一発でいっちゃうというものでした。ちなみに私もWindows XPで試したところハングアップしちゃいました。プロセスが落ちるならまだしも、カーネルまで逝かないでほしかった。NT系カーネルは信用できると思ってたのにー。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by seldon (5637) on 2001年10月28日 17時21分 (#33349)
    小島さんのセキュリティmemoのページでも既報ですが、 それを使用した ActiveX コントロールは作れるそうです。
  • Re:これですな (スコア:4, 参考になる)

    by iteb (189) on 2001年10月28日 18時09分 (#33359)
  • by brake-handle (5065) on 2001年10月28日 21時10分 (#33380)

    大昔、JNetHackをwin32で作っていた時、似たような症状を見ました。putc()で2バイト文字を1バイトずつ出力するとfaultを食らうというものです(NT 4.0で。OSごと落ちたかどうかは失念)。

    記憶がおぼろげですが、win32のコンソール出力APIには1バイト単位での入出力を行うものがなく、すべて文字列としていたような気がします。マルチバイト文字列がきちんと完結していることを前提にしてAPIを作っているのでしょう。最も、端末という考えのないOSに文字の片割を正しく扱えというのにも無理があるといえばありますが。

  • by oku (4610) on 2001年10月28日 23時32分 (#33415) 日記
    NT4 や 2k にも引っかかるようなので XP だけリコールしてもしようがないのではありませんか?
    # リコール不要ですが修正パッチは欲しい...
  • by brake-handle (5065) on 2001年10月29日 1時42分 (#33467)

    Unixでも確かにttyを使えばkernelは通ります。ですが、Unixのttyが解釈するのは基本的にフロー制御やジョブ制御などです。それ以外のデータについてはcharsetすら仮定をおいていません。あるいはラインディシプリンでも、せいぜい通信路が8bitか7bitかを指定できるぐらいです。

    charsetやlocaleに基づいたデータの解釈など、より複雑な処理を実現するためには、Unixではpty(pseudo-tty)を使うのが普通です。これを使えばOSが想定していないようなラインディシプリンであっても、ユーザプロセスで実現できます(xtermやtelnetdなどもこれで動いている)。作れるttyドライバの自由度が高いことや、デバッグが容易なことから、現代のUnixではptyを使うことが多くなっています。

    ptyに相当するものは、win32ではまだ出現していないはずです。といっても、ジョブ制御自体win32にはありませんが。

  • これですな (スコア:3, 参考になる)

    by Anonymous Coward on 2001年10月28日 17時14分 (#33347)
    #include int main(void) { while (1) printf("\t\t\b\b\b\b\b\b"); return 0; }
  • 原因の検討がつかないバグですね…
    コンソール出力で\bを処理する時にバグでもあるのかな?
    けど、コンソール出力関係の一般的な問題だったら、"copy con"かなんかで[Tab]-[BS]-[BS]で落ちそうですし。(元ニュースによると「漢字コード第二バイトの\t」と「\b\b」だったら落ちないそうです。)
    なんかこのバグ自体の問題はともかくこういう基本的な部分でバグが出たということでNTの内部(ソースやら構造やら)が結構ぐちゃぐちゃなのではないか、という考えが頭をよぎります。
  • by Anonymous Coward on 2001年10月28日 20時23分 (#33372)
    http://www.zdnet.com/zdnn/stories/news/0,4586,2436920,00.html Windows2000が持つ63000のバグの一つなのでしょう。
  • by G7 (3009) on 2001年10月28日 23時02分 (#33402)
    とはいっても、表示って、本質的に1つのプロセスだけで完結するわけじゃない処理ですよね?
    表示のハードに至るまでの経路が全部、カーネルじゃなくプロセスの所有物ならば話は別ですが、
    ふつーそういうことは無いでしょうし。
    (俺は知りませんがきっと)unixでも、
    あるバイト列を表示するまでに原理的に最低1回はプロセスからカーネルかなにかに処理が回ってくるはずですよね?

    まぁ、どっちにせよ今回の失態は笑って看過できるもんじゃないですが>win
  • 他にも、コンソールで 55 行以上出力した後に、 他にもCtrl-H(BS)でカーソルを1文字分、 左に移動させようとしても、左上に移動しちゃう という難儀なバグもあります。

    結局、どう解決したかというと、Ctrl-M(CR) コードで1カラム目に戻してから、戻るべき 位置まで同じ文字列をもう1度出力してから カーソルを右に移動させるという力技。

    エスケープシーケンスがまともにつかえたらなー。

  • Re:これですな (スコア:3, 参考になる)

    by kaokun (2474) on 2001年10月29日 2時01分 (#33471)
    バッチファイルにして、

    @echo off
    cls
    :LOOP
    echo " " ←"\t\t\b\b\b\b\b\b" に当たるコードを直埋め込み
    goto LOOP

    でもいけました。
    ポイントは、cls みたいです。これが無いとコマンドラインからは再現できませんでした。
    内部的に、画面左上より戻ったバッファ位置に書き込んじゃうんではないかと想像されます。
    --
    kaokun
  • Re:これですな (スコア:3, すばらしい洞察)

    by oku (4610) on 2001年10月29日 9時41分 (#33522) 日記
    いや、タイマー連動で時限発火されたら Nimda どころの騒ぎじゃ済まないのではありませんか?

    # で、修正パッチを探しているのですが
    # まだ公開されていないんですかね? > MS さま

  • 2台のW2k で試したけど、ハングしませんでした。
    元ネタのコンパイラはなんですか?
    わしのは cygwin....
  • Re:これですな (スコア:2, おもしろおかしい)

    by seldon (5637) on 2001年10月29日 0時38分 (#33448)
    あっさり死んでくれるのであれば、Nimdaみたいに広まらないから害が無い....かも(多少の希望的観測)
  • エスケープシーケンスがまともにつかえたらなー。
    VT100 とか ANSI 互換ではありませんが NT コンソールの制御をする API はあったと思いますが。

    件の役に立つかどうかは存じませんが CONSOLE_SCREEN_BUFFER_INFO 構造体周りをホゲればどうにかなりませんかね? (ウソだったらごめんなさい)

  • すみません。
    多分カーソルの位置設定は SetConsoleCursorPosition() の方です。_(_ _)_
  • by anakata (5746) on 2001年10月29日 13時17分 (#33576)
    LSI-C86を入れてなかったので、Watcom C 11.0の16bit DOS版と32bit NT版で試しました。
    結果:
    16bit版:正常
    32bit版:即死
    でした。DOS仮想マシンの中では大丈夫みたいですね。
    以前SJISを1byteずつ出力して落ちた時も、16bitアプリは大丈夫でした。
  • 四年前に (スコア:2, 興味深い)

    by Anonymous Coward on 2001年10月29日 16時56分 (#33649)
    あの、実は私、97年の1月にはこの問題に気がついていたんですが、特に人に知らせませんでした。
    罪深いでしょうか?
  • by oku (4610) on 2001年10月29日 22時19分 (#33749) 日記
    一定期間後にでも死んでくれれば、それ以上他所には被害が広まりませんよね?
    Windows にも AT という便利なコマンドがございまして...
    # 一ヶ月周期くらいにしとけば誰も疑わなかったりして。 :-)
  • NT 系 OS で言うと、サブシステムはカーネルなんでしょうか、ユーザプロセスなんでしょうか?

    # 今回の問題って WIN32 サブシステムだと思うんですけど...

  • by k2luna (3854) on 2001年10月28日 17時18分 (#33348)
    インターネット経由で実行させることはできるのでしょうか?
    できたら大変なことになると思うのですけど…。
    --
    k2luna−来栖 香
  • by skamio (5870) on 2001年10月28日 17時31分 (#33352)
    これがNimdaに取り込まれた日には、仕事にならんでしょう...
    WindowsXPは発売早々リコールしてくれないかな。
  • by atrib (5512) on 2001年10月28日 17時59分 (#33357)
    VC++でコンパイルすると起こるという記述を読んだ記憶があります。
  • オフトピ失礼 (スコア:1, おもしろおかしい)

    by newmodelx (4227) on 2001年10月28日 21時09分 (#33379) ホームページ 日記
    仮面ライダーV3みたいでイカス!
  • by Anonymous Coward on 2001年10月28日 22時22分 (#33390)
    端末があるないに関わらず、ソフトウェア的にはユーザに何されても動作を保証するのがまっとうなOSのあるべき姿だと思うのですが…
    (というより、それをWindowsに求めるのはユーザのあるべき姿ではないのかも知れない)
  • by Anonymous Coward on 2001年10月28日 22時40分 (#33397)
    最低限、死ぬのはそのプロセスだけにするのが、OSの役割なのでは?
  • 端末ドライバタスク(スレッド? プロセス? Winのことは知らん)
    や、関連するユーザプロセスがお亡くなりになることまでは
    許せても、リブートするなんてのは、論外なのでは…。
    --
    from もなか
  • by seldon (5637) on 2001年10月29日 19時14分 (#33689)
    一定期間後にでも死んでくれれば、それ以上他所には被害が広まりませんよね?
    いまだに来るんですが...(^^;>Nimda
  • Unixでも確かにttyを使えばkernelは通ります。ですが、Unixのttyが解釈するのは基本的にフロー制御やジョブ制御などです。それ以外のデータについてはcharsetすら仮定をおいていません。あるいはラインディシプリンでも、せいぜい通信路が8bitか7bitかを指定できるぐらいです。

    UNIX System V Release 4 (SVR4) 系のシステムには, そのラインディシプリンモジュールである ldterm に文字エンコーディングを意識する部分があります.

    それは canonical 入力処理で ERASE 文字を操作する部分で, 端末から ERASE 文字が入力されると,直前の文字が何バイトの文字で,画面上を何カラム占有しているかを意識して,バッファの最後の文字を削除し,画面上の消去処理 を行います.(ERASE 文字は直前の「1文字」を削除する処理ですので,当然1文字が何バイトかを意識するし, それを画面上で反映する必要性から,カラム数も意識します.)

  • by nsawa (497) on 2001年10月30日 5時01分 (#33872)
    これはお手軽ですね。当方でも再現できました。
    ":LOOP"と"goto LOOP"はなくても確実に落ちるようです。
    環境によってはループさせないと落ちないことがあるのでしょうか。
    タイミング依存?
  • by WindKnight (1253) on 2001年10月30日 10時30分 (#33935) 日記
    コンソールを特別扱いしているってことは、
    まだ、DOS 世代なわけですな。
  • by Anonymous Coward on 2001年10月29日 2時12分 (#33476)
    NTにもJob Objectは存在するが、UndocumentedなAPI なので上位互換性を信じない方が良い。以前、ある仕 事でJob Object周りの挙動がおかしくて、NT 4.0から Windows 2000に移行できなかったことがある。MSに問 い合わせたが、要領を得る答えは得られなかった。 やっぱNT自体、GDIやIMEをカーネルモードで動かした り、腐った仕様変更ばかり続けてるよなぁ。個々の判 断にエンジニアリング的な合理性はあるんだろうが、 気が付いたらとてもサーバーには使えない構造になっ てるんじゃないか?そもそも、Officeを動かすことに 最適化したOSをサーバーに使うもんじゃないし、 OfficeにはWindowsが刺さるコードは含まれてないだろ うし、Officeなら落ちたってデータ復旧してくれる そうだし...
  • by Anonymous Coward on 2001年10月29日 12時39分 (#33565)
    LSI-C86で作っても、Win2Kを殺せるんですか? 手元にこのOSがないので、どなたか試してくだされ。
  • by Anonymous Coward on 2001年10月29日 15時41分 (#33614)
    > やっぱNT自体、GDIやIMEをカーネルモードで動かしたり、
    > 腐った仕様変更ばかり続けてるよなぁ。個々の判断にエンジ
    > ニアリング的な合理性はあるんだろうが、 気が付いたらと
    > てもサーバーには使えない構造になっ てるんじゃないか?

    カトラーの不在中にGDIがカーネルモードで動くように改悪されてカトラーがキレたという噂が。
  • by Anonymous Coward on 2001年10月29日 19時40分 (#33698)

    罪は深くないと思うけど、せっかく3年もあっためたんだから、もっと派手に発表してもらいたかった、という感じやね。

  • by Anonymous Coward on 2001年10月30日 8時37分 (#33900)
    "最低限、死ぬのはそのプロセスだけにするのが、OSの役割なのでは?"と書いたACです。 この話は、コンソール出力にカーネルがかかわっているかどうかとは、無関係な話です。

    何かトラブルが起こったとき、その原因は、 カーネルにあるか、カーネル以外にあるか、 どちらかです。

    • カーネルに原因があるのなら、 デバッグしましょう。
    • カーネル以外に原因があるのなら、 問題が起きたときに、 問題を起こしたプロセス以外は保護しましょう。

    これが、"最低限、死ぬのはそのプロセスだけにするのが、OSの役割なのでは?"という意味です。
  • by Anonymous Coward on 2001年10月30日 22時48分 (#34214)
    Windows2000はなかったですね。 NTのコンソールで確かめたのでしょうか?
    • by Anonymous Coward
      そう、これは少なくともNT4から存在している問題です。
      もう環境がないから確認できないけど、3.51では落ちなかったように記憶している。
typodupeerror

UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie

読み込み中...