- Apple史上最悪のセキュリティバグか、iOSとOS XのSSL接続に危険すぎる脆弱性が発覚──原因はタイプミス? | アプリオ
- ImperialViolet - Apple's SSL/TLS bug
This signature verification is checking the signature in a ServerKeyExchange message. This is used in DHE and ECDHE ciphersuites to communicate the ephemeral key for the connection. The server is saying “here's the ephemeral key and here's a signature, from my certificate, so you know that it's from me”. Now, if the link between the ephemeral key and the certificate chain is broken, then everything falls apart. It's possible to send a correct certificate chain to the client, but sign the handshake with the wrong private key, or not sign it at all! There's no proof that the server possesses the private key matching the public key in its certificate.
サーバが適切な秘密鍵を持っていなくても通信できる→詐称できるということかな。
コード的には、SSLVerifySignedServerKeyExchangeという関数の中で
if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail;
としていて、goto failが2回続いているところで、2回目のgoto failが必ず実行されるので、後のSSLHashSHA1.finalなどのチェックが意味をなさないということか。
But if the client only enables TLS 1.2 then it appears that would workaround this issue. Likewise, if the client only enabled the plain, RSA ciphersuites then there's no ServerKeyExchange and that should also work around this issue. (Of the two, the former workaround is much more preferable.)
回避策はTLS1.2のみを使うようにするか、暗号化方式に平文もしくはRSA暗号のみを使うようにするとある。
TLS 1.2を使うとSSLVerifySignedServerKeyExchangeが呼ばれないし、RSA暗号だと上記のコードを実行する前にSSLVerifySignedServerKeyExchangeを抜けてしまう。
if (sslVersionIsLikeTls12(ctx)) { err = SSLVerifySignedServerKeyExchangeTls12(ctx, sigAlg, signedParams, signature, signatureLen); } else { err = SSLVerifySignedServerKeyExchange(ctx, isRsa, signedParams, signature, signatureLen); }
static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { ... if(isRsa) { /* skip this if signing with DSA */ dataToSign = hashes; dataToSignLen = SSL_SHA1_DIGEST_LEN + SSL_MD5_DIGEST_LEN; hashOut.data = hashes; hashOut.length = SSL_MD5_DIGEST_LEN; if ((err = ReadyHash(&SSLHashMD5, &hashCtx)) != 0) goto fail; if ((err = SSLHashMD5.update(&hashCtx, &clientRandom)) != 0) goto fail; if ((err = SSLHashMD5.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashMD5.update(&hashCtx, &signedParams)) != 0) goto fail; if ((err = SSLHashMD5.final(&hashCtx, &hashOut)) != 0) goto fail; } else { /* DSA, ECDSA - just use the SHA1 hash */ dataToSign = &hashes[SSL_MD5_DIGEST_LEN]; dataToSignLen = SSL_SHA1_DIGEST_LEN; } // この後にgoto fail; goto fail;がある
Since this is in SecureTransport, it affects iOS from some point prior to 7.0.6 (I confirmed on 7.0.4) and also OS X (confirmed on 10.9.1). It affects anything that uses SecureTransport, which is most software on those platforms although not Chrome and Firefox, which both use NSS for SSL/TLS. However, that doesn't mean very much if, say, the software update systems on your machine might be using SecureTransport.
影響があるのは、iOS 7.0.6以前とOS X 10.9.1。SecureTransportを利用しているソフト。ChromeとFirefoxはNSSを利用しているので問題ない。ただし、ソフトウェアアップデートシステムがSecureTransportを利用していればそこでソフトそのものを書き換えられてしまう可能性があるか。
脆弱性があるかどうかは以下のサイトで確認できる。
あと、Mac OS X 10.9.2で修正されるという情報もみかけた。