Lua は配列が１スタートなんがなぁ。ポインタを理解すると、0 スタートのが合理的な気がするけどなぁ。でも、LL っていう意味では好きよ。一時期 Rust が辛くて Nim にいったけど、「最後に C言語になっちゃうと、バッファオーバーフロー問題は解決できなくね？」と思ったら、Rust に戻ってきちゃった。

Permalink | 記事への反応(0) | 02:39

2021-05-19

■バグと脆弱性(セキュリティホール)の線引

ワクチン大規模接種東京センターの予約システムで発生した、適当な数字を入力しても予約できるシステムの不備はバグなのか脆弱性(セキュリティホール)なのかを考えていこう。

もし、脆弱性であるとするならば、しかるべき報告フローを取る必要があるからだ。

記事の末尾に参考リンクをいろいろおいておいたので、詳細は確認してほしい。

この問題は、本来するべきチェック処理をしていないのだから、バグの一種といえる。

// ただ、改善する気がないのなら仕様となるのだろうけどね。

あるゆる、脆弱性はバグの結果起きる。

では、適当な数字を入れても予約できちゃうバグは、脆弱性(セキュリティホール)と言えるのか？

もし、脆弱性(セキュリティホール)となるなら、ゼロディでいきなり公開する前に、しかるべき報告フローを取るべきだ。

// ただ、新聞社は、ネットで噂になったものを取材して報道しただけであるから、ゼロディで公開とは言えないだろうけどな。

個人的な意見としては、脆弱性とまでは言えないと思う。

これはタダのバグであって、脆弱性(セキュリティホール)と呼ぶのは言い過ぎだろう。

例えば、教科書レベルの「"＜script＞alert("XSS");＜/script＞」でXSSを発生させる意図的な入力をして、誤動作が発生するなら、それは間違いなく脆弱性(セキュリティホール)といえる。

同様に、SQLインジェクションを発生させる意図的な入力をして、何か変なことが起きれば、これも間違いなく脆弱性といえる。

他にも、超でかいデータを送りつけてバッファオーバーフローさせたり、特殊な入力をしてスタックを破壊して戻り値を改ざんして任意のコマンドを実行するみたいなものも同様に脆弱性と呼んでもいいだろう。

(注:念のために書いておくが、不正アクセスで違法になる可能性があるので、自分の所有するサイトやコンピュータ以外へは、これらの入力を試さないように。)

でも、ごく普通の入力をしても、エラーとしてはじかないで受け入れてしまうのは、脆弱性ではなく、タダのバグであるように思う。

「こういう操作したら、計算結果が変になった」はバグの領域であって、脆弱性とまでは言えない。

今までの話を簡単に言うとしたら、ドラクエ4で8回逃げたら会心の一撃が連続して出るのはバグなのか脆弱性なのか？って話になるのかな。

確かに、8回逃げることで、データのバッファオーバーフローが発生して、そのような結果になる。

でも、8回逃げるというはやろうと思えは誰でもできる動作であって、これをバグではなく脆弱性(セキュリティホール)と呼ぶのは違和感がある。

この裏技を見つけたとして、脆弱性としてしかるべき報告フローを取らずに公開したことを咎められるとしたら、実に変な話である。

これら裏技を試しても不正アクセスと言われて、罪を着せられたり、裏技の記事を削除されるとしたら、強烈な違和感がある。

このあたりのバグと脆弱性の線引はどうなっているのか。

今回の事件で、それが一番気になった。

最終的には、裁判で裁判所が決めることになるんだろうけど、あまりアホな判決を出して、日本のエンジニアの手足を拘束しないでほしいと思う。

参考URL:

■ドラクエ４で「にげる」８回でずっと会心の一撃になるバグ、こういう仕組みで起こってたらしい

https://b.hatena.ne.jp/entry/s/togetter.com/li/1715732

■「誰でも何度でも予約可能」ワクチン大規模接種東京センターの予約システムに重大欠陥

https://b.hatena.ne.jp/entry/s/dot.asahi.com/dot/2021051700045.html

■岸信夫 on Twitter: "自衛隊大規模接種センター予約の報道について。...

https://b.hatena.ne.jp/entry/s/twitter.com/KishiNobuo/status/1394440062125805572

■脆弱性の手口、IPA「見つけたらまず開発者やIPA窓口に報告して」　コロナワクチンの架空予約巡り

https://b.hatena.ne.jp/entry/s/www.itmedia.co.jp/news/articles/2105/18/news145.html

■Hiromitsu Takagi on Twitter: "私はこの届出制度の提唱者・設計者・運用協力者・有識者研究会委員であり、IPAの広報が取材にこんな回答をしたのであれば、出鱈目であり、...

