Appleは、SSL接続を確立するときにサーバーの署名を確認するために、SSLVerifySignedServerKeyExchange関数の途中でgoto無条件演算子を使用して余分な行を削除することを忘れて、最近
大きなミスを犯しました。 その結果、署名検証の結果に関係なく、関数は正常に完了しました。
ただし、重大なエラーが1行のコードで説明されるのはこれが史上初めてではありません。 以下に、
このような例をいくつか示します。
Xサーバー
2006年、X Serverがユーザーのルート権限をチェックすることが発見されましたが、同時に、開発者は実際
に対応する関数を呼び出すのを忘れていました 。
Debian OpenSSL
2008年、Debian
は 、2006年の独自のOpenSSL実装の擬似乱数ジェネレータが実際に予測可能な数値を生成する
ことを
認めました。
その理由は、重要な行がコメントに含まれていたためです。 誰もコードをまったくチェックしていないかのように、このような顕著なバグが最終リリースにどのように侵入したかは完全に理解できません。 ちなみに、多くの人がDebianが理由でPRNGを「壊さない」と疑っていました。
標準OpenSSL
OpenSSLのもう1つのバグ 。2008年からです。 OpenSSL 0.9.8i以前のバージョンは、「EVP_VerifyFinal関数によって返された値を誤ってチェックしたため、攻撃者はDSAおよびECDSAキーの偽のSSL / TLS署名を使用して証明書の検証をバイパスできました。」
--- lib/libssl/src/ssl/s3_srvr.c +++ lib/libssl/src/ssl/s3_srvr.c @@ -2009,7 +2009,7 @@ static int ssl3_get_client_certificate(S else { i=ssl_verify_cert_chain(s,sk); - if (!i) + if (i <= 0) { al=ssl_verify_alarm_type(s->verify_result); SSLerr(SSL_F_SSL3_GET_CLIENT_CERTIFICATE,SSL_R_NO_CERTIFICATE_RETURNED);
Android
2010年5月11日付けの
memset.cの
パッチをご覧ください 。
正しいパラメーターの代わりに、ゼロがメモリーに書き込まれます。 つまり、関数に渡されたパラメーターの1つはまったく使用されません。
タースナップ
Amazon S3のバックアップを安全に保存するためのオンラインサービスであるTarsnapプログラムの著者は、2011年に、データの暗号化時にランダムな値(nonce)を生成する手順の
バグを
報告しました 。
暗号化されたデータの16バイトごとに新しいランダム値が生成されることになっていましたが、実際にはまったく変化しませんでした。
したがって、Appleがミスをするだけではありません。