Apple's SSL/TLS bug (22 Feb 2014)
https://www.imperialviolet.org/2014/02/22/applebug.html
(Hi Adam Langley, Than you for your blog! We really appreciate you.)

-----

昨日、AppleはばかばかしいiOS向けのセキュリティアップデートを発行した。
それは詳しく明かされていないが、SSL/TSLについてとんでもなく恐ろしい間違いを示すものだった。

その答えは既にハッカーニュースのトップにタレこまれている(https://news.ycombinator.com/item?id=7281378)し、アップルが隠したい秘密はもうバレてしまっていると思う。
そして現在、俺たちはその誤った情報を正すステージに来ているんだ。

ほらここに、Appleのbugがあるんだ。：

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                 uint8_t *signature, UInt16 signatureLen)
{
 OSStatus        err;
 ...

 if ((err = SSLHashSHA1.update(&amp;amp;hashCtx, &amp;amp;serverRandom)) != 0)
  goto fail;
 if ((err = SSLHashSHA1.update(&amp;amp;hashCtx, &amp;amp;signedParams)) != 0)
  goto fail;
  goto fail;
 if ((err = SSLHashSHA1.final(&amp;amp;hashCtx, &amp;amp;hashOut)) != 0)
  goto fail;
 ...

fail:
 SSLFreeBuffer(&amp;amp;signedHashes);
 SSLFreeBuffer(&amp;amp;hashCtx);
 return err;
}(Quoted from Apple's published source code.)

(訳者注：(Quoted from Apple's published source code)→sslKeyExchange.c)

2行のgotoがあるだろ。
2行目のgotoは、見て分かる通り常に発動する。
変数[err]にはエラーを示す値が入らず、正常を示す値のままfailに飛ぶってことだ。
それって成功したのと同じなんだよね！

この署名検証処理は(訳者注：SSL/TLSハンドシェイクのやりとりのうちの一つである)ServerKeyExchangeメッセージの署名を検証するものだ。
このServerKeyExchangeでは、"the ephemeral key"（通信のための一時的な鍵）を交換するためのDHE や ECDHE という暗号スイートが使われる。
そのサーバーは言うんだ。
「ここに"the ephemeral key"と署名があるよ、ほら、これが証明書だ。君はこれが僕からのものだってわかってくれるよね！」

今、もし"the ephemeral key"と証明書の関係が破たんしているならば、すべては無意味なんだ。
これってつまり、正規の証明書チェーンをクライアントに送信したけど、ハンドシェイクへの署名には正しくない間違った（つまり適当にその辺で作った）鍵を使ったり、そもそもハンドシェイクに署名しなかったりってことができるってことなんだよ！

そこには、今君が通信しているサーバーが、サーバー証明書に含まれる公開鍵の秘密鍵を持っているってことの証明が、何もないんだ。

これはSecureTransport(というライブラリ)に入っていて、以下に影響する。
・iOS 7.0.6より前(俺は7.0.4で確認した)
・OS X 10.9.2より前(10.9.1で確認した)
(訳者注：つまりiOS 7.0.6、OS X 10.9.2で解決した)

これはSecureTransportを使っているすべてに影響するけど、ChromeとFirefoxはそうじゃない。
ChromeとFirefoxはSSL/TLSのためにNSSを使っている。
でも、それはあんまり君のマシンがSecureTransportを使っていないってことを意味しないよ。(ソフトって更新されるしね)


超特急でテストサイトを作ってみたよ。https://www.imperialviolet.org:1266
ポート番号に気を付けてね。(テストサイトはCVE番号になってるよ)
443は通常通りに動いているからね。

ポート1266のサーバーと443のサーバーは同じ証明書を送っているけど、完全に異なるキーで署名しているんだ。
君がもしポート1266のHTTPSサイトにアクセスできたんだったら、君のマシンはこのイケてるバグを抱えてるってことだね。:)


それってつまり、証明書チェーンは正しいってことで、そしてハンドシェイクと証明書チェーンの関係は壊れたってことで、もう俺はどんな証明書も信じないよ。

またこれは、DHE または ECDHE 暗号スイートを使っているサイトに影響を及ぼすだけじゃないんだ。
攻撃者は、この暗号スイートを使うサーバーを自分で建てるようになるだろう。

また、これはTLS 1.2には影響しない。このバグを含まないTLS 1.2の別の関数があったから。
でも攻撃者は使うプロトコルをある程度選ぶことができるから、安心できないよ。
(訳者注：サーバー側がTLS1.2を使えないことにしていたら、それ以外の例えばSSL3.0とかTLS1.0とか1.1で通信が始まっちゃうから。)
でもでも、クライアント側でTLS1.2だけを使えるようにしておけば、それは今回の問題の回避策になる。。
同じく、クライアント側でRSA暗号スイートだけを許可するということも、ServerKeyExchangeが発生しなくなるので今回の問題の回避策になる。
(2つのうち、1つ目のほうがだいぶ好ましい。)

俺のテストサイトでは、iOS 7.0.6 と OS X 10.9.2で問題は解決していた。
(更新：このバグはOS X 10.9 のときに入ったように見えたけど、iOS6にもっあったぽい。iOS 6.1.6は昨日リリースされたよ。)

こんなような微妙なバグって、悪夢だ。
俺はこれは単なるミスだと思うし、なんかもうほんと最悪って思う。


ここに、今回の問題を明らかにするコードがある。：

extern int f();

int g() {
 int ret = 1;

 goto out;
 ret = f();

out:
 return ret;
}

もし俺が"-Wall "を付けてコンパイルしたとしても、XcodeのGCC 4.8.2 や Clang 3.3は死んでるコード(the dead code)について警告をしないんだ。
本当にビックリだよ！！！

ここで警告が出ていたらこの問題は止められたのに。でもたぶん、現実には死んでるコードが多すぎて無視することにしてるんだろうね。
(ピーター・ネルソンが教えてくれたけど、Clangはこれを警告するための"-Wunreachable-code"を持ってる。でもこれ、なんと"-Wall "には含まれてない！)

if文に{}をつけないことを許すコーディングスタイルはこの問題を誘発したかもしれない。
でも、人は{}を付けたとしても間違ったプログラムを書くことがあるから、これは俺はあんまり関係ないように思う。

テストケースはこれを見つけることができたはずだけど、今回のはいろいろ条件が複雑なやつだったから難しかったと思う。
TLSのめちゃめちゃ多くのオプションを試さなきゃいけなかったからね。しかも正常系じゃないやつも。
俺、TLSLiteでちゃんとテストしてるか思い出せないもん。(月曜日怖いかも)

コードレビューはこの種類のバグについて効果的でありえる。
ただし単なる審査じゃなく、それぞれの変更に対してしっかりとレビューすることだ。
Appleのコードレビューカルチャーがどんなもんか知らないけど、もし俺が同じようなことをやっちゃったとしたら、同僚のWan-Teh や Ryan Sleevi がばっちり見つけてくれたと、固く信じてる。
でも、誰もがそんなにいい仲間を持てるわけじゃないよね。


最後に。昨日、Appleが証明書のホスト名をちゃんとチェックしていなかったことについて多くの議論があったんだけど、
それは OS X のコマンドラインでcurlを使うと、IPじゃない証明書でもIPでHTTPSにつながっちゃうってだけだったよ。変だけど。
Safariはこの問題には関係なかったよ。

Permalink | 記事への反応(0) | 01:12

2011-12-23

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

あとフェミニストは、なぜか主婦に冷たい。

もともとフェミは『家族』とか『家庭』という構造自体に反対している人間が多いってのもあるが。

WAN:Women's Action Network「労働」概念は変化したのか？　　伊田久美子

私は７０年代以降のフェミニズムは、以下の２点を明らかにしたと思っていた。
ひとつは、稼ぎのない妻の利害は「稼ぎ手」である夫と一致しているように思い込まされてきたが、
それは必ずしも一致しないこと、もうひとつは、「主婦」と「働く女」の利害は対立していると思い込まされてきたが、
実はけっこう一致している、ということである。
ミクロな権力関係を含んだ「家父長制」と、一心同体とみなされてきた家族の中の仕事を労働であると主張した「家事労働」という二大キー概念は、
これに呼応している。さらに言えば、ジェンダー論は労働／非労働の二項区分の自明を問い直す画期的ツールだったはずである。

ここまでは解る。個人的にも、ある時点まではフェミニズムは社会に有益な働きをしてきた、とも思ってる。

しかしこの日のシンポジウムを聞いていると、どうやら二つとも私の勘違いだったかのようである。
むしろ女の多様化とか女女格差という議論の展開によって、上記の課題の重要性は希薄になっているのだろうか。
たしかに70年代の「女」というアイデンティティは今の時代には既に齟齬があるだろうし、
この変化は機会を改めて考察したいテーマである。しかしあのとき開けた構造の認識は、
運動にとって貴重な相互理解を可能にしたであろう。
なぜなら女たちが手探りで模索したフェミニズム理論とは、異なる立場の者、知り合うこともない者との連帯を可能にするためのツールだからである。
私が衝撃を受けたのは、多くの発言の「主婦」についての辛辣で冷ややかな口調であり、
ほんの少し異なる立場への想像力と寛容の欠如であった。「主婦フェミニズム」という批判もあまりよく理解できなかった。

http://wan.or.jp/reading/?p=5396

運動が拡大する前は、どうしても頭数がいる、そういう利害もあって

活動に参加する時間がある専業主婦層を大量に取り込んだって感じなんだろうか。

そして今は女性側の権利もほぼ満たされ、より雇用の拡大をポジティブアクションで実現しようとしている、

そんな段階に達してしまうと、フェミ観点では主婦って面倒な存在なのかな、と思ったりもする。

Permalink | 記事への反応(0) | 22:23