アカウント名:
パスワード:
Cではバッファーエラー(CWE-119)・領域外読み込み(CWE-125)・NULLポインター参照(CWE-476)の順になっている。
他の言語ではそもそも脆弱性になりえないから…と思ったが、ここではC++も「他の言語」なのか。みんな意外とC++の機能をちゃんと使っているということか
ちなみに python ruby php などはC言語で実装されています
C言語が滅ぶことは当面無いと思われます
セルフホスティングできるようになれば解決!?
話を矮小化するなセルフホスティング可能云々じゃないだろまずOSもなにもない全くの新しいプロセッサを開発したとしてそのプロセッサ用にC言語用のクロス環境を作ることは容易いだろうがそれ以外の言語で同じことが可能な言語があるのか?って話よ
C以外のほぼすべての言語がそうした状態での使用をそもそも想定できておらず勘違いも甚だしいことになぜかCコンパイラとそのビルドツール一式が存在しているという前提の元にすべてが設計されてんじゃねーの?
PythonでもRubyでもRustでもJavaでもC#でもなんでもいいがCのクロス環境さえない状態でいきなり自身のクロス環境を構築できんの?
Cより普及させたいという願望があるのならそうした願望を持った言語は自身とアセンブラのみですべて記述され容易にクロス環境の構築が可能な程度の移植性は備えていないと話にもならないよCよりも安全性の高いコードの記述が可能か否かなんてのはその後の話
あらゆる言語の中で最もCに近いであろうC++ですらLinusに移植性が低いと何度も切って捨てられてることからもわかるようにそういった用途ではC以外の選択肢がないのが現状CコンパイラをC++で記述してるgccですらその1stステージxg++の記述に使われているのはC言語あなたが認めようと認めまいとね
RustはバックエンドがLLVMだから新規CPUに対応させるのはCとあまり変わらないのではないかと
LLVMがCで書かれているという反論が来そう。実際のところの実装が容易なのはCが他の高級言語に依存しないからというより仕様が単純な上コンパイラ開発になれた人が多いからってだけの話。
ピュアなセルフホスティング目指すならLLVM書き直すんでしょうね
クロス環境は容易に作れるか?から始まったのに長文書いてるうちにセルフホスティングの話に戻っちゃった感じ
> LLVMがCで書かれているという反論が来そう。LLVM以外のバックエンド(Cranelisftのような)でRustのビルドができてようやくセルフホストと言える、のかな。まだあるかな
FORTHなら自身のクロス環境の構築はそれほど難しくない。実際>Cより普及させたいという願望があるのなら>そうした願望を持った言語は自身とアセンブラのみですべて記述されFIG-FORTHなんぞまさにこの形の実装だし。
# せめてANSI FORTHの話をしろよ、という異論は認める
ダメなプログラムを書いた責任を言語に擦り付けるようじゃ何使ってもダメでしょチンパンジーがキーボードを乱打しても正常なプログラムが書けるような言語があるなら話は別だけど
人間の注意力に責任を押し付けるようなやつは何をやってもダメ
ただ、この手の指摘って実害はないけれどコーディング上はだめというものも含まれているからただ統計結果だけだとゴミの評価にしかならないというのが個人的な感想。企業がやってるコーディングのセキュリティチェックなんかがよい例なんじゃないだろうか。ツールの出力結果を成形して貼り付けるだけで中身なんて何も見てないからなあれ。ほんと存在価値がない。まぁ。全部が全部そういう実害のない脆弱性というわけでもないだろうけれど。。。
基本的なことをちゃんと手抜かずにすればいいのにCの場合、めんどくさがってやらないやつが多いという話でもあるんだと思う。手間を惜しまず、手続きさえちゃんとふめば、Cが一番安定した言語だと今でも思うよ。基幹部分を作るのならばの話。
あのさぁ……データの収集元になったNVDや脆弱性データベースって見たことない?そこに「実害はないけれどコーディング上はだめ」というものが含まれていると思う?
例えばポインタの存在しないプログラムで同じように初期化や値チェックが雑なプログラムを組んだらNULLポで落ちない代わりによくわからない想定外の動作をするプログラムになるだけでしょ?バッファーオーバランでセキュリティリスクになるよりはランタイムエラーで落ちる方が良いとか?注意力に限界はあるしプログラムにバグが発生するのはあたりまえそれをテストデバッグせずに言語が悪いと言う人はプログラマーに向いてない※注意力散漫でもバグが無いプログラムを作れる言語なりシステムがあるなら教えてほしい
Cでも初期化や値チェックがだめでよいわけじゃないので、なんの比較にもなっていない。
バグが完全に無くならないかぎり、少なくしようとするのに意味はないという意見には賛成できない。
例えばポインタの存在しないプログラムで同じように初期化や値チェックが雑なプログラムを組んだらNULLポで落ちない代わりによくわからない想定外の動作をするプログラムになるだけでしょ?バッファーオーバランでセキュリティリスクになるよりはランタイムエラーで落ちる方が良いとか?
例えば流行りのRustなら、ランタイムエラーどころか、そもそもビルドを通さない仕組みがいくつかあるよな。レースコンディションとかはきっちり叱ってくれる。解放済みのポインタの使用も。何もないよりは、こっちの方が断然良い。
注意力に限界はあるしプログラムにバグが発生するのはあたりまえ
そう。それを言語がカバーして叱ってくれるんだぜ。やっぱり言語の選択は重要よ。
言語側でカバーして、文法レベルでエラーにしてくれるのが良いのはもちろんだが、Cは最近の静的解析使えばかなり改善する。いまどきの静的解析はとても優秀で一昔前だとリソース的に無理だったような、そこまでの実行パスで取りうる値を網羅的にチェックしてくれたりするんだよな。解放済みのポインタ参照なんか当たり前のように検出してくれる。valgrindはもう無くていいレベル
組み込み業界は秀丸やサクラエディタ使ってりゃマシな方でひどいとメモ帳ですよ。解析ツールなんて予算が降りません。
よし、ベターなCを作って名前に+でも加えよう
おまえのではまだ不足だから、俺がさらに改善して名前にもう一個+を加えとくわ。
ソースを読まずにお前が悪いと言う人はスラドに向いてない。Pythonは人気が高いにも関わらず脆弱性の割合が低いってことが書いてあるぞ。
Pythonでポインタとか使えたっけ?
低レベルな操作ができない(あるいはできることが少ない)言語は、それに起因した脆弱性は減るよ。それは特性の問題で、言語の良し悪し(や、ユーザーの良し悪し)とは、直接関係ははない。
かといって低レベルな操作が仕様にない言語だけになると、その辺やるのにいきなり機械語書くのか?みたいな問題になるから、たとえ脆弱性を作りこみやすいとしても、低レベル操作が可能な言語は必要だ。
# 包丁とミキサーなら包丁のほうが負傷事故は起きやすいが、じゃあ包丁がいらないかと言えばそんなことはない
言語特性起因の脆弱性が(言語内でも言語外でも)トップにきてる時点で、セイフティが存在しないか役に立ってない残念言語ってことにならない?
# ミキサーの負傷事故が少ないのは、指をミキサーに突っ込んだ状態で# 動かないようにするとか、絶縁して漏電しないように安全性が考慮されているから
で、ミキサーで野菜の皮を剥いたり、生魚の鱗を取ったり、エビの背腸をとったり、食肉をダイスカットできるわけ?
機能を制限すればリミッターや安全装置はつけられるけど、その分、汎用性は失われる。その汎用性が必要なときに、仕方なくリミッターや安全装置がない道具を使わざるを得ないこともある。そこにリミッターも安全装置もないのは欠陥ではないよ。汎用性を維持するために付けられなかっただけ。
LinuxというカーネルはgccのC言語拡張を使ってて、OpenMandrivaの人たちなんかがパッチを当ててclangでビルドできるようにしていると聞いているけど、C言語は野菜の皮を剥けるのか剥けないのかどっち側なんでしょ?
データベース関係だと、コンパイル結果がCのソースになるプログラム言語というかコンバータというかがありますけど、素のCの作法にしなかったのは生魚の鱗が取りづらいんからじゃないかなあ。
無限の猿に無限時間書かせればばいずれ意味解析通るので正常がなにか定義しないとダメ。
正常をどう定義したところで無限の数の猿に無限の時間タイプさせれば意味解析も構文チェッカも通るでしょ。
一体いつから正常なプログラムが有限と錯覚していた?
元コメは無限が2つあるので、正常なプログラムが無限でも別に発散したりしないのでは
無限の猿は日常的な感覚で言えば可算無限集合にしかならないでしょ?
# どんな日常だ
正常なプログラムを全部猿がかけるって話ではないでしょ
無限の話なので「全部」という概念が適切かはわからないけど、「任意」の正常の定義について猿がプログラムを書けるという主張でしょ?空やコメントだけのプログラムは大抵有効なプログラムなので、特定の正常なプログラムを有限の猿が書けることは自明でしょう。
そりゃシェアが高ければ件数も多いわなとっととRustとやらをC以上に普及させてね
https://wired.jp/2018/08/18/apple-swift-android-kotlin-rankings/ [wired.jp]2018年の時点で、タレコミに出てくる他のどの言語よりもシェアが低いようだが
WIREDで取り上げられてるのはシェアランキングではなくGitHubとStack Overflowから抽出した人気言語ランキング。
WhiteSourceの年次報告書では"C still has the highest percentage of vulnerabilities due to the high volume of code written in this language."(Cは、この言語で記述された大量のコードのために、依然として脆弱性の割合が最も高くなっています。)と分析している。
おそらく、Cの割合が依然として高いのはGNU/Linuxの影響で、PHPの割合が15%から27%に増加したのはWordPressの影響。
RustをC以上に普及させるもなにもそもそもRustがCで書かれたLLVMの上に乗ってる以上机上の空論だろLLVMを使うのを止めすべてをRustで書くか、LLVMをRustで書けと
LLVM は C ではなくて C++ で書かれているのでは。
そもそもRust を C 以上に普及させるということはRust 以外の使用を認めないということではないのでRust で書かれていない LLVM を使うのをやめる必要もないしC を滅ぼす必要もないよね。
OSにしても、コアの部分はCも必要不可欠だろうけれど、大半はJavaやC#のような保護された高級言語によって記述されるべきなんだよね。そろそろバフォーマンス的にも問題がなくなってきているし。Linuxにいまだ標準的なOS記述向け保護機能付き高級言語が無いのは良くない。
ヌルポの脆弱性ってどんなの?SEGっても呼び出し側プロセスかなんかのレベルで粘り腰プログラムが不正な処理を続けるとか?
外部から意図的にSEGらせてサービス運用妨害(DoS)できること自体が脆弱性
> ヌルポの脆弱性ってどんなの?
ちゃんと「NULLポインター参照(CWE-476) 」と書いてあるじゃないですか
質問する前に CWE-476 を読みましょう
http://cwe.mitre.org/data/definitions/476.html [mitre.org]
私がcプログラマを神聖視(尊敬)してphpとかを憎んでいるのもあるが、それを差し引いても実装者のやらかし的な脆弱性に限定すればcはマシな部類なんじゃないかと思う。
何年か前だと、ifがコードブロックも式も受け付けるというのと、gotoというラベルを書けばOKな機能とが相まって、goto failしちゃうというのがありましたね。
仮定の話ですが、失敗の理由にはこういうコードを追いかけるのがめんどくさいのというのがあると思うので、ifがどちらかしか受け付けなかったり、gotoがなかったりすればプログラマなりコンパイラなりが気づけたのかもしれません。
PHPがそうかどうかは知らないですけれど。
ランタイムやその他足回りがC言語である以上、どうあがいても無理。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
ともあれC言語は滅びるべきである (スコア:0)
他の言語ではそもそも脆弱性になりえないから…と思ったが、ここではC++も「他の言語」なのか。みんな意外とC++の機能をちゃんと使っているということか
Re:ともあれC言語は滅びるべきである (スコア:1)
ちなみに python ruby php などはC言語で実装されています
C言語が滅ぶことは当面無いと思われます
Re: (スコア:0)
セルフホスティングできるようになれば解決!?
Re:ともあれC言語は滅びるべきである (スコア:2, 参考になる)
話を矮小化するな
セルフホスティング可能云々じゃないだろ
まずOSもなにもない全くの新しいプロセッサを開発したとして
そのプロセッサ用にC言語用のクロス環境を作ることは容易いだろうが
それ以外の言語で同じことが可能な言語があるのか?って話よ
C以外のほぼすべての言語がそうした状態での使用をそもそも想定できておらず
勘違いも甚だしいことになぜかCコンパイラとそのビルドツール一式が存在している
という前提の元にすべてが設計されてんじゃねーの?
PythonでもRubyでもRustでもJavaでもC#でもなんでもいいが
Cのクロス環境さえない状態でいきなり自身のクロス環境を構築できんの?
Cより普及させたいという願望があるのなら
そうした願望を持った言語は自身とアセンブラのみですべて記述され
容易にクロス環境の構築が可能な程度の移植性は備えていないと話にもならないよ
Cよりも安全性の高いコードの記述が可能か否かなんてのはその後の話
あらゆる言語の中で最もCに近いであろうC++ですら
Linusに移植性が低いと何度も切って捨てられてることからもわかるように
そういった用途ではC以外の選択肢がないのが現状
CコンパイラをC++で記述してるgccですらその1stステージxg++の記述に使われているのはC言語
あなたが認めようと認めまいとね
Re: (スコア:0)
RustはバックエンドがLLVMだから新規CPUに対応させるのはCとあまり変わらないのではないかと
Re: (スコア:0)
LLVMがCで書かれているという反論が来そう。
実際のところの実装が容易なのはCが他の高級言語に依存しないからというより仕様が単純な上コンパイラ開発になれた人が多いからってだけの話。
Re: (スコア:0)
ピュアなセルフホスティング目指すならLLVM書き直すんでしょうね
クロス環境は容易に作れるか?から始まったのに長文書いてるうちにセルフホスティングの話に戻っちゃった感じ
Re: (スコア:0)
> LLVMがCで書かれているという反論が来そう。
LLVM以外のバックエンド(Cranelisftのような)でRustのビルドができてようやくセルフホストと言える、のかな。まだあるかな
Re: (スコア:0)
FORTHなら自身のクロス環境の構築はそれほど難しくない。実際
>Cより普及させたいという願望があるのなら
>そうした願望を持った言語は自身とアセンブラのみですべて記述され
FIG-FORTHなんぞまさにこの形の実装だし。
# せめてANSI FORTHの話をしろよ、という異論は認める
Re: (スコア:0)
ダメなプログラムを書いた責任を言語に擦り付けるようじゃ何使ってもダメでしょ
チンパンジーがキーボードを乱打しても正常なプログラムが書けるような言語があるなら話は別だけど
Re:ともあれC言語は滅びるべきである (スコア:1)
人間の注意力に責任を押し付けるようなやつは何をやってもダメ
Re: (スコア:0)
ただ、この手の指摘って実害はないけれどコーディング上はだめというものも含まれているから
ただ統計結果だけだとゴミの評価にしかならないというのが個人的な感想。
企業がやってるコーディングのセキュリティチェックなんかがよい例なんじゃないだろうか。
ツールの出力結果を成形して貼り付けるだけで中身なんて何も見てないからなあれ。ほんと存在価値がない。
まぁ。全部が全部そういう実害のない脆弱性というわけでもないだろうけれど。。。
基本的なことをちゃんと手抜かずにすればいいのに
Cの場合、めんどくさがってやらないやつが多いという話でもあるんだと思う。
手間を惜しまず、手続きさえちゃんとふめば、Cが一番安定した言語だと今でも思うよ。
基幹部分を作るのならばの話。
Re: (スコア:0)
あのさぁ……データの収集元になったNVDや脆弱性データベースって見たことない?
そこに「実害はないけれどコーディング上はだめ」というものが含まれていると思う?
Re: (スコア:0)
例えばポインタの存在しないプログラムで同じように初期化や値チェックが雑なプログラムを組んだらNULLポで落ちない代わりによくわからない想定外の動作をするプログラムになるだけでしょ?
バッファーオーバランでセキュリティリスクになるよりはランタイムエラーで落ちる方が良いとか?
注意力に限界はあるしプログラムにバグが発生するのはあたりまえ
それをテストデバッグせずに言語が悪いと言う人はプログラマーに向いてない
※注意力散漫でもバグが無いプログラムを作れる言語なりシステムがあるなら教えてほしい
Re: (スコア:0)
Cでも初期化や値チェックがだめでよいわけじゃないので、なんの比較にもなっていない。
バグが完全に無くならないかぎり、少なくしようとするのに意味はないという意見には
賛成できない。
Re: (スコア:0)
例えば流行りのRustなら、ランタイムエラーどころか、そもそもビルドを通さない仕組みがいくつかあるよな。
レースコンディションとかはきっちり叱ってくれる。解放済みのポインタの使用も。
何もないよりは、こっちの方が断然良い。
そう。
それを言語がカバーして叱ってくれるんだぜ。やっぱり言語の選択は重要よ。
Re: (スコア:0)
言語側でカバーして、文法レベルでエラーにしてくれるのが良いのはもちろんだが、Cは最近の静的解析使えばかなり改善する。
いまどきの静的解析はとても優秀で一昔前だとリソース的に無理だったような、そこまでの実行パスで取りうる値を網羅的にチェックしてくれたりするんだよな。解放済みのポインタ参照なんか当たり前のように検出してくれる。
valgrindはもう無くていいレベル
Re: (スコア:0)
組み込み業界は秀丸やサクラエディタ使ってりゃマシな方でひどいとメモ帳ですよ。
解析ツールなんて予算が降りません。
Re: (スコア:0)
よし、ベターなCを作って名前に+でも加えよう
Re: (スコア:0)
おまえのではまだ不足だから、俺がさらに改善して名前にもう一個+を加えとくわ。
Re:ともあれC言語は滅びるべきである (スコア:1)
Re: (スコア:0)
ソースを読まずにお前が悪いと言う人はスラドに向いてない。
Pythonは人気が高いにも関わらず脆弱性の割合が低いってことが書いてあるぞ。
Re: (スコア:0)
ソースを読まずにお前が悪いと言う人はスラドに向いてない。
Pythonは人気が高いにも関わらず脆弱性の割合が低いってことが書いてあるぞ。
Pythonでポインタとか使えたっけ?
低レベルな操作ができない(あるいはできることが少ない)言語は、それに起因した脆弱性は減るよ。
それは特性の問題で、言語の良し悪し(や、ユーザーの良し悪し)とは、直接関係ははない。
かといって低レベルな操作が仕様にない言語だけになると、その辺やるのにいきなり機械語書くのか?みたいな問題になるから、たとえ脆弱性を作りこみやすいとしても、低レベル操作が可能な言語は必要だ。
# 包丁とミキサーなら包丁のほうが負傷事故は起きやすいが、じゃあ包丁がいらないかと言えばそんなことはない
Re: (スコア:0)
言語特性起因の脆弱性が(言語内でも言語外でも)トップにきてる時点で、
セイフティが存在しないか役に立ってない残念言語ってことにならない?
# ミキサーの負傷事故が少ないのは、指をミキサーに突っ込んだ状態で
# 動かないようにするとか、絶縁して漏電しないように安全性が考慮されているから
Re: (スコア:0)
で、ミキサーで野菜の皮を剥いたり、生魚の鱗を取ったり、エビの背腸をとったり、食肉をダイスカットできるわけ?
機能を制限すればリミッターや安全装置はつけられるけど、その分、汎用性は失われる。
その汎用性が必要なときに、仕方なくリミッターや安全装置がない道具を使わざるを得ないこともある。
そこにリミッターも安全装置もないのは欠陥ではないよ。汎用性を維持するために付けられなかっただけ。
Re: (スコア:0)
LinuxというカーネルはgccのC言語拡張を使ってて、OpenMandrivaの人たちなんかがパッチを当ててclangでビルドできるように
していると聞いているけど、C言語は野菜の皮を剥けるのか剥けないのかどっち側なんでしょ?
データベース関係だと、コンパイル結果がCのソースになるプログラム言語というかコンバータというかがありますけど、
素のCの作法にしなかったのは生魚の鱗が取りづらいんからじゃないかなあ。
Re: (スコア:0)
無限の猿に無限時間書かせればばいずれ意味解析通るので正常がなにか定義しないとダメ。
Re: (スコア:0)
正常をどう定義したところで無限の数の猿に無限の時間タイプさせれば意味解析も構文チェッカも通るでしょ。
Re: (スコア:0)
一体いつから正常なプログラムが有限と錯覚していた?
Re: (スコア:0)
元コメは無限が2つあるので、正常なプログラムが無限でも別に発散したりしないのでは
Re: (スコア:0)
無限の猿は日常的な感覚で言えば可算無限集合にしかならないでしょ?
# どんな日常だ
Re: (スコア:0)
正常なプログラムを全部猿がかけるって話ではないでしょ
Re: (スコア:0)
無限の話なので「全部」という概念が適切かはわからないけど、「任意」の正常の定義について猿がプログラムを書けるという主張でしょ?
空やコメントだけのプログラムは大抵有効なプログラムなので、特定の正常なプログラムを有限の猿が書けることは自明でしょう。
Re: (スコア:0)
そりゃシェアが高ければ件数も多いわな
とっととRustとやらをC以上に普及させてね
Re: (スコア:0)
https://wired.jp/2018/08/18/apple-swift-android-kotlin-rankings/ [wired.jp]
2018年の時点で、タレコミに出てくる他のどの言語よりもシェアが低いようだが
Re: (スコア:0)
WIREDで取り上げられてるのはシェアランキングではなくGitHubとStack Overflowから抽出した人気言語ランキング。
WhiteSourceの年次報告書では"C still has the highest percentage of vulnerabilities due to the high volume of code written in this language."(Cは、この言語で記述された大量のコードのために、依然として脆弱性の割合が最も高くなっています。)と分析している。
おそらく、Cの割合が依然として高いのはGNU/Linuxの影響で、PHPの割合が15%から27%に増加したのはWordPressの影響。
Re: (スコア:0)
RustをC以上に普及させるもなにも
そもそもRustがCで書かれたLLVMの上に乗ってる以上机上の空論だろ
LLVMを使うのを止めすべてをRustで書くか、LLVMをRustで書けと
Re: (スコア:0)
LLVM は C ではなくて C++ で書かれているのでは。
そもそも
Rust を C 以上に普及させるということは
Rust 以外の使用を認めないということではないので
Rust で書かれていない LLVM を使うのをやめる必要もないし
C を滅ぼす必要もないよね。
Re: (スコア:0)
OSにしても、コアの部分はCも必要不可欠だろうけれど、大半はJavaやC#のような保護された高級言語によって記述されるべきなんだよね。
そろそろバフォーマンス的にも問題がなくなってきているし。
Linuxにいまだ標準的なOS記述向け保護機能付き高級言語が無いのは良くない。
Re:ともあれC言語は滅びるべきである (スコア:1)
Re: (スコア:0)
ヌルポの脆弱性ってどんなの?
SEGっても呼び出し側プロセスかなんかのレベルで粘り腰プログラムが不正な処理を続けるとか?
Re: (スコア:0)
外部から意図的にSEGらせてサービス運用妨害(DoS)できること自体が脆弱性
Re: (スコア:0)
> ヌルポの脆弱性ってどんなの?
ちゃんと「NULLポインター参照(CWE-476) 」と書いてあるじゃないですか
質問する前に CWE-476 を読みましょう
http://cwe.mitre.org/data/definitions/476.html [mitre.org]
Re: (スコア:0)
私がcプログラマを神聖視(尊敬)してphpとかを憎んでいるのもあるが、それを差し引いても実装者のやらかし的な脆弱性に限定すればcはマシな部類なんじゃないかと思う。
Re: (スコア:0)
何年か前だと、ifがコードブロックも式も受け付けるというのと、gotoというラベルを書けばOKな機能とが相まって、
goto failしちゃうというのがありましたね。
仮定の話ですが、失敗の理由にはこういうコードを追いかけるのがめんどくさいのというのがあると思うので、
ifがどちらかしか受け付けなかったり、gotoがなかったりすればプログラマなりコンパイラなりが気づけたのかもしれません。
PHPがそうかどうかは知らないですけれど。
Re: (スコア:0)
ランタイムやその他足回りがC言語である以上、どうあがいても無理。