NSA、可能な限りメモリ安全なプログラミング言語を使うことを推奨 105
ストーリー by headless
安全 部門より
安全 部門より
米国家安全保障局 (NSA) は 10 日、メモリ安全性の問題に対応するためのガイダンスを公開し、可能な限りメモリ安全なプログラミング言語を使用するよう推奨した
(プレスリリース、
The Register の記事、
ガイダンス: PDF)。
Microsoft は 2019 年、過去 12 年間の Microsoft 製品の脆弱性は 70 % がメモリ安全性に起因すると述べており、Google も 2020 年に Chromium の重大な脆弱性の 70 % がメモリ安全性に起因すると述べていた。
広く使われているCやC++などの言語はメモリ管理の自由度が高い一方で、必要なメモリ参照の確認はプログラマーに強く依存する。ソフトウェア解析ツールを使用すればある程度の保護は可能になるが、メモリ安全な言語はそれ自体がメモリ管理の問題の多くに対応可能な保護機能を提供する。そのため、可能な場面ではメモリ安全な言語の使用が推奨されるとのこと。メモリ安全な言語の例としては、C#・Go・Java・Ruby・Rust・Swift が挙げられている。
Microsoft は 2019 年、過去 12 年間の Microsoft 製品の脆弱性は 70 % がメモリ安全性に起因すると述べており、Google も 2020 年に Chromium の重大な脆弱性の 70 % がメモリ安全性に起因すると述べていた。
広く使われているCやC++などの言語はメモリ管理の自由度が高い一方で、必要なメモリ参照の確認はプログラマーに強く依存する。ソフトウェア解析ツールを使用すればある程度の保護は可能になるが、メモリ安全な言語はそれ自体がメモリ管理の問題の多くに対応可能な保護機能を提供する。そのため、可能な場面ではメモリ安全な言語の使用が推奨されるとのこと。メモリ安全な言語の例としては、C#・Go・Java・Ruby・Rust・Swift が挙げられている。
当たり前だね (スコア:1)
CやC++は素晴らしいという人も居るけど、セキュリティ的には可能な限り避けるべき代物っていうのは当たり前の話だね。
気を付けたって規模がデカくなればどっかで絶対やらかすのは避けられないと思うのよね。
というか大企業だって著名オープンソースだってやらかしてるのに、お前はきちんとできるというのかと。
組み込みとかなら仕方ないけど。
C#ならunsafe、Javaならsun.misc.Unsafe、その他色々壊せるけどね。
ランタイムや参照してるネイティブのライブラリや実行環境やその他諸々で脆弱性があればどうにもならないというか、それ以前にメモリ安全以外の危険は色々あるけどね。
Re: (スコア:0)
CやC++が素晴らしいのは、だいたいなんでも書けることであって、書こうと思えば無茶苦茶も書ける。
これから起こすプロジェクトでは、制約のきつい言語のほうが安全だろうし、CやC++はその知見を取り込まなければならない。
制約をも記述できてこそ、C++だと自分は思う。
Re: (スコア:0)
アセンブラほど「理屈の上では」ってわけではないが、でも現実的な意味でCやC++で何でも書けるかと言われれば疑問符が付く。
何しろ大規模開発は精神と難易度的に厳しい。
スマホアプリもコンソールツールもウェブアプリもWindows向けアプリもって意味じゃC#だし、スマホやデスクトップ向けアプリでもうちょい良い感じならDartだし、30億のデバイスで走ると言えばJavaだし、その辺も割と何でもと言えるレベルだと思うけどな。
「覚えておいて損はしない」ってのは否定しないけど最新規格や細部まで追うべきかは微妙。
Re: (スコア:1)
> スマホアプリもコンソールツールもウェブアプリもWindows向けアプリもって意味じゃC#だし
今どきはこういうのも、ガチなやつじゃなければ JavaScript でできちゃうからずいぶんハードル下がりましたね。
Re: (スコア:0)
WebGLあるし、ガチなやつでもマルチプラットフォームなものはJavaScriptが増えてるのでは？
Re: (スコア:0)
https://jp.quora.com/kumikomi-shisutemu-deha-doushite-C-ga-C-ni-shu-tt... [quora.com]
組み込み系なら損はないどころかリアルタイム性でも現役
いつかは進歩するだろうけど当面先だろうね
あとはCOBOLみたいに特殊な環境で脆弱性に対処する荒業もw
Re: (スコア:0)
C言語内にインラインアセンブラや、アセンブラコードをマージして使うことで、
その欠点を補ってるのが、OSのカーネルや、デバイスドライバだね
どうしてもアセンブラじゃないと出来ないことや、パフォーマンスのためにアセンブラが必要なところのみ、
アセンブラを使ってる
Re: (スコア:0)
Rustが台頭して、C++は完全にその役目を終えたのでは？
比較すると、C++選ぶメリットがないよね？
Re: (スコア:0)
選ぶことはなくても、既存の資産ってのがあるから(強化は必要)。
極端な話、一晩でひっくり返したようにChromeをRustに移行したりはしないと思うので。
たとえコンバータを書いたとしても。
Re: (スコア:1)
COBOLみたいな立ち位置に落ち着きそうだな。
Re: (スコア:0)
ひとつのアプリを開発するたびにそれ専用のインタプリタを開発していたこともあったんだよ。アプリの大部分はデータとして記述して、その解釈を行う小さいプログラムがあるような作り。そんな作りの場合でも C/C++ よりも何らかのスクリプト言語の方がいいね。
Re: (スコア:0)
そのメモリ安全で防げるもの以外の危険が相対的に少ない、という話なのだが。
Re: (スコア:0)
当たり前だけど「セキュリティ的には可能な限り避けるべき代物」なんかこの物言いには違和感。
C/C++は原理的にメモリ管理のセキュアコーディングは開発者に任されているから、
開発者はその要件が求められるプログラムではセキュアなコーディングが求められるというだけだろう。
どんな開発環境だって開発者に任されている領域は開発者の責務において実装しなければならない。
Re:当たり前だね (スコア:3, 興味深い)
ここは高木先生 [archive.org]を召喚しないと。
Re: (スコア:0)
そもそも今時はメモリ安全なんか、開発者に任せる必要性がないだろ。
無駄に責任を負わせるのは止めようと言う話。
F-35 (スコア:1)
JSFの開発にストラウストラップ御大まで投入してC++を採用
初飛行時は数時間おきにリブートしないとシステムダウン
結局バグはとりきれてないけど、ダウンするまでの時間が最長任務時間をようやく超えたから検収できたとか
Re: (スコア:0)
結局バグはとりきれてないけど、ダウンするまでの時間が最長任務時間をようやく超えたから検収できたとか
OSにMeでも載せてたりするんだろうか
Re: (スコア:0)
MEも遠くなりにけり
Re: (スコア:0)
いえ、インタフェースがFirewireなだけです。
Re: (スコア:0)
タイマの制度を落としました
Re: (スコア:0)
ここでのメモリ安全性はセキュリティバグの話だから別件ですね
Re: (スコア:0)
までというと語弊があるような。 むしろ国防だからこそ参加してくれたと見るべきかもしれない。
Swiftが挙げられてるのに (スコア:0)
Kotlinが挙げられてない可哀想
Re: (スコア:0)
Javaに含んでるでしょ。
Visual BasicやF#と同じ。
Re: (スコア:0)
せんせー、JavascriptはJavaに含まれますか？
# いや、RhinoとかNashornじゃなくてね。
Re: (スコア:0)
JSのメモリ安全性はブラウザの実現次第なので言語仕様的には不問じゃね？
Re: (スコア:0)
JavaScript警察です！ぴぴー！
https://developer.mozilla.org/en-US/docs/Web/JavaScript [mozilla.org]
https://www.w3.org/standards/webdesign/script [w3.org]
Re: (スコア:0)
Rubyが挙げられているのにPythonが挙げられていないほうが不思議
Rubyは標準化されているからかね？
Re: (スコア:0)
GoやRustやSwiftって標準化されてたっけ?
どういうこと？ (スコア:0)
NSAとしては未発見の脆弱性が無いとピーピングトムれないから堅牢は非推奨かと思ったが
問答無用のバックドア手に入れたからもう大丈夫ってことなのかな
Re: (スコア:0)
問答無用のバックドア相当品が次々と現れてNSAでない連中が利用するからじゃないの
Re: (スコア:0)
ポインタや参照を理解できない職員が増えてきたってこと。時代だよ。
C/C++のせいで感覚が麻痺してくるが (スコア:0)
ふつー高級言語ってメモリ安全でないの
Re: (スコア:0)
本当はC/C++だって未定義動作を全部例外飛ばすなりすればメモリ安全な実装も可能だろうが、みんな使いたがらないだろうなあ
Re: (スコア:0)
それjavaじゃん、みんな使ってるよ。
Re: (スコア:0)
言葉の定義で言うなら、CもC++もCOBOLも高級言語。
機械語・アセンブリ言語や同レベルの物を低級(低水準)と言ってた時代に決まった用語だから。
Re:C/C++のせいで感覚が麻痺してくるが (スコア:1)
Re: Re:C/C++のせいで感覚が麻痺してくるが (スコア:0)
現代人の感覚だと高級と低級の中間だから中間言語だよね。
Re: Re: Re:C/C++のせいで感覚が麻痺してくるが (スコア:0)
> 現代人の感覚だと高級と低級の中間だから中間言語だよね。
中級の書き間違いですよね。 中間言語は、また違う意味を持った言葉なので。
Re: Re: Re:C/C++のせいで感覚が麻痺してくるが (スコア:1)
> 中間言語は、また違う意味を持った言葉なので。
江戸時代のはなしですね。
足軽言語、中間言語、小者言語がある。
Re: Re: Re: Re:C/C++のせいで感覚が麻痺してくるが (スコア:0)
つられてやんの # 俺もな～
メモリ安全に (スコア:0)
スレッドセーフは含まれますか？
Re: (スコア:0)
並列処理は人類には早すぎる
Re: (スコア:0)
量子コンピュータなどバグがどうなるのやら？
なぜ脆弱性が発生してしまうのか？ (スコア:0)
OSや言語仕様やコンパイラの設計に問題があるのではないの？
これだけ脆弱性がわかっているならそれを踏まえて設計し直すことは可能では？
ハッカやクラッカのほうが技術的スキルが上であればそういう集団を雇って全部刷り直しるればいい
海外はともかく日本ではスキルがあっても学歴重視社会で
本当の天才は日の目を見ないのが現実
これじゃあ技術者の海外流出があるのは当然
日本という国はどうでもいいところに税金を無駄遣いしている
その合計年間数十兆円
いつまで既得権益などという過去の亡霊に頼るのだろうか？
Re:なぜ脆弱性が発生してしまうのか？ (スコア:1)
最近バッファオーバーフロー保護も普及してきてるし、
静的解析ツールも使えるし、言語仕様やコンパイラのレベルで
打ち取れる脆弱性は減ってきてるでしょ。
Log4Shell とかはメモリ安全な言語で発生してるものだし、
メタップスの事例とかも、直接言語仕様でどうこうできるもんではないでしょう。
Re: (スコア:0)
その流出した海外でも出来ない事が、何故出来ると？？？
Re: (スコア:0)
完璧な設計、完璧な実装、完璧な評価
それらを満たすには無限大のコストがかかります
そこまで完璧じゃなくっても良い？その妥協の結果が現状ですね
Re: (スコア:0)
開発者は1点のミスもない満点を取らなければならない。
クラッカーは開発者がミスした部分のうちたった1点でも分かるとクラックできる。
通常は開発する側の方がずっと難易度が高い。
Re:インタプリタじゃ無理か (スコア:2)
BASIC が安全だって？
ＢＡＳＩＣの基本３命令
http://www.pro.or.jp/~fuji/pasocomlife/1995-11-21.html [pro.or.jp]
PEEKとPOKE
https://ja.wikipedia.org/wiki/PEEKとPOKE [wikipedia.org]