Heartbleed脆弱性と、その背後にあるWebアプリケーションアーキテクチャの一般的欠陥について

■Heartbleedのリスクと善後策 Heartbleedは、攻撃者が一定の条件を満たすOpenSSLが動作しているサーバの、任意位置のメモリを外部から読み出すことができてしまうという脆弱性です。具体的には、以下のようなリスクが想定されています。 秘密鍵の漏洩による、偽サイトの出現（あるいは中間者攻撃） 秘密鍵の漏洩により、（過去のものを含む）パケットキャプチャの解読 サーバの同一プロセスが行った処理に関連する（他のユーザーのパスワードやセッションキーを含む）データの漏洩 漏洩した秘密鍵を用いた攻撃には、ユーザーを偽サイトへ誘導できたり、パケットの経由点を管理しているなどの、経路上の要件が必要になります。他のユーザーのデータの漏洩については、経路上の要件は不要な一方、攻撃の実施に近いタイミングでサーバにアクセスしたユーザーのデータしか漏れない、という違いがあります。 どこまで対策を施すべ

[iakio]

DJBがWebアプリケーションを作ったらどんなアーキテクチャになるんだろうと妄想する。まずリクエスト毎に別のユーザーIDでchrootだろうが、DB周りは難しいな

[coppieee]

OpenSSLライブラリ内で、秘密鍵が必要な処理と、それ以外の処理を別々の権限で実行する処理にするのはあまりにも非現実的ではない？最小権限の原則といっても粒度が細かすぎると複雑になりすぎて逆にバグが発生しそう

[deep_one]

本題に関係ないが、この脆弱性って「任意の位置のメモリ」なの？よくある「プロセスのメモリに隣接したメモリ」かと思っていたけど。

[circled]

過去のパケットキャプチャをこの脆弱性が見つかるまで保存してた奴がいるんだろうか？という疑問が。

[ssids]

リクエストごとに個別のLXCインスタンスを作るのはどうだろう。リクエストだけじゃなくて機能モジュールごとにも別インスタンス。

[rti7743]

最小構成や権限分離したコードを作る方法が専念されておらず面倒だってことが問題で、もっと気軽にこれらの処理をかけるプログラム言語とかのサポートがあっていいと思う。constをつけるぐらいに気軽にできるといいな

[oppara]

Kazuho's Weblog: Heartbleed脆弱性と、その背後にあるWebアプリケーションアーキテクチャの一般的欠陥について

[Kureduki_Maari]

Kazuho's Weblog: Heartbleed脆弱性と、その背後にあるWebアプリケーションアーキテクチャの一般的欠陥について

[bobbyjam99]

Kazuho's Weblog: Heartbleed脆弱性と、その背後にあるWebアプリケーションアーキテクチャの一般的欠陥について :

[sonota88]

最小権限の原則

[rryu]

ユーザーごとにリソースを分離するとそれはそれでDoS攻撃の元になってしまうような気もする。

[Haaaa_N]

ユーザごとにプロセス作ってたら,1万件問題に対処できないんだが…

[tyru]

パスワードはハッシュ化して置いておきましょう見たいな、そもそも侵入されても大丈夫なようにしましょうって話に似てる

[takaesu]

総括した感じのまとめ

[mikage014]

高コストだけど安全なアーキテクチャが選択肢として存在するのはいいことだと思う

[nbsn]

「安全性の根拠をプログラムにバグがない点に求めるという悪しき慣習が続いています。」

[labocho]

最小の権限限のみで動作すれば被害はないか少ないと / ログイン時に fork するアーキテクチャ見たことある

[tmatsuu]

ユーザ登録ごとにCREATE USER、友達になったらGRANT SELECT ON (友達のレコード)。というよりはビューの活用か。強力なACLを備えたデータストアか。あるかな。

[taguch1]

セキュリティは各種メリットとトレードオフだから今の位置に収まったと考えてる。暗黙の総意による妥協点というべきか。

[tjtjtjofthedead]

ユーザー毎コンテナの世界？

[hobbiel55]

是非、万単位のユーザが同時アクセスするシステムを、そのようなWebアプリケーションとして開発し公開してみて欲しい。

[tsupo]

「最小権限の原則に基づいたセキュリティは有効に機能することが知られています」

[legoboku]

「秘密鍵の漏洩にしても、秘密鍵を必要とする処理（TLSのハンドシェイク中の一部処理に限られます）と、TLS Heartbeatの処理を別個の権限の元で動作させていれば、発生しなかったと言えます」

[s_mori]

最小権限の原則

[abracadabra321]

RESTでしょ。

[KoshianX]

ああまあそうだよなあ、そりゃそのユーザーが読み書きできるところだけ読み書きできりゃ SQL インジェクションとかあっても脆弱性にはならんけどさ。認証と権限が一元化できるといいんだけどね

[kyab]

任意位置のメモリじゃないよ。位置も内容も攻撃者はおろか、やられる側も予測不能。攻撃者はサイズだけ指定できる。最大64kbで何度でも。

[Dryad]

「プロセスを使い回すのはよくない」とか言われても、Java使いとしては承服し難いんだが…(´・ω・`)

[asuka0801]

ユーザー毎にDB作ったりすんのかな。見るからにカオスになりそうだけど

[restartr]

たしかにそうだよなーと。

[ukitazume]

“リバースプロキシ、アプリケーションサーバ、データストア、そういったウェブアプリケーションの各要素について、最小権限の原則に基づいた、アプリケーションにバグがあっても脆弱にならないようなアーキテクチャ

[masabossa]

ちなみに秘密鍵漏洩についてはクライアント端末におけるICカードやUSBトークンのように耐タンパなハードウェア暗号処理装置のなかに秘密鍵を保持すればよい。秘密鍵は装置のなかで処理されメモリにロードされない。

[tzt]

パフォーマンスや複雑さとのトレードオフなのでなかなかそういう方向に行くのは難しそう。でもいずれはそうなるといいなぁ。