सिंगल लाइन कीड़े का इतिहास

Apple ने हाल ही में SSL कनेक्शन की स्थापना के दौरान सर्वर हस्ताक्षर को सत्यापित करने के लिए SSLVerifySignedServerKeyExchange फ़ंक्शन के बीच में गोटो बिना शर्त ऑपरेटर के साथ अतिरिक्त लाइन को हटाने के लिए भूलकर एक बड़ी गलती की । परिणामस्वरूप, सत्यापन सत्यापन परिणाम की परवाह किए बिना फ़ंक्शन सफलतापूर्वक पूरा हुआ।

हालाँकि, इतिहास में यह पहली बार नहीं है जब किसी एकल पंक्ति द्वारा किसी महत्वपूर्ण त्रुटि को समझाया गया हो। इस तरह के कुछ और उदाहरण हैं ।

एक्स सर्वर

2006 में, यह पता चला कि एक्स सर्वर उपयोगकर्ता के मूल अधिकारों की जांच करता है, लेकिन एक ही समय में, वास्तविकता में डेवलपर्स संबंधित फ़ंक्शन को कॉल करना भूल गया ।

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

डेबियन ओपनएसएसएल

2008 में, डेबियन ने स्वीकार किया कि इसके 2006 के मालिकाना ओपनएसएसएल कार्यान्वयन में छद्म यादृच्छिक संख्या जनरेटर वास्तव में अनुमानित संख्या उत्पन्न करता है।

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

कारण यह है कि टिप्पणी में एक महत्वपूर्ण पंक्ति शामिल थी। यह पूरी तरह से समझ में नहीं आता है कि इस तरह के ध्यान देने योग्य बग अंतिम रिलीज में कैसे आए, जैसे कि किसी ने भी कोड की जांच नहीं की थी। वैसे, कई ने तब डेबियन पर संदेह किया कि यह एक कारण से PRNG को "ब्रेक" नहीं करता था।

मानक ओपनएसएसएल

ओपनएसएसएल में एक और बग , और फिर 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); 

एंड्रॉयड

11 मई 2010 को 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; } 

सही पैरामीटर के बजाय, शून्य को मेमोरी में लिखा जाता है। यही है, फ़ंक्शन में पारित मापदंडों में से एक का उपयोग बिल्कुल नहीं किया जाता है।

Tarsnap

Tarsnap कार्यक्रम के लेखक, अमेज़ॅन S3 पर बैकअप के सुरक्षित भंडारण के लिए एक ऑनलाइन सेवा, 2011 में डेटा को एन्क्रिप्ट करते समय यादृच्छिक मान (गैर) उत्पन्न करने की प्रक्रिया में एक बग की सूचना दी ।

 --- 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 गलतियाँ करता है।