സർട്ടിഫിക്കറ്റുകൾ പ്രോസസ്സ് ചെയ്യുമ്പോൾ മോസില്ല NSS-ൽ കോഡ് എക്സിക്യൂഷൻ ദുർബലത

മോസില്ല വികസിപ്പിച്ച ക്രിപ്‌റ്റോഗ്രാഫിക് ലൈബ്രറികളുടെ NSS (നെറ്റ്‌വർക്ക് സെക്യൂരിറ്റി സർവീസസ്) സെറ്റിൽ ഗുരുതരമായ ഒരു കേടുപാടുകൾ (CVE-2021-43527) തിരിച്ചറിഞ്ഞിട്ടുണ്ട്, ഇത് ഉപയോഗിച്ച് വ്യക്തമാക്കിയ DSA അല്ലെങ്കിൽ RSA-PSS ഡിജിറ്റൽ സിഗ്നേച്ചറുകൾ പ്രോസസ്സ് ചെയ്യുമ്പോൾ ആക്രമണകാരി കോഡ് നടപ്പിലാക്കാൻ ഇത് ഇടയാക്കും. DER എൻകോഡിംഗ് രീതി ( വിശിഷ്ട എൻകോഡിംഗ് നിയമങ്ങൾ). ബിഗ്‌സിഗ് എന്ന കോഡ് നാമത്തിലുള്ള ഈ പ്രശ്നം NSS 3.73, NSS ESR 3.68.1 എന്നിവയിൽ പരിഹരിച്ചു. Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD എന്നിവയ്‌ക്കായി വിതരണങ്ങളിലെ പാക്കേജ് അപ്‌ഡേറ്റുകൾ ലഭ്യമാണ്. ഫെഡോറയ്‌ക്കായി ഇതുവരെ അപ്‌ഡേറ്റുകളൊന്നും ലഭ്യമല്ല.

CMS, S/MIME, PKCS #7, PKCS #12 ഡിജിറ്റൽ സിഗ്നേച്ചറുകൾ കൈകാര്യം ചെയ്യാൻ NSS ഉപയോഗിക്കുന്ന ആപ്ലിക്കേഷനുകളിലോ TLS, X.509, OCSP, CRL നടപ്പിലാക്കലുകളിൽ സർട്ടിഫിക്കറ്റുകൾ പരിശോധിക്കുമ്പോഴോ പ്രശ്നം സംഭവിക്കുന്നു. TLS, DTLS, S/MIME എന്നിവയെ പിന്തുണയ്ക്കുന്ന വിവിധ ക്ലയന്റ്, സെർവർ ആപ്ലിക്കേഷനുകൾ, ഇമെയിൽ ക്ലയന്റുകൾ, ഡിജിറ്റൽ സിഗ്നേച്ചറുകൾ പരിശോധിക്കാൻ NSS CERT_VerifyCertificate() കോൾ ഉപയോഗിക്കുന്ന PDF വ്യൂവർ എന്നിവയിൽ ഈ അപകടസാധ്യത ദൃശ്യമാകും.

LibreOffice, Evolution, Evince എന്നിവ ദുർബലമായ ആപ്ലിക്കേഷനുകളുടെ ഉദാഹരണങ്ങളായി പരാമർശിക്കപ്പെടുന്നു. Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss for Apache http സെർവർ, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition തുടങ്ങിയ പ്രോജക്ടുകളെയും പ്രശ്നം ബാധിച്ചേക്കാം. എന്നിരുന്നാലും, ഫയർഫോക്സ്, തണ്ടർബേർഡ്, ടോർ ബ്രൗസർ എന്നിവയിൽ ഈ അപകടസാധ്യത ദൃശ്യമാകില്ല, അവ പരിശോധിച്ചുറപ്പിക്കുന്നതിനായി NSS-ൽ ഉൾപ്പെടുത്തിയിരിക്കുന്ന പ്രത്യേക മോസില്ല ::pkix ലൈബ്രറി ഉപയോഗിക്കുന്നു. 2015 വരെ NSS ഉപയോഗിച്ചിരുന്ന, എന്നാൽ പിന്നീട് BoringSSL-ലേക്ക് മാറിയ Chromium-അധിഷ്‌ഠിത ബ്രൗസറുകളെയും (അവ പ്രത്യേകമായി NSS ഉപയോഗിച്ച് നിർമ്മിച്ചിട്ടില്ലെങ്കിൽ) പ്രശ്‌നം ബാധിക്കില്ല.

