Chromiumプロジェクト、重大度の高いセキュリティバグの約70％がメモリに由来すると発表 60
世の中全体でもそんな感じな気もする 部門より
Anonymous Coward曰く、
Chromiumプロジェクトは今週、重大度の高いセキュリティバグの約70％は、メモリの安全性に関する問題（ポインタの誤り）に由来すると発表した。これはGoogleのエンジニアが2015年以降の912の重大度の高い、もしくは重大なセキュリティバグを分析した結果から導き出させたものだという。これはユーザーのセキュリティを危険にさらすだけでなく、Chromeの修正と出荷においてコストを増大させているとしている。
同様の問題はMicrosoftも指摘している。2019年2月のセキュリティ会議で講演したMicrosoftのエンジニアは過去12年間、Microsoft製品のすべてのセキュリティアップデートの約70％がメモリの安全性が原因だったと指摘している。端的に言えば、コードベースで2つの主要なプログラミング言語であるCとC++は「安全でない」言語であるということになる。
Googleによると2019年3月以降、重大度の高いChrome脆弱性130個のうち、125はメモリ破損に関連する問題だった。他のバグクラスの修正が進んだにもかかわらず、メモリ管理が依然として問題であるとしている。Mozillaは、CおよびC++の修正をするのをあきらめ、FirefoxでRustプログラミング言語を後援、促進、大幅に採用することで大きな進歩を遂げた。MicrosoftもCおよびC++の代替に多大な投資をしている。
今週、Googleも同様の計画を発表した。今後、Googleは、メモリ関連のバグに対する保護を強化したライブラリであるカスタムC++ライブラリの開発を検討する予定であると述べている。またGoogleは可能な限り「安全な」言語の使用を検討する計画があるとも述べている。候補には、Rust、Swift、JavaScript、Kotlin、およびJavaが含まれているようだ（The Chromium Projects、Slashdot）。
OpenBSDが。 (スコア:2)
っていうか、Theo君が、はるか昔に言ってなかったっけ、そんなこと。
# てれっててれっててー --- macohime(#cpdz)
そんな (スコア:1)
// 測定したことに意味があるのですよ!
ポインタ (スコア:0)
ポインタでメモリを直接操作するのが危険みたいな話だからな。ライブラリを強化したところで、ポインタで自由にメモリにアクセスできる時点で危険性は残る。
アジャイル系の言語でランタイムモジュールでメモリ領域を管理するようなものでなければ大なり小なり問題がある。
そりゃリッチ資源環境なら保護付き使うべき (スコア:1)
わたしゃC/C++しかまともに使えないので組み込み界隈で飯食ってます
もうPC界隈ではネイティブコードに無鑑査で落ちる言語を使うことは
悪とされるようになるのかもしれない。
# デバイスドライバさえも???
Re: (スコア:0)
Rustが好評と実績を得ているが、贔屓にしているC++が負けるのは正直いって悔しいｗ
Rustで得られたメモリ管理パラダイムが、C++(の規格か、実装)に取り入れられることを期待している。
ていうか、数学の得意な人がやれば、今でもできそうなもんなんだが、やらない理由があるんだろうか。
Re: (スコア:2, すばらしい洞察)
「人間は間違える」を前提にするとC/C++は本当にクソなので滅びるべき
Rustで得られた知見がC++にフィードバックされようが、メモリ管理の誤りは人間がコードを書く限りは発生する
だからこそ、安全な言語が使われるべき
Re: (スコア:0)
メモリ管理の問題を作りこめる問題は克服できると信じてるが、C++を無茶苦茶に使うヤツは多いからな、いっそ滅びろってのはわかる。
どうとでも書けるからって、どう書いてもいいわけじゃないと思うんだ。
strcpy_s()みたいなやつ (スコア:0)
古くから＆今でもよく使われているものなのに「互換性を維持しながら安全性を確保するのは無理なので、より安全な代替を用意したからそっちを使って」とするしかないものはたくさんあると思う。
依存関係の上流側にあるものを更新するコストとリスクはでかいからねぇ。
Re: (スコア:0)
Perl「お、おぅ・・・」
Re: (スコア:0)
Perlが業務用途で廃れたのって「どう書いてもいいから」だろうね。
粒ぞろいのエンジニアだけで開発するならこれほど効率がいい言語はないと今でも思ってるが、
VBA感覚で書く素人が大量にいるのでデメリットの方が大きい。
バージョン間の互換性も高いせいでメンテ不能に陥ってる社内システムって相当残ってる気がするぞ。
Re: (スコア:0)
C++ はあまりに多機能なため、解析ツールとの相性が悪い。
安全な言語を使うべきだが、そうでなければ C++ でなく Cを使って静的、動的解析ツールでバグを防止した方がましだと思う。
Re: (スコア:0)
未熟なプログラマが悪いのであってC++は悪くないよ
Re: (スコア:0)
書いた通りにしか動かないという観点からはC++がクソという意見には同意しかねるね。
Re: (スコア:0)
未熟でないC++erって聞いたことないんだけど。
あの言語は、深部に行けば行くほど初心者になっていく。
Re: (スコア:0)
でも元記事はメモリ破壊とか言ってるぞ？
テンプレートがどうとか型推論がどうとか、そんなんじゃない。
きちんとエラーチェックして、しっかり排他処理して、生ポインタ使わずに済むようにクラスにまとめて、とかその程度でいい。
C++のエキスパートでなくても、普通のプログラマなら普通にできることだよ。
Re: (スコア:0)
それがちゃんとできてりゃ、標題のようなことには、なってないわけだ。
なんだかんだで。ってやつ。自戒も込める。
その上、さらに、Rustのように、もっともっとコンパイラが仕事するべきだ。
Re: (スコア:0)
Cは滅ぶべきなんて言われてもう30年くらい経過してる気がするけど、代替になる言語がないので仕方ない。
高級言語みたいに書けるアセンブラって他にあるか？
Re: (スコア:0)
今、汗は不人気だが欠かせないように、C/C++もその位置に向かうのかもね。となら、アンチにも言えるな。
ただ、Rustに負けっぱなしも悔しいので、まだまだがんばってもらいたい。
Re: (スコア:0)
個人的には、C++がクソは同意。Cはさほどでもない。
とにかく好きにさせろや、という時には結局Cがいい。安全なプログラム書きたいという時にはC++は余計なことができすぎる。
Re: (スコア:0)
御託はいいからさっさとC++を滅ぼして見せてほしいですね。
私は理想より現実のほうが好きなので。
Re: (スコア:0)
危ない仕事そのものを忌避して担い手のC++を悪者にしてるうちは無理だろうな
Re: (スコア:0)
用途次第だから、滅びろとまでは思わない。
1%のバグがあっても、99%の確率で2割高速に動作することに意味がある場合もある。
リスクは用途ごとに得られる利益と天秤にかけて議論すべきであって、C/C++は全部だめとかRustは使えないなんて、用途を限定せず話すのは意味が無い。
Re: (スコア:0)
C++ってunsafeな処理を指定した関数に限定するコードチェッカとか作れないのかね。
作れないのかそれとも、今でも想定外のメモリバグを可能な限り根絶したいとまでは思っていないというのがC++のスタンスなのだろうか。
Re: (スコア:2)
CならMicrosoftのChecked Cとか。
https://github.com/Microsoft/checkedc [github.com]
Re: (スコア:0)
その思想でやったのがC#なんじゃね?
Re: (スコア:0)
C# は C系統じゃないと何度言ったら判るのか
Re: (スコア:0)
C# は C系統じゃないと何度言ったら判るのか
マイクロソフト自身が「C++に更に++を足してC#だ」って言っているのに？
++
++
で#
Re: (スコア:0)
C#はシステム的には.NET wrapperだからな。
Low Level LanguageのC/C++とは系統が違うよ。
Re: (スコア:0)
そんな思想あったっけ？
メモリを比較的安全に使えるようにガーベージコレクション使ってるけど
強参照だと状況によっては普通にメモリリークするし
あとC#もunsafeな処理は可能
Re: (スコア:0)
c++/cliでいいのでは。死にそうな言語だけど。
メモリ以外のセキュリティ問題 (スコア:0)
あえて脆弱性を入れ込むとかでなければメモリ以外のセキュリティ問題って滅多にない気がする
・仕様に由来するセキュリティ（WebGL 問題みたいなの）
・API のパラメータの取り違えなど
ぐらい？
結局重大度の高い問題って「任意コードの実行」「メモリの読み取り」が大半だと思うので、メモリ起因がほとんどだよね
# とはいえ、「安全な」言語の使用って今以上にメモリ喰いしそうで嫌だな
Re:メモリ以外のセキュリティ問題 (スコア:1)
// 調べなくても済む問題は調べずに「いかにすませるか」が最適化の鍵だったりするのだ
Re: (スコア:0)
いかに事前に済ませるか、だよな。
C++だって、全機能がいつも最先端だったわけじゃない。他言語の「あれいいなあ」と思うものを、少しずつ取り込んで今がある。
Rustが大成功を収めつつあり、「何がよかったのか」がプログラミング哲学的にわかってくる日は近い。
C++の生ポインタにフットプリント0のトレイトを付与することは可能だと思うので、Rustの知見を取り込める日も来ると思う。
Re: (スコア:0)
30%あることを滅多にないと表現するのは、とても違和感があります
Re:メモリ以外のセキュリティ問題 (スコア:1, 参考になる)
ご指摘ごもっとで、感覚と違いすぎるなと思い残りの 3 割について調べてみました
Severity Guidelines for Security Issues [googlesource.com]
細かい内訳はないのでこれがどの程度の比率かは不明ですが、XSS などポリシー外で情報を読めてしまうものも重大度が高いとして扱われていました
確かに読まれたくない情報もあるし、クレジット番号など機密度の高い情報もあるのでこれも重大度の高い問題ですね
Re: (スコア:0)
Apple案件でセミコロンが一個多かったか閉じ括弧が一個抜けてたかで判別ロジックが腐った
っていうのがなかったっけ
Re:メモリ以外のセキュリティ問題 (スコア:1)
かの有名な goto fail 問題ですね
iOS7.0.6で修正された「最悪のセキュリティバグ」はありがちなコーディングミスで発生していた [apple.srad.jp]
コーディング規約で「必ずブロック化すること、理由はコレ」
って書いても単行の場合は中括弧省略する人が多いのツライ
Re: (スコア:0)
そりゃ、中括弧を省略したことが問題の本質じゃないことを理由にしたって
納得するわけないじゃないの
そりゃそうだろう (スコア:0)
ブラウザの処理でレンダリングにしろ解析や実行にしろ、動的メモリ管理が大きなウェイトを占めているわけだし
巨大なアプリには無理ゲー (スコア:0)
個人ベースでソースの隅々まで把握してる小さなアプリならともかく、
巨大なアプリでは誰も全体像を把握できてないし、
そういう環境でC/C++はヤバいと思う。
組み込みならともかくPCやスマホ向けアプリの開発で
アドレスを直でいじる言語は、もうキツいだろう。
Re: (スコア:0)
それは別の話なんじゃないかな
DBやファイルへのアクセスすら巨大なアプリは無理ということになっちゃう
いまさらですか (スコア:0)
Javaが安全って(安全の意味が違う
先読み実行 (スコア:0)
データを移動して演算しメモリに書き込み、またデータを移動する
Re: (スコア:0)
Rustの標準ライブラリBoxやVecが生成時そんな感じのモヤモヤする処理してますな
何も調べてないけど (スコア:0)
Goでは書けないの？
JavaScriptが安全？ (スコア:0)
サンドボックス内ならなんでもアリってこと？
Re: (スコア:0)
当然。JavaScriptでメモリ破壊できたらそりゃエンジン側のバグでしょうが。
Re:JavaScriptが安全？ (スコア:1)
「範囲外アクセスしてもエラーにならずそのまま動いてしまうことが危険」という話題なので、範囲外エラーを検出できるのはいいこと。
うじゃうじゃ
Chromeのほとんどのバグを検知するツール (スコア:0)
https://chromereleases.googleblog.com/2020/05/stable-channel-update-fo... [googleblog.com]
Chromeが紹介してるツールをみんなが使いこなすようになればいい
- AddressSanitizer
- MemorySanitizer
- UndefinedBehaviorSanitizer
- Control Flow Integrity
- libFuzzer
- AFL
Re: (スコア:0)
異存はないですが、VC派(VSじゃないよ。コマンドラインから使ってる)なので、もっとVCが追従・実装してほしいって思ってる。