単一行バグの歴史

Appleは、SSL接続を確立するときにサーバーの署名を確認するために、SSLVerifySignedServerKeyExchange関数の途中でgoto無条件演算子を使用して余分な行を削除することを忘れて、最近大きなミスを犯しました。 その結果、署名検証の結果に関係なく、関数は正常に完了しました。



ただし、重大なエラーが1行のコードで説明されるのはこれが史上初めてではありません。 以下に、 このような例をいくつか示します。

Xサーバー

2006年、X Serverがユーザーのルート権限をチェックすることが発見されましたが、同時に、開発者は実際に対応する関数を呼び出すのを忘れていました 。

--- hw/xfree86/common/xf86Init.c +++ hw/xfree86/common/xf86Init.c @@ -1677,7 +1677,7 @@ } if (!strcmp(argv[i], "-configure")) { - if (getuid() != 0 && geteuid == 0) { + if (getuid() != 0 && geteuid() == 0) { ErrorF("The '-configure' option can only be used by root.\n"); exit(1); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Debian OpenSSL

2008年、Debian は 、2006年の独自のOpenSSL実装の擬似乱数ジェネレータが実際に予測可能な数値を生成することを認めました。

 --- openssl-a/md_rand.c +++ openssl-b/md_rand.c @@ -271,10 +271,7 @@ else MD_Update(&m,&(state[st_idx]),j); -/* - * Don't add uninitialised data. MD_Update(&m,buf,j); -*/ MD_Update(&m,(unsigned char *)&(md_c[0]),sizeof(md_c)); MD_Final(&m,local_md); md_c[1]++;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その理由は、重要な行がコメントに含まれていたためです。 誰もコードをまったくチェックしていないかのように、このような顕著なバグが最終リリースにどのように侵入したかは完全に理解できません。 ちなみに、多くの人が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のパッチをご覧ください 。

 --- libc-a/memset.c +++ libc-b/memset.c @@ -1,6 +1,6 @@ void *memset(void *_p, unsigned v, unsigned count) { unsigned char *p = _p; - while(count-- > 0) *p++ = 0; + while(count-- > 0) *p++ = v; return _p; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

正しいパラメーターの代わりに、ゼロがメモリーに書き込まれます。 つまり、関数に渡されたパラメーターの1つはまったく使用されません。

タースナップ

Amazon S3のバックアップを安全に保存するためのオンラインサービスであるTarsnapプログラムの著者は、2011年に、データの暗号化時にランダムな値（nonce）を生成する手順のバグを報告しました 。

 --- tarsnap-autoconf-1.0.27/lib/crypto/crypto_file.c +++ tarsnap-autoconf-1.0.28/lib/crypto/crypto_file.c @@ -108,7 +108,7 @@ /* Encrypt the data. */ if ((stream = - crypto_aesctr_init(&encr_aes->key, encr_aes->nonce)) == NULL) + crypto_aesctr_init(&encr_aes->key, encr_aes->nonce++)) == NULL) goto err0; crypto_aesctr_stream(stream, buf, filebuf + CRYPTO_FILE_HLEN, len); crypto_aesctr_free(stream);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

暗号化されたデータの16バイトごとに新しいランダム値が生成されることになっていましたが、実際にはまったく変化しませんでした。



したがって、Appleがミスをするだけではありません。