secvfy.c ഫയലിൽ നിന്നുള്ള vfy_CreateContext ഫംഗ്‌ഷനിലെ സർട്ടിഫിക്കറ്റ് വെരിഫിക്കേഷൻ കോഡിലെ ഒരു പിശകാണ് ഈ അപകടത്തിന് കാരണം. ക്ലയന്റ് സെർവറിൽ നിന്ന് ഒരു സർട്ടിഫിക്കറ്റ് വായിക്കുമ്പോഴും സെർവർ ക്ലയന്റ് സർട്ടിഫിക്കറ്റുകൾ പ്രോസസ്സ് ചെയ്യുമ്പോഴും പിശക് സംഭവിക്കുന്നു. ഒരു DER-എൻകോഡ് ചെയ്ത ഡിജിറ്റൽ സിഗ്നേച്ചർ പരിശോധിക്കുമ്പോൾ, NSS ഒപ്പിനെ ഒരു നിശ്ചിത വലിപ്പത്തിലുള്ള ബഫറിലേക്ക് ഡീകോഡ് ചെയ്യുകയും PKCS #11 മൊഡ്യൂളിലേക്ക് ബഫർ കൈമാറുകയും ചെയ്യുന്നു. കൂടുതൽ പ്രോസസ്സിംഗ് സമയത്ത്, DSA, RSA-PSS സിഗ്നേച്ചറുകൾക്കായി വലുപ്പം തെറ്റായി പരിശോധിച്ചു, ഇത് ഡിജിറ്റൽ സിഗ്നേച്ചറിന്റെ വലുപ്പം 16384 ബിറ്റുകളിൽ കൂടുതലാണെങ്കിൽ VFYContextStr ഘടനയ്‌ക്കായി അനുവദിച്ച ബഫറിന്റെ ഓവർഫ്ലോയിലേക്ക് നയിക്കുന്നു (2048 ബൈറ്റുകൾ ബഫറിനായി അനുവദിച്ചിരിക്കുന്നു, പക്ഷേ ഒപ്പ് വലുതായിരിക്കുമോ എന്ന് പരിശോധിച്ചിട്ടില്ല) ).

അപകടസാധ്യത അടങ്ങിയ കോഡ് 2003 മുതൽ കണ്ടെത്താനാകും, പക്ഷേ 2012-ൽ റീഫാക്‌ടറിംഗ് നടത്തുന്നതുവരെ ഇത് ഒരു ഭീഷണിയും സൃഷ്ടിച്ചില്ല. 2017ൽ, ആർഎസ്എ-പിഎസ്എസ് പിന്തുണ നടപ്പാക്കുമ്പോഴും ഇതേ തെറ്റ് സംഭവിച്ചു. ഒരു ആക്രമണം നടത്താൻ, ഡിജിറ്റൽ സിഗ്നേച്ചറിന്റെ കൃത്യത പരിശോധിക്കുന്നതിന് മുമ്പുള്ള ഘട്ടത്തിൽ ഓവർഫ്ലോ സംഭവിക്കുന്നതിനാൽ, ആവശ്യമായ ഡാറ്റ ലഭിക്കുന്നതിന് ചില കീകളുടെ ഉറവിട-ഇന്റൻസീവ് ജനറേഷൻ ആവശ്യമില്ല. അതിരുകൾക്കപ്പുറത്തേക്ക് പോകുന്ന ഡാറ്റയുടെ ഭാഗം ഫംഗ്ഷനുകളിലേക്കുള്ള പോയിന്ററുകൾ അടങ്ങിയ മെമ്മറി ഏരിയയിലേക്ക് എഴുതിയിരിക്കുന്നു, ഇത് പ്രവർത്തന ചൂഷണങ്ങളുടെ സൃഷ്ടിയെ ലളിതമാക്കുന്നു.

ഗൂഗിൾ പ്രൊജക്റ്റ് സീറോയിൽ നിന്നുള്ള ഗവേഷകർ പുതിയ ഫസ്സിംഗ് ടെസ്റ്റിംഗ് രീതികൾ പരീക്ഷിക്കുന്നതിനിടെയാണ് ഈ അപകടസാധ്യത കണ്ടെത്തിയത്, കൂടാതെ വ്യാപകമായി പരീക്ഷിക്കപ്പെട്ട അറിയപ്പെടുന്ന ഒരു പ്രോജക്റ്റിൽ എത്രത്തോളം നിസ്സാരമായ കേടുപാടുകൾ കണ്ടെത്താനാകാതെ പോകുന്നു എന്നതിന്റെ മികച്ച പ്രകടനമാണിത്:

