🥇 শংসাপত্র প্রক্রিয়াকরণের সময় মজিলা এনএসএস কোড কার্যকর করার দুর্বলতা

মোজিলা দ্বারা তৈরি ক্রিপ্টোগ্রাফিক লাইব্রেরিগুলির NSS (নেটওয়ার্ক সিকিউরিটি সার্ভিসেস) সেটে একটি জটিল দুর্বলতা (CVE-2021-43527) চিহ্নিত করা হয়েছে, যা ব্যবহার করে নির্দিষ্ট করা DSA বা RSA-PSS ডিজিটাল স্বাক্ষর প্রক্রিয়া করার সময় আক্রমণকারী কোড কার্যকর করতে পারে। DER এনকোডিং পদ্ধতি (বিশিষ্ট এনকোডিং নিয়ম)। বিগসিগ কোডনাম দেওয়া সমস্যাটি NSS 3.73 এবং NSS ESR 3.68.1-এ সমাধান করা হয়েছে। ডেবিয়ান, আরএইচইএল, উবুন্টু, SUSE, আর্চ লিনাক্স, জেন্টু, ফ্রিবিএসডি-এর জন্য ডিস্ট্রিবিউশনে প্যাকেজ আপডেট পাওয়া যায়। ফেডোরার জন্য এখনও কোন আপডেট উপলব্ধ নেই।

CMS, S/MIME, PKCS #7 এবং PKCS #12 ডিজিটাল স্বাক্ষরগুলি পরিচালনা করার জন্য NSS ব্যবহার করে বা TLS, X.509, OCSP এবং CRL বাস্তবায়নে শংসাপত্র যাচাই করার সময় সমস্যাটি ঘটে। দুর্বলতা বিভিন্ন ক্লায়েন্ট এবং সার্ভার অ্যাপ্লিকেশনগুলিতে প্রদর্শিত হতে পারে যা TLS, DTLS এবং S/MIME সমর্থন করে, ইমেল ক্লায়েন্ট এবং PDF ভিউয়ার যারা ডিজিটাল স্বাক্ষর যাচাই করতে NSS CERT_VerifyCertificate() কল ব্যবহার করে।

LibreOffice, Evolution এবং Evince দুর্বল অ্যাপ্লিকেশনের উদাহরণ হিসেবে উল্লেখ করা হয়েছে। সম্ভবত, সমস্যাটি Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, Apache HTTP সার্ভারের জন্য mod_nss, ওরাকল কমিউনিকেশনস মেসেজিং সার্ভার, ওরাকল ডিরেক্টরি সার্ভার এন্টারপ্রাইজ সংস্করণের মতো প্রকল্পগুলিকেও প্রভাবিত করতে পারে। যাইহোক, ফায়ারফক্স, থান্ডারবার্ড এবং টর ব্রাউজারে দুর্বলতা দেখা যায় না, যা যাচাইয়ের জন্য NSS-এ অন্তর্ভুক্ত একটি পৃথক mozilla::pkix লাইব্রেরি ব্যবহার করে। ক্রোমিয়াম-ভিত্তিক ব্রাউজারগুলি (যদি না সেগুলি বিশেষভাবে এনএসএস দিয়ে তৈরি করা হয়), যেগুলি 2015 সাল পর্যন্ত এনএসএস ব্যবহার করেছিল, কিন্তু তারপরে বোরিংএসএসএল-এ স্যুইচ করা হয়েছিল, তারাও সমস্যা দ্বারা প্রভাবিত হয় না৷

secvfy.c ফাইল থেকে vfy_CreateContext ফাংশনে শংসাপত্র যাচাইকরণ কোডে একটি ত্রুটির কারণে দুর্বলতা সৃষ্টি হয়েছে। যখন ক্লায়েন্ট সার্ভার থেকে একটি শংসাপত্র পড়ে এবং যখন সার্ভার ক্লায়েন্ট শংসাপত্রগুলি প্রক্রিয়া করে তখন উভয়ই ত্রুটি ঘটে। একটি DER-এনকোডেড ডিজিটাল স্বাক্ষর যাচাই করার সময়, NSS স্বাক্ষরটিকে একটি নির্দিষ্ট আকারের বাফারে ডিকোড করে এবং PKCS #11 মডিউলে বাফারটি পাস করে। আরও প্রক্রিয়াকরণের সময়, DSA এবং RSA-PSS স্বাক্ষরগুলির জন্য আকারটি ভুলভাবে চেক করা হয়, যা VFYContextStr কাঠামোর জন্য বরাদ্দকৃত বাফারের ওভারফ্লোতে নিয়ে যায় যদি ডিজিটাল স্বাক্ষরের আকার 16384 বিট অতিক্রম করে (বাফারের জন্য 2048 বাইট বরাদ্দ করা হয়, কিন্তু এটি পরীক্ষা করা হয় না যে স্বাক্ষরটি বড় হতে পারে))।