https://b.hatena.ne.jp/entry/s/twitter.com/HiromitsuTakagi/status/1394713619212816385

■ワクチン大規模接種「架空ウェブ予約」やったら犯罪？　国は「法的手段」に言及

https://b.hatena.ne.jp/entry/s/www.bengo4.com/c_23/n_13071/

■確認作業は公益性高い、毎日新聞　接種センター架空入力は取材目的

https://b.hatena.ne.jp/entry/s/this.kiji.is/767285347672670208

■AERA dot. 記事への防衛省の申し入れに対する見解

https://b.hatena.ne.jp/entry/s/dot.asahi.com/info/2021051900065.html

Permalink | 記事への反応(7) | 06:14

2019-10-09

■anond:20190626224519

263

百三日目

最近わかったこと：「お前の意見を言え」→「～～」→「お前の意見なんて聞いてねえよ」→「？？」→「お前の意見をさっさと言えよ」→「～～」→「お前の意見を聞いてないって何度いえば分かるんだ」→「……」→「お前の意見をさっさと言えと言ってるのが分からねえのか！」ってパターンを食らうと脳がバグってブチ切れてしまう。

結局の所は単純なダブルバインドに過ぎないのだが、こういうシンプルな精神攻撃に意外と弱いらしい。

コミュニケーションという行為に対して元々高い負荷を感じている自分にとっては、こんなどうでもいいようなダブルバインド方式のコミュニケーションエラーがある種のバッファオーバーフロー攻撃のようなものになってしまい脳が完全にバグる。

対処法としては、相手がこのような「無礼なコミュニケーション」を行ってきていると気づいた段階で真摯に対応するモードから適当に応対するモードに切り替える、ないしは上っ面だけ真面目に聞いてる風に見せかけて実際は単に「うんうんそうだね」「言えたじゃねえか」と女子会のような中身空っぽトークで乗り切るという回路を脳に形成していくのが有効だろう。

コミュニケーションにおけるバッファオーバーフロー攻撃を狙って実行しているパターンの典型例が宗教における洗脳行為である。

相手の精神に対して高い負荷をかけて一度パニックを起こさせてから、精神に生まれたスキに新たな価値観を入れていく、いわゆるイニシエーションと呼ばれる洗脳の初期段階である。

なるほど、改めて考えてみるとその原理は高負荷をかけることで管理者権限を乗っ取ろうとするタイプのハッキング行為そのものではないか。

逆を言えば、このようなコミュニケーションを無自覚に行ってくる人間は、自分に都合よく状況をすすめるために目の前の人間を洗脳しながら今日まで生きてきたということだ。

それが自覚的にせよ無自覚にせよ、錯覚を起こさせる段階を通り越し相手を洗脳して自分に都合がいいコミュニケーション結果を生み出すことを生存戦略としてきた人間など『まともに相手にしてはいけない』のは間違いない。

Permalink | 記事への反応(0) | 06:39

2019-10-01

■anond:20191001094140

死んでるのに消費税とられた場合になんか符号が反転してバッファオーバーフローとか発生したりしないの？

Permalink | 記事への反応(0) | 09:43

2019-07-10

■anond:20190710223018

あんなマウンティング人間を引き寄せるプログラミング言語は嫌だわ。

バッファオーバーフローを引き起こす可能性があるだけでも言語としては欠陥なのに、

自称ハッカーは「ポインタも理解できない云々」なんて威張るし。

ああやって、そういう自称ハッカーがコンピュータに振り回されて、

ゴチャゴチャした可読性の低いプログラムを量産するんだよね。

今時パフォーマンスなんてボトルネックがきちんと把握できてれば、問題ないよ。

Rustなんかもあるご時世だし。

Permalink | 記事への反応(2) | 22:34

2019-01-11

■メモリー オーバーフロー

近くでミーティングをしていて「メモリーオーバーフロー」という言葉が聞こえてきた。

サーバーのメモリーが足らなくなることを言ってるらしい。

オーバーフローと言うと、バッファオーバーフローみたいに決められた領域からはみ出すとか、演算で数値の上限を超えてしまうとかそういうニュアンスだよな。

ただの「メモリ不足」でいいんじゃないか。

Permalink | 記事への反応(2) | 17:06

2018-10-17

■anond:20181017182112

C言語的には問題が無いのでエラーは出ないよなあ。

あのコードでは、静的解析でバッファオーバーフローをあぶり出さないとヤバイ感じ。

Permalink | 記事への反応(0) | 18:59

2016-02-04

■http://anond.hatelabo.jp/20160204031629

マダムは増田のココロにバッファオーバーフロー攻撃を仕掛けたんだと思う。