• അത്യാധുനിക പരിശോധനയും പിശക് വിശകലന സാങ്കേതിക വിദ്യകളും ഉപയോഗിച്ച് പരിചയസമ്പന്നരായ ഒരു സുരക്ഷാ ടീമാണ് NSS കോഡ് പരിപാലിക്കുന്നത്. എൻഎസ്എസിലെ കേടുപാടുകൾ തിരിച്ചറിയുന്നതിന് ഗണ്യമായ പ്രതിഫലം നൽകുന്നതിന് നിരവധി പ്രോഗ്രാമുകൾ നിലവിലുണ്ട്.
• ഗൂഗിളിന്റെ ഓസ്-ഫസ് സംരംഭത്തിൽ ചേരുന്ന ആദ്യത്തെ പ്രോജക്റ്റുകളിൽ ഒന്നാണ് എൻഎസ്എസ്, മോസില്ലയുടെ ലിബ്ഫസ്സർ അടിസ്ഥാനമാക്കിയുള്ള ഫസ് ടെസ്റ്റിംഗ് സിസ്റ്റത്തിലും ഇത് പരീക്ഷിക്കപ്പെട്ടു.
• 2008 മുതൽ കവറിറ്റി സേവനം നിരീക്ഷിക്കുന്നത് ഉൾപ്പെടെ വിവിധ സ്റ്റാറ്റിക് അനലൈസറുകളിൽ ലൈബ്രറി കോഡ് നിരവധി തവണ പരിശോധിച്ചു.
• 2015 വരെ, ഗൂഗിൾ ക്രോമിൽ എൻഎസ്എസ് ഉപയോഗിച്ചിരുന്നു, മോസില്ലയിൽ നിന്ന് സ്വതന്ത്രമായി ഗൂഗിൾ ടീം സ്വതന്ത്രമായി പരിശോധിച്ചുറപ്പിച്ചു (2015 മുതൽ, ക്രോം ബോറിംഗ്എസ്എസ്എല്ലിലേക്ക് മാറി, പക്ഷേ എൻഎസ്എസ് അധിഷ്ഠിത പോർട്ടിനുള്ള പിന്തുണ നിലനിൽക്കുന്നു).

പ്രശ്നം വളരെക്കാലമായി കണ്ടെത്താനാകാത്ത പ്രധാന പ്രശ്നങ്ങൾ:

• എൻഎസ്എസ് മോഡുലാർ ലൈബ്രറിയും ഫസ്സിംഗ് ടെസ്റ്റിംഗും മൊത്തത്തിൽ അല്ല, വ്യക്തിഗത ഘടകങ്ങളുടെ തലത്തിലാണ് നടത്തിയത്. ഉദാഹരണത്തിന്, DER ഡീകോഡ് ചെയ്യുന്നതിനും സർട്ടിഫിക്കറ്റുകൾ പ്രോസസ്സ് ചെയ്യുന്നതിനുമുള്ള കോഡ് വെവ്വേറെ പരിശോധിച്ചു - ഫസ് ചെയ്യുന്നതിനിടയിൽ, സംശയാസ്പദമായ അപകടസാധ്യത പ്രകടിപ്പിക്കുന്നതിലേക്ക് നയിക്കുന്ന ഒരു സർട്ടിഫിക്കറ്റ് നേടാമായിരുന്നു, പക്ഷേ അതിന്റെ പരിശോധന പരിശോധനാ കോഡിൽ എത്തിയില്ല, പ്രശ്നം ഉണ്ടായില്ല. സ്വയം വെളിപ്പെടുത്തുക.
• ഫസ്സിംഗ് ടെസ്റ്റിംഗ് സമയത്ത്, NSS-ൽ സമാനമായ നിയന്ത്രണങ്ങളുടെ അഭാവത്തിൽ ഔട്ട്‌പുട്ട് വലുപ്പത്തിൽ (10000 ബൈറ്റുകൾ) കർശന നിയന്ത്രണങ്ങൾ സജ്ജീകരിച്ചു (സാധാരണ മോഡിലെ പല ഘടനകൾക്കും 10000 ബൈറ്റുകളിൽ കൂടുതൽ വലുപ്പമുണ്ടാകാം, അതിനാൽ പ്രശ്നങ്ങൾ തിരിച്ചറിയാൻ കൂടുതൽ ഇൻപുട്ട് ഡാറ്റ ആവശ്യമാണ്) . പൂർണ്ണ സ്ഥിരീകരണത്തിന്, TLS-ൽ അനുവദനീയമായ പരമാവധി സർട്ടിഫിക്കറ്റ് വലുപ്പവുമായി പൊരുത്തപ്പെടുന്ന പരിധി 224-1 ബൈറ്റുകൾ (16 MB) ആയിരിക്കണം.
• ഫസ് ടെസ്റ്റിംഗ് കോഡ് കവറേജിനെക്കുറിച്ചുള്ള തെറ്റിദ്ധാരണ. ദുർബലമായ കോഡ് സജീവമായി പരീക്ഷിച്ചു, പക്ഷേ ആവശ്യമായ ഇൻപുട്ട് ഡാറ്റ സൃഷ്ടിക്കാൻ കഴിയാത്ത ഫസ്സറുകൾ ഉപയോഗിച്ചു. ഉദാഹരണത്തിന്, fuzer tls_server_target ഒരു മുൻകൂട്ടി നിശ്ചയിച്ചിട്ടുള്ള റെഡിമെയ്ഡ് സർട്ടിഫിക്കറ്റുകൾ ഉപയോഗിച്ചു, ഇത് സർട്ടിഫിക്കറ്റ് സ്ഥിരീകരണ കോഡ് പരിശോധനയെ TLS സന്ദേശങ്ങളിലും പ്രോട്ടോക്കോൾ നില മാറ്റങ്ങളിലും മാത്രമായി പരിമിതപ്പെടുത്തി.

അവലംബം: opennet.ru