দুর্বলতা সম্বলিত কোডটি 2003-এ চিহ্নিত করা যেতে পারে, তবে 2012 সালে রিফ্যাক্টরিং না হওয়া পর্যন্ত এটি কোনও হুমকি সৃষ্টি করেনি। 2017 সালে, RSA-PSS সমর্থন বাস্তবায়ন করার সময় একই ভুল করা হয়েছিল। একটি আক্রমণ চালানোর জন্য, প্রয়োজনীয় ডেটা পাওয়ার জন্য নির্দিষ্ট কীগুলির সংস্থান-নিবিড় প্রজন্মের প্রয়োজন হয় না, যেহেতু ডিজিটাল স্বাক্ষরের সঠিকতা পরীক্ষা করার আগে পর্যায়ে ওভারফ্লো ঘটে। ডেটার যে অংশটি সীমানা ছাড়িয়ে যায় তা একটি মেমরি এলাকায় লেখা হয় যাতে ফাংশনগুলির পয়েন্টার থাকে, যা কাজের শোষণের সৃষ্টিকে সহজ করে।

Google প্রোজেক্ট জিরোর গবেষকরা নতুন অস্পষ্ট পরীক্ষার পদ্ধতি নিয়ে পরীক্ষা করার সময় দুর্বলতাটি আবিষ্কার করেছিলেন এবং একটি ব্যাপকভাবে পরীক্ষিত সুপরিচিত প্রকল্পে কীভাবে তুচ্ছ দুর্বলতাগুলি দীর্ঘ সময়ের জন্য সনাক্ত করা যায় না তার একটি ভাল প্রদর্শনী:

এনএসএস কোড একটি অভিজ্ঞ নিরাপত্তা দল দ্বারা অত্যাধুনিক পরীক্ষা এবং ত্রুটি বিশ্লেষণ কৌশল ব্যবহার করে রক্ষণাবেক্ষণ করা হয়। এনএসএস-এ দুর্বলতা চিহ্নিত করার জন্য উল্লেখযোগ্য পুরষ্কার প্রদানের জন্য বেশ কয়েকটি প্রোগ্রাম রয়েছে।
NSS ছিল Google-এর oss-fuzz উদ্যোগে যোগদানের প্রথম প্রকল্পগুলির মধ্যে একটি এবং Mozilla-এর libFuzer-ভিত্তিক ফাজ টেস্টিং সিস্টেমেও পরীক্ষা করা হয়েছিল।
2008 সাল থেকে কভারিটি পরিষেবা দ্বারা পর্যবেক্ষণ করা সহ বিভিন্ন স্ট্যাটিক বিশ্লেষকগুলিতে লাইব্রেরি কোডটি বহুবার পরীক্ষা করা হয়েছে।
2015 সাল পর্যন্ত, NSS Google Chrome-এ ব্যবহার করা হয়েছিল এবং Mozilla থেকে স্বাধীনভাবে Google টিম দ্বারা স্বাধীনভাবে যাচাই করা হয়েছিল (2015 সাল থেকে, Chrome বোরিংএসএসএল-এ স্যুইচ করেছে, কিন্তু NSS-ভিত্তিক পোর্টের জন্য সমর্থন রয়ে গেছে)।

প্রধান সমস্যা যার কারণে সমস্যাটি দীর্ঘকাল ধরে সনাক্ত করা যায়নি:

এনএসএস মডুলার লাইব্রেরি এবং ফাজিং টেস্টিং সামগ্রিকভাবে নয়, পৃথক উপাদানের স্তরে করা হয়েছিল। উদাহরণস্বরূপ, DER ডিকোডিং এবং প্রসেসিং সার্টিফিকেটের কোড আলাদাভাবে চেক করা হয়েছিল - ফাজিংয়ের সময়, একটি শংসাপত্র পাওয়া যেত যা প্রশ্নে দুর্বলতার প্রকাশ ঘটাতে পারে, কিন্তু এটির চেক যাচাইকরণ কোডে পৌঁছায়নি এবং সমস্যা হয়নি নিজেকে প্রকাশ করা।
ফাজিং টেস্টিংয়ের সময়, NSS-এ অনুরূপ বিধিনিষেধের অনুপস্থিতিতে আউটপুট আকারের (10000 বাইট) উপর কঠোর বিধিনিষেধ সেট করা হয়েছিল (সাধারণ মোডে অনেক কাঠামোর আকার 10000 বাইটের বেশি হতে পারে, তাই সমস্যাগুলি সনাক্ত করতে আরও ইনপুট ডেটার প্রয়োজন ছিল) . সম্পূর্ণ যাচাইকরণের জন্য, সীমাটি 224-1 বাইট (16 MB) হওয়া উচিত, যা TLS-এ অনুমোদিত সর্বোচ্চ শংসাপত্রের আকারের সাথে মিলে যায়।
ফাজ টেস্টিং কোড কভারেজ সম্পর্কে ভুল ধারণা। দুর্বল কোডটি সক্রিয়ভাবে পরীক্ষা করা হয়েছিল, কিন্তু প্রয়োজনীয় ইনপুট ডেটা তৈরি করতে অক্ষম fuzzers ব্যবহার করে। উদাহরণ স্বরূপ, fuzzer tls_server_target প্রস্তুত-তৈরি শংসাপত্রের একটি পূর্বনির্ধারিত সেট ব্যবহার করে, যা শংসাপত্র যাচাইকরণ কোড চেককে শুধুমাত্র TLS বার্তা এবং প্রোটোকল অবস্থার পরিবর্তনের মধ্যে সীমাবদ্ধ করে।

উত্স: opennet.ru

শংসাপত্র প্রক্রিয়াকরণের সময় Mozilla NSS-এ কোড নির্বাহের দুর্বলতা

একটি মন্তব্য জুড়ুন উত্তর বাতিল