ਸਰਟੀਫਿਕੇਟਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਸਮੇਂ ਮੋਜ਼ੀਲਾ NSS ਵਿੱਚ ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਕਮਜ਼ੋਰੀ

ਮੋਜ਼ੀਲਾ ਦੁਆਰਾ ਵਿਕਸਤ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੇ NSS (ਨੈਟਵਰਕ ਸੁਰੱਖਿਆ ਸੇਵਾਵਾਂ) ਸੈੱਟ ਵਿੱਚ ਇੱਕ ਗੰਭੀਰ ਕਮਜ਼ੋਰੀ (CVE-2021-43527) ਦੀ ਪਛਾਣ ਕੀਤੀ ਗਈ ਹੈ, ਜੋ ਕਿ DSA ਜਾਂ RSA-PSS ਡਿਜੀਟਲ ਹਸਤਾਖਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਹਮਲਾਵਰ ਕੋਡ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਅਗਵਾਈ ਕਰ ਸਕਦੀ ਹੈ। DER ਏਨਕੋਡਿੰਗ ਵਿਧੀ (ਵਿਸ਼ੇਸ਼ ਏਨਕੋਡਿੰਗ ਨਿਯਮ)। ਮੁੱਦਾ, ਕੋਡਨੇਮ ਬਿਗਸਿਗ, NSS 3.73 ਅਤੇ NSS ESR 3.68.1 ਵਿੱਚ ਹੱਲ ਕੀਤਾ ਗਿਆ ਹੈ। ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨਾਂ ਵਿੱਚ ਪੈਕੇਜ ਅੱਪਡੇਟ ਡੇਬੀਅਨ, ਆਰਐਚਈਐਲ, ਉਬੰਟੂ, ਸੂਸੇ, ਆਰਚ ਲੀਨਕਸ, ਜੈਂਟੂ, ਫ੍ਰੀਬੀਐਸਡੀ ਲਈ ਉਪਲਬਧ ਹਨ। ਫੇਡੋਰਾ ਲਈ ਅਜੇ ਕੋਈ ਅੱਪਡੇਟ ਉਪਲਬਧ ਨਹੀਂ ਹੈ।

ਸਮੱਸਿਆ ਉਹਨਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਹੁੰਦੀ ਹੈ ਜੋ CMS, S/MIME, PKCS #7 ਅਤੇ PKCS #12 ਡਿਜ਼ੀਟਲ ਦਸਤਖਤਾਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ NSS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਜਾਂ TLS, X.509, OCSP ਅਤੇ CRL ਲਾਗੂਕਰਨਾਂ ਵਿੱਚ ਸਰਟੀਫਿਕੇਟਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਸਮੇਂ। ਕਮਜ਼ੋਰੀ ਵੱਖ-ਵੱਖ ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਦਿਖਾਈ ਦੇ ਸਕਦੀ ਹੈ ਜੋ TLS, DTLS ਅਤੇ S/MIME, ਈਮੇਲ ਕਲਾਇੰਟਸ ਅਤੇ PDF ਦਰਸ਼ਕ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ ਜੋ ਡਿਜੀਟਲ ਦਸਤਖਤਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ NSS CERT_VerifyCertificate() ਕਾਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।

