オープンソースソフトウェアの脆弱性、2019年は前年から50％近く増加したとの調査結果 58
ストーリー by headless
増加 部門より
増加 部門より
WhiteSourceの年次報告書「The State of Open Source Security Vulnerabilities」によると、2019年に報告されたオープンソースソフトウェアの脆弱性は前年から50%近く増加していたそうだ(BetaNewsの記事、 The Registerの記事)。
データはWhiteSourceがNVD(National Vulnerability Database)のほか、セキュリティアドバイザリやピアレビュー型の脆弱性データベース、バグトラッカーから収集したもので、2019年のオープンソースソフトウェアの脆弱性は6,000件を超えているという。オープンソースソフトウェアの脆弱性は85%が公表時点で修正されている一方、NVDに掲載されるのは84%にとどまる。当初はNVDに報告されないものも45%にのぼり、29%はいずれNVDに掲載されるものの数か月のタイムラグがあるとのこと。
オープンソースソフトウェアの脆弱性で最も多いのはCで書かれたものだ。ただし、2009年～2018年のデータでは脆弱性の47%を占めていたのに対し、2019年は30%まで減少している。一方、PHPは15%から27%に増加した。脆弱性の種類ではC以外の言語(C++/Java/JavaScript/PHP/Python/Ruby)でXSS(CWE-79)が最多、不適切な入力確認(CWE-20)と情報漏洩(CWE-200)が続く(Rubyのみ逆順)のに対し、Cではバッファーエラー(CWE-119)・領域外読み込み(CWE-125)・NULLポインター参照(CWE-476)の順になっている。
データはWhiteSourceがNVD(National Vulnerability Database)のほか、セキュリティアドバイザリやピアレビュー型の脆弱性データベース、バグトラッカーから収集したもので、2019年のオープンソースソフトウェアの脆弱性は6,000件を超えているという。オープンソースソフトウェアの脆弱性は85%が公表時点で修正されている一方、NVDに掲載されるのは84%にとどまる。当初はNVDに報告されないものも45%にのぼり、29%はいずれNVDに掲載されるものの数か月のタイムラグがあるとのこと。
オープンソースソフトウェアの脆弱性で最も多いのはCで書かれたものだ。ただし、2009年～2018年のデータでは脆弱性の47%を占めていたのに対し、2019年は30%まで減少している。一方、PHPは15%から27%に増加した。脆弱性の種類ではC以外の言語(C++/Java/JavaScript/PHP/Python/Ruby)でXSS(CWE-79)が最多、不適切な入力確認(CWE-20)と情報漏洩(CWE-200)が続く(Rubyのみ逆順)のに対し、Cではバッファーエラー(CWE-119)・領域外読み込み(CWE-125)・NULLポインター参照(CWE-476)の順になっている。
ともあれ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)
ダメなプログラムを書いた責任を言語に擦り付けるようじゃ何使ってもダメでしょ
チンパンジーがキーボードを乱打しても正常なプログラムが書けるような言語があるなら話は別だけど
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)
無限の猿に無限時間書かせればばいずれ意味解析通るので正常がなにか定義しないとダメ。
Re: (スコア:0)
正常をどう定義したところで無限の数の猿に無限の時間タイプさせれば意味解析も構文チェッカも通るでしょ。
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)
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言語である以上、どうあがいても無理。
自動テストツールが充実してきたせいでは? (スコア:0)
バグトラッカーには、リリース前に自動テストツールによって検出され自動的に登録されるバグやが大量に含まれていると思われる。
そもそも、リリース前のバグもカウントするべきなのか。
公開のリポジトリにコミットされたらリリースしたと扱うの?
邪悪なM$製品は危険(笑) (スコア:0, 荒らし)
OSSなら安心(爆笑)
Re: (スコア:0)
修正されない脆弱性の方が危険
Re: (スコア:0)
修正したのに文句垂れてるゴミがいる [srad.jp]んだが
× 脆弱性、2019年は前年から50％近く増加したとの調査結果 (スコア:0)
○ 脆弱性の定義、2019年は前年から50％近く増加したとの調査結果
Re: (スコア:0)
昔の人の方が健康的だったって信じている人がいるけれど、今の方が圧倒的に健康的。
自動車や船舶なんかも圧倒的に今の方が安全だけど、なぜか信じない人が多い。
それに似てる。
アプリにバグがあっても利用されない環境を作ったほうがいい (スコア:0)
たとえば、iPhoneは、アプリにバグがあっても、そのバグをハッカーが利用するのが難しい
同じく、rootも勝手アプリも開放してないAndroidも同様
サーバOSも、アプリにバグがあってもそれをハッカーが利用するのが難しい環境を作ったほうがいいのでは？
Re: (スコア:0)
人はなぜSELinuxを無効化してしまうのか……
Re: (スコア:0)
restorecon / -R
してもいいから有効化しろ
と言ってくれる人が居ないからでは？
「コンテキストはデフォルト設定」固定！
でもいいから、
SELinuxは有効にした方が良いと
権威のある人が言い切ってくれたら
良かったと思う。
（私は、個人的に構築したCentOSでは、全部やっているが。。。）
Re: (スコア:0)
アップアーマーを使うからさ
MS環境の場合は (スコア:0)
WindowsのAPIに、昔のgets的なインタフェースの奴がごろごろあるので
言語以前の問題がある。
そこらへんをFIXしたら互換性で阿鼻叫喚になるはず。