C言語以外ならバッファオーバーフローは起きないのでしょうか？

Question

こんにちわ

私はつい最近プログラミング入門したばかりのものです。

いろいろな興味に実力がついていけずとんちんかんな状態です。

ところで、昨今のセキュリティ問題でよく登場するバッファーオーバーフローという
ものは何だろう、と思っていろいろ自分なりに調べてみました。

ある説明文では、C言語のメモリー格納仕様に起因する問題、と書かれていました。

・・・ということは、パスカルなどのような他の言語であれば、バッファーオーバー
フローの心配はしなくてもいいことになるでしょうか？


マック愛好家の間では、MacOSの安全性の高さを大変にアピールしていますが、これは
技術的に言うとMacがPascal言語で開発されていたから、という種明かし、と考えれば
よいことになりますでしょうか？

お暇な方がいらしてましたら、どうかおつきあい頂けましたら幸いです。

ultraCS · Accepted Answer

#6です、話がそれて雑談というか余談に近づいていますが

ちょっと誤解を招く書き方がありました、コードインタープリタというのは言語ではなく、CPUの中で命令の機械語をフェッチし、インストラクションコードに基づいたアキュムレータの動作、オペランドのアドレス変換をしてデータを取り出す機構で、CPU内部で動く一種のプログラムで、ユーザがいじることは出来ません。コードインタープリタというのも正式名称かはわかりません。

それが、次の実行命令として、インストラクションポインタで指定されたアドレスに格納されているバイト群を取り出すわけですが、このとき、それが、コードかデータかを判断できないと言うことです。

ノイマン型コンピュータでは、アドレス空間はリニアに実装され、そこを適当にコードとデータで分割して使います。この方法にはある程度のルール(低いアドレスは割り込み等のシステムコールに使うなど)はありますが、基本的にはフリーです。データがコードの前にあっても後ろにあっても構わないわけです。


Pascalも、Wirthが考えたPureなパスカルであれば別ですが、現在出回っているPascalは使いやすく(Cと対峙する為もあり)するために拡張が施されているし、実際に使うとなると、すべてを値渡しというわけにも行かず、システムとのインターフェースでは、アドレス渡しをせざるを得ません、で、ここが大きな穴になってしまいます。まあ、BASICだって、ダートマスのPureなBASICは今のBASICとは似ても似つかないものですから仕方ないでしょうけど。


ところで、バッファオーバーフローに限れば、おそらく、プログラムではライブラリで処理しているでしょうから、そのライブラリのコードに問題がある、ところが、そこを書いた人間が退社してしまってわからない。ソースが見つからないなんて事もこの業界ではざらにありますから、おそらく、そんなところではないかと思います。これを書いたプログラマは気が気じゃないだろうなあ(人ごとじゃなく、心臓が縮む思い)。

ultraCS · Answer

一般論で書きますね

ノイマン型コンピュータである限り、本質的には回避できない問題です。データとプログラムを区別しないというのも一つの特徴で、これの恩恵はOS開発などでは計り知れないものがあり、ちゃんと理解して使えば大変便利なものでした。インストラクションコードやオペランドを直接書き換えるなど、アドレス空間が小さい時代には大変重宝でした。オーバーレイモジュールなどもユーザー側で実現できましたから。

なので、OSや言語、アプリケーションが一生懸命それを防止しようとしても、最後に出てくるコードインタープリタが一切お構いなしで動いてしまうため、どこかに穴があれば簡単に漏れてしまいます。これはMacでも同じです。違うのは穴の大きさと数ということになります。

また、Macにしても、初期には、OSがPascalで書かれていたとしても、BIOSに当たる部分、ToolBoxやデバイスドライバには68Kネイティブのアセンブラで書いた部分があり、ここでは、同様の問題があり得ました(最近のMacは詳しくないので)。

データフローマシンなど非ノイマン型に期待するしかないかも知れません。実際、アドレス空間が広がった状況では、コードとデータを完全分離することは不可能ではありません。

noname#12761 · Answer