ਲਿਬਰੇਆਫਿਸ, ਈਵੇਲੂਸ਼ਨ ਅਤੇ ਈਵਿੰਸ ਨੂੰ ਕਮਜ਼ੋਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਵਜੋਂ ਦਰਸਾਇਆ ਗਿਆ ਹੈ। ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ, ਸਮੱਸਿਆ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਵੀ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀ ਹੈ ਜਿਵੇਂ ਕਿ Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat ਡਾਇਰੈਕਟਰੀ ਸਰਵਰ, Red Hat ਸਰਟੀਫਿਕੇਟ ਸਿਸਟਮ, Apache http ਸਰਵਰ ਲਈ mod_nss, ਓਰੇਕਲ ਕਮਿਊਨੀਕੇਸ਼ਨ ਮੈਸੇਜਿੰਗ ਸਰਵਰ, ਓਰੇਕਲ ਡਾਇਰੈਕਟਰੀ ਸਰਵਰ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਐਡੀਸ਼ਨ। ਹਾਲਾਂਕਿ, ਫਾਇਰਫਾਕਸ, ਥੰਡਰਬਰਡ ਅਤੇ ਟੋਰ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਕਮਜ਼ੋਰੀ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦੀ, ਜੋ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਇੱਕ ਵੱਖਰੀ ਮੋਜ਼ੀਲਾ::ਪੀਕਿਕਸ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਜੋ ਕਿ NSS ਵਿੱਚ ਵੀ ਸ਼ਾਮਲ ਹੈ। Chromium-ਆਧਾਰਿਤ ਬ੍ਰਾਊਜ਼ਰ (ਜਦੋਂ ਤੱਕ ਕਿ ਉਹ ਖਾਸ ਤੌਰ 'ਤੇ NSS ਨਾਲ ਨਹੀਂ ਬਣਾਏ ਗਏ ਹਨ), ਜੋ ਕਿ 2015 ਤੱਕ NSS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਨ, ਪਰ ਫਿਰ ਬੋਰਿੰਗSSL ਵਿੱਚ ਬਦਲ ਗਏ ਸਨ, ਵੀ ਸਮੱਸਿਆ ਤੋਂ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਹੁੰਦੇ ਹਨ।

ਕਮਜ਼ੋਰੀ secvfy.c ਫਾਈਲ ਤੋਂ vfy_CreateContext ਫੰਕਸ਼ਨ ਵਿੱਚ ਸਰਟੀਫਿਕੇਟ ਤਸਦੀਕ ਕੋਡ ਵਿੱਚ ਇੱਕ ਗਲਤੀ ਕਾਰਨ ਹੁੰਦੀ ਹੈ। ਗਲਤੀ ਉਦੋਂ ਵਾਪਰਦੀ ਹੈ ਜਦੋਂ ਕਲਾਇੰਟ ਸਰਵਰ ਤੋਂ ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਸਰਵਰ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ। DER-ਏਨਕੋਡ ਕੀਤੇ ਡਿਜੀਟਲ ਦਸਤਖਤ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਸਮੇਂ, NSS ਦਸਤਖਤ ਨੂੰ ਇੱਕ ਨਿਸ਼ਚਿਤ-ਆਕਾਰ ਦੇ ਬਫਰ ਵਿੱਚ ਡੀਕੋਡ ਕਰਦਾ ਹੈ ਅਤੇ ਬਫਰ ਨੂੰ PKCS #11 ਮੋਡੀਊਲ ਵਿੱਚ ਭੇਜਦਾ ਹੈ। ਅੱਗੇ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਦੌਰਾਨ, DSA ਅਤੇ RSA-PSS ਦਸਤਖਤਾਂ ਲਈ ਆਕਾਰ ਦੀ ਗਲਤ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਨਾਲ VFYContextStr ਢਾਂਚੇ ਲਈ ਨਿਰਧਾਰਤ ਬਫਰ ਦਾ ਓਵਰਫਲੋ ਹੋ ਜਾਂਦਾ ਹੈ ਜੇਕਰ ਡਿਜੀਟਲ ਦਸਤਖਤ ਦਾ ਆਕਾਰ 16384 ਬਿੱਟ ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ (2048 ਬਾਈਟ ਬਫਰ ਲਈ ਨਿਰਧਾਰਤ ਕੀਤੇ ਗਏ ਹਨ, ਪਰ ਇਹ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ ਕਿ ਦਸਤਖਤ ਵੱਡੇ ਹੋ ਸਕਦੇ ਹਨ))।

ਕਮਜ਼ੋਰੀ ਵਾਲੇ ਕੋਡ ਨੂੰ 2003 ਵਿੱਚ ਲੱਭਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ 2012 ਵਿੱਚ ਰੀਫੈਕਟਰਿੰਗ ਹੋਣ ਤੱਕ ਇਸ ਨੂੰ ਕੋਈ ਖ਼ਤਰਾ ਨਹੀਂ ਸੀ। 2017 ਵਿੱਚ, RSA-PSS ਸਹਾਇਤਾ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵੇਲੇ ਉਹੀ ਗਲਤੀ ਕੀਤੀ ਗਈ ਸੀ। ਹਮਲੇ ਨੂੰ ਅੰਜਾਮ ਦੇਣ ਲਈ, ਲੋੜੀਂਦੇ ਡੇਟਾ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕੁਝ ਕੁੰਜੀਆਂ ਦੀ ਸੰਸਾਧਨ-ਗੰਭੀਰ ਉਤਪਾਦਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਡਿਜ਼ੀਟਲ ਦਸਤਖਤ ਦੀ ਸ਼ੁੱਧਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੜਾਅ 'ਤੇ ਓਵਰਫਲੋ ਹੁੰਦਾ ਹੈ। ਡੇਟਾ ਦਾ ਉਹ ਹਿੱਸਾ ਜੋ ਸੀਮਾਵਾਂ ਤੋਂ ਪਾਰ ਜਾਂਦਾ ਹੈ, ਇੱਕ ਮੈਮੋਰੀ ਖੇਤਰ ਵਿੱਚ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਫੰਕਸ਼ਨਾਂ ਲਈ ਪੁਆਇੰਟਰ ਹੁੰਦੇ ਹਨ, ਜੋ ਕਾਰਜਸ਼ੀਲ ਸ਼ੋਸ਼ਣਾਂ ਦੀ ਸਿਰਜਣਾ ਨੂੰ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ।

ਗੂਗਲ ਪ੍ਰੋਜੈਕਟ ਜ਼ੀਰੋ ਦੇ ਖੋਜਕਰਤਾਵਾਂ ਦੁਆਰਾ ਨਵੇਂ ਫਜ਼ਿੰਗ ਟੈਸਟਿੰਗ ਤਰੀਕਿਆਂ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰਦੇ ਸਮੇਂ ਕਮਜ਼ੋਰੀ ਦੀ ਖੋਜ ਕੀਤੀ ਗਈ ਸੀ ਅਤੇ ਇਹ ਇਸ ਗੱਲ ਦਾ ਇੱਕ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਹੈ ਕਿ ਕਿਵੇਂ ਇੱਕ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਟੈਸਟ ਕੀਤੇ ਜਾਣੇ-ਪਛਾਣੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਮਾਮੂਲੀ ਕਮਜ਼ੋਰੀਆਂ ਦਾ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਪਤਾ ਨਹੀਂ ਲਗਾਇਆ ਜਾ ਸਕਦਾ ਹੈ:

• NSS ਕੋਡ ਨੂੰ ਇੱਕ ਤਜਰਬੇਕਾਰ ਸੁਰੱਖਿਆ ਟੀਮ ਦੁਆਰਾ ਆਧੁਨਿਕ ਟੈਸਟਿੰਗ ਅਤੇ ਗਲਤੀ ਵਿਸ਼ਲੇਸ਼ਣ ਤਕਨੀਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਣਾਈ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ। NSS ਵਿੱਚ ਕਮਜ਼ੋਰੀਆਂ ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ ਮਹੱਤਵਪੂਰਨ ਇਨਾਮ ਦੇਣ ਲਈ ਕਈ ਪ੍ਰੋਗਰਾਮ ਹਨ।
• NSS Google ਦੀ oss-fuzz ਪਹਿਲਕਦਮੀ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਵਾਲੇ ਪਹਿਲੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸੀ ਅਤੇ ਇਸਨੂੰ ਮੋਜ਼ੀਲਾ ਦੇ libFuzer-ਅਧਾਰਿਤ ਫਜ਼ ਟੈਸਟਿੰਗ ਸਿਸਟਮ ਵਿੱਚ ਵੀ ਟੈਸਟ ਕੀਤਾ ਗਿਆ ਸੀ।
• ਲਾਇਬ੍ਰੇਰੀ ਕੋਡ ਨੂੰ ਵੱਖ-ਵੱਖ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਕਾਂ ਵਿੱਚ ਕਈ ਵਾਰ ਜਾਂਚਿਆ ਗਿਆ ਹੈ, ਜਿਸ ਵਿੱਚ 2008 ਤੋਂ Coverity ਸੇਵਾ ਦੁਆਰਾ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ।
• 2015 ਤੱਕ, NSS ਦੀ ਵਰਤੋਂ Google Chrome ਵਿੱਚ ਕੀਤੀ ਜਾਂਦੀ ਸੀ ਅਤੇ Google ਟੀਮ ਦੁਆਰਾ ਮੋਜ਼ੀਲਾ ਤੋਂ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਤਸਦੀਕ ਕੀਤੀ ਗਈ ਸੀ (2015 ਤੋਂ, Chrome ਨੇ BoringSSL ਵਿੱਚ ਸਵਿਚ ਕੀਤਾ, ਪਰ NSS-ਅਧਾਰਿਤ ਪੋਰਟ ਲਈ ਸਮਰਥਨ ਰਹਿੰਦਾ ਹੈ)।

ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ ਜਿਸ ਕਾਰਨ ਸਮੱਸਿਆ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਅਣਡਿੱਠ ਰਹੀ:

• NSS ਮਾਡਿਊਲਰ ਲਾਇਬ੍ਰੇਰੀ ਅਤੇ ਫਜ਼ਿੰਗ ਟੈਸਟਿੰਗ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਨਹੀਂ, ਪਰ ਵਿਅਕਤੀਗਤ ਭਾਗਾਂ ਦੇ ਪੱਧਰ 'ਤੇ ਕੀਤੀ ਗਈ ਸੀ। ਉਦਾਹਰਨ ਲਈ, DER ਅਤੇ ਪ੍ਰੋਸੈਸਿੰਗ ਸਰਟੀਫਿਕੇਟਾਂ ਨੂੰ ਡੀਕੋਡ ਕਰਨ ਲਈ ਕੋਡ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਚੈੱਕ ਕੀਤਾ ਗਿਆ ਸੀ - ਫਜ਼ਿੰਗ ਦੇ ਦੌਰਾਨ, ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਸੀ ਜੋ ਪ੍ਰਸ਼ਨ ਵਿੱਚ ਕਮਜ਼ੋਰੀ ਦੇ ਪ੍ਰਗਟਾਵੇ ਵੱਲ ਲੈ ਜਾਂਦਾ ਸੀ, ਪਰ ਇਸਦਾ ਚੈੱਕ ਪੁਸ਼ਟੀਕਰਨ ਕੋਡ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਿਆ ਅਤੇ ਸਮੱਸਿਆ ਨਹੀਂ ਆਈ ਆਪਣੇ ਆਪ ਨੂੰ ਪ੍ਰਗਟ.
• ਫਜ਼ਿੰਗ ਟੈਸਟਿੰਗ ਦੇ ਦੌਰਾਨ, NSS ਵਿੱਚ ਸਮਾਨ ਪਾਬੰਦੀਆਂ ਦੀ ਅਣਹੋਂਦ ਵਿੱਚ ਆਉਟਪੁੱਟ ਆਕਾਰ (10000 ਬਾਈਟ) 'ਤੇ ਸਖਤ ਪਾਬੰਦੀਆਂ ਲਗਾਈਆਂ ਗਈਆਂ ਸਨ (ਆਮ ਮੋਡ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਢਾਂਚੇ 10000 ਬਾਈਟਾਂ ਤੋਂ ਵੱਧ ਦਾ ਆਕਾਰ ਹੋ ਸਕਦੇ ਹਨ, ਇਸਲਈ ਸਮੱਸਿਆਵਾਂ ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ ਵਧੇਰੇ ਇਨਪੁਟ ਡੇਟਾ ਦੀ ਲੋੜ ਸੀ) . ਪੂਰੀ ਤਸਦੀਕ ਲਈ, ਸੀਮਾ 224-1 ਬਾਈਟ (16 MB) ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਜੋ TLS ਵਿੱਚ ਮਨਜ਼ੂਰ ਅਧਿਕਤਮ ਸਰਟੀਫਿਕੇਟ ਆਕਾਰ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ।
• ਫਜ਼ ਟੈਸਟਿੰਗ ਕੋਡ ਕਵਰੇਜ ਬਾਰੇ ਗਲਤ ਧਾਰਨਾ। ਕਮਜ਼ੋਰ ਕੋਡ ਦੀ ਸਰਗਰਮੀ ਨਾਲ ਜਾਂਚ ਕੀਤੀ ਗਈ ਸੀ, ਪਰ ਫਜ਼ਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜੋ ਲੋੜੀਂਦਾ ਇਨਪੁਟ ਡੇਟਾ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥ ਸਨ। ਉਦਾਹਰਨ ਲਈ, fuzzer tls_server_target ਨੇ ਤਿਆਰ ਸਰਟੀਫਿਕੇਟਾਂ ਦੇ ਇੱਕ ਪੂਰਵ-ਪਰਿਭਾਸ਼ਿਤ ਸੈੱਟ ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਜੋ ਸਰਟੀਫਿਕੇਟ ਪੁਸ਼ਟੀਕਰਨ ਕੋਡ ਦੀ ਜਾਂਚ ਨੂੰ ਸਿਰਫ਼ TLS ਸੁਨੇਹਿਆਂ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਸਥਿਤੀ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਤੱਕ ਸੀਮਿਤ ਕਰਦਾ ਹੈ।

ਸਰੋਤ: opennet.ru