経験で得た悪意のあるコードも埋め込んで、実効性のある攻撃として仕掛けた。

増田に出来たことは耳を塞ぐこと、走って逃げること、棒のように固まったあとすぐ逃げることとかだろうか。

恐怖で竦んでしまった分けだし、今回は本当に悔しい思いをしたと思う。

ただ、はっきり言っとく。

婆さんはあんたを鴨としてしか見てなかったはずだ。

あんたは老人の浅ましさ、怖さを知らない。

へらへらしっ放しなんて、俺から見ても申し分ない、上々の鴨にしか見えないんだよ。

Permalink | 記事への反応(0) | 21:29

2015-02-04

■「セキュリティ 対策」

「不正な入力に対して脆弱性を発生させないようセキュリティ対策としてバリデーションを行う」。アホか。プログラマならセキュリティ対策とか気にするな。いや、気にするなというのは言い過ぎだけれど、ほとんどの場合においてあなたの書くコードはセキュリティ対策の必要性はない。

攻撃者の細工した入力によってSQL/HTML/JavaScriptが壊れるとかバッファオーバーフローが発生するとか、そういった脆弱性と呼ばれるほとんどのものはただのバグだ。セキュリティ対策っていうのはコードとは切り離された領域で行うDEPだったりASLRだったりX-Frame-OptionsだったりCSPだったりiframe sandboxだったり、そういうものがセキュリティ対策だ。コード上で書くのは「アプリケーションとして正しく動作するための処理」だけだ。

もちろん例外もあるかもしれないけど、それはあくまでも例外だ。日常的に書くコード－長さやフォーマット、範囲のチェックだったり、次の処理系に適したエスケープを施したり－は全てセキュリティ対策のためのコードではない。アプリケーションが正しく動くための処理だ。それができていないのはただのバグだ。

にも関わらず「セキュリティ対策」のようにさも特別なものであるかのような言葉でポジショントークを繰り返すような姿勢は好ましくない。

もし、「セキュリティ対策という視点で入力バリデーションをしていない」ということに対して不安を覚える開発者がいるのであれば、セキュリティ対策など考えなくていいので今すぐテストを書け。

Permalink | 記事への反応(4) | 23:34

2011-09-12

■http://anond.hatelabo.jp/20110912211500

でも、データの発生や消滅のフラグは携帯電話内のアプリ側でやってるよね？

そういうやつもあるかも知れんが、おそらく大半は違うと思う。

たとえば、「宝箱を開けてハズレ or 当たり」ってシーンでは、宝箱のシーンになった時点でハズレか当たりかのフラグもセットでサーバーから送られる(送られた時点でサーバーのアカウント情報にも同じデータが反映される)。

なのでパケットや携帯電話内のデータを改ざんしてもアイテムの不正取得は難しいんじゃないかな。

もしやるとしたら、サーバーの脆弱性を突いてバッファオーバーフローさせてサーバー内のデータを書き換えるとか、そういうレベルになるんじゃないかな。

あの手のゲーム作ってる所って基本的にセキュリティとか全然考えてなさそうだし。

Permalink | 記事への反応(0) | 21:26

2010-01-17

■Google、中国撤退問題

各種報道よりGoogle 中国撤退問題のまとめ

2006年 1月　 Googleが中国に進出　当局の検閲を受け入れる

2009年 12月　Aurora事件　シリコンバレーの企業に大規模ハッキング

ハッキングの手口

メールでURL リンクを送りつけ→従業員が間違って悪意のあるサイトを訪問→
IE6の脆弱性（JavaScriptのバッファオーバーフロー）を突いた暗号化された
未知のマルウェアが気付かないうちに自動で仕込まれる→
マルウェアがサーバーからほかのマルウェアをDLしはじめる→
社内ネットワークに侵入→各種データを収集→
イリノイ、テキサス、台湾のサーバーに情報を送る→痕跡を消去
McAfeeの説明

Adobe Reader の脆弱性を突いたpdfを添付した電子メールを従業員に送りつける→
『Trojan.Hydraq』というバックドア型トロイの木馬がインストールされる→
社内ネットワークに侵入
iDefenseの説明
IE6, pdf の脆弱性だけでなく複数の方法を使っていると思われる
Google社のソースコードが盗まれた可能性がある
34社がターゲットになった
Google, Adobe, Yahoo, Symantec, Juniper Networks, ノースロップ・グルマン、ダウ・ケミカルなど

12/15 シリコンバレーにハッキング攻撃開始　
　　　　Googleが侵入に気付く　台湾のサーバーを覗く(逆ハック）
1/2 Adobeが侵入に気付く
1/4 攻撃終了　攻撃者のサーバーが閉じられる