古典的なパスカルの仕様ならバッファーオーバーフローは発生しないかもしれません。

しかしそれでは OS は開発できません。当然ポインタが使用できインラインアセンブラが使えるような拡張された仕様でないと開発はできません。

そうなれば、C,C++ とほとんど条件は変わりません。

また Mac は Unix 指向に向かっていますので関数呼び出しの仕様の違いなど考えると Pascal で開発すると逆にバグが増えそうです。

TT414 さんの

>OSX以前はPascalだったかもしれませんが、OSXはCです(unix系なので)

との指摘は理にかなっています。

TT414 · Answer

>MacがPascal言語で開発されていた
OSX以前はPascalだったかもしれませんが、OSXはCです(unix系なので)。

k_o_r_o_c_h_a_n · Answer

＞ある説明文では、C言語のメモリー格納仕様に起因する問題、と書かれていました。

この説明は適切ではないと思いますよ。
「C言語のメモリー格納仕様を鑑みず、無頓着なプログラミングにより発生する問題」と
するのが良いかと思います。
バッファオーバーフローの原因を、C言語に押しつけてしまうのは、如何なものかと。

＞・・・ということは、パスカルなどのような他の言語であれば、バッファーオーバー
＞フローの心配はしなくてもいいことになるでしょうか？

現代のpascal系の言語で、バッファオーバーフローが起こらないわけではありません。
ポインタを使う場面は多々あるので、同じような問題は引き起こす可能性を持っていると
考えたほうが良いと思います。

rinkun · Answer

No.1さんはOSの不備と言っていますが、多くのバッファオーバーフロー攻撃はOSの用意したバッファじゃなくアプリケーションが用意したバッファを溢れさせてアプリケーションを乗っ取るものです。もしOSの用意したバッファが溢れたらカーネルごと乗っ取られますよ。(^-^;)
バッファオーバーフローに関してOSが不備な点は多くはスタック上にあるバッファ溢れ部分でプログラムが実行できてしまうことくらいです。プログラムとデータを区別してアクセス権管理ができていれば多くの場合は防げるんですからね。
# ただOSがCPUサポートなしに管理するのは大変なので最近のCPUではNXビットなんてものが追加されていたりする

ちなみにバッファオーバーフローは配列の境界チェックをきちんとやっていれば防げます。C言語では全く無チェックなのでa[-1]なんて無茶もできるわけですが、Pascalや最近ではJavaなど多くの言語では宣言範囲外の配列インデックスではアクセスできないようになっています。
ただ配列インデックスのチェックは実行時のオーバーヘッドになるため、C言語では採用されていないということです。

OsieteG00 · Answer

C言語に限った話ではないですが、C言語では任意のアドレスのメモリにアクセスできるのでそういう説明になりましたかね。

結局、PascalであってもCであってもコンパイルすれば同じですから、言語による違いというものはありません。また、メモリの格納仕様は処理系(OS)によって異なります。言語仕様によるものというよりは、OS上の不備を突いた攻撃です。OSが用意したバッファより大きいデータ量を送りつけて、バッファより大きい部分のデータをプログラムとして認識させて誤動作させるというしくみです。

Macの安全性については、単にシェアが低くてかつ内容がブラックボックス化しているのでハッカーの興味を引かなかったという事ですね。

C言語以外ならバッファオーバーフローは起きないのでしょうか？

#6です、話がそれて雑談というか余談に近づいていますが

一般論で書きますね

古典的なパスカルの仕様ならバッファーオーバーフローは発生しないかもしれません。

この回答への補足

>MacがPascal言語で開発されていた

この回答への補足

＞ある説明文では、C言語のメモリー格納仕様に起因する問題、と書かれていました。

No.1さんはOSの不備と言っていますが、多くのバッファオーバーフロー攻撃はOSの用意したバッファじゃなくアプリケーションが用意したバッファを溢れさせてアプリケーションを乗っ取るものです。

C言語に限った話ではないですが、C言語では任意のアドレスのメモリにアクセスできるのでそういう説明になりましたかね。

似たような質問が見つかりました

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング