The history of single-line bugs

Apple has recently made a major mistake , forgetting to remove the extra line with the goto unconditional transfer statement in the middle of the SSLVerifySignedServerKeyExchange function to verify the server signature when establishing an SSL connection. As a result, the function successfully terminated, regardless of the result of the signature verification.

However, this is not the first time in history when a critical error is explained by a single line of code. Here are some more such examples .

X Server

In 2006, it was discovered that the X Server checks the user's root rights, but at the same time, the developers in reality forgot to call the corresponding function .
')

--- 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

In 2008, Debian acknowledged that the pseudo-random number generator in its 2006 proprietary OpenSSL implementation actually generates predictable numbers.

 --- 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]++; 

The reason is that an important line was included in the comment. It is completely incomprehensible how such a noticeable bug got into the final release, as if no one had checked the code at all. By the way, many people then suspected Debian that it “broke” PRNG not by accident.

Standard OpenSSL

Another bug in OpenSSL , and again from 2008. OpenSSL 0.9.8i and earlier versions "incorrectly checked the value returned by the EVP_VerifyFinal function, which allowed attackers to bypass certificate validation using fake SSL / TLS signatures for DSA and ECDSA keys."

  --- 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

Look at the patch for memset.c of May 11, 2010.

 --- 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; } 

Instead of the correct parameter, zero is written to the memory. That is, one of the parameters passed to the function is not used at all.

Tarsnap

The author of the program Tarsnap, an online service for secure storage of backups on Amazon S3, in 2011 reported a bug in the procedure for generating a random value (nonce) when encrypting data.

 --- 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); 

A new random value had to be generated for every 16 bytes of encrypted data, but in reality it did not change at all.

So not only Apple makes mistakes.