سرٹیفکیٹ پر کارروائی کرتے وقت موزیلا این ایس ایس میں کوڈ پر عمل درآمد کا خطرہ

موزیلا کی طرف سے تیار کردہ کرپٹوگرافک لائبریریوں کے NSS (نیٹ ورک سیکیورٹی سروسز) سیٹ میں ایک نازک خطرے (CVE-2021-43527) کی نشاندہی کی گئی ہے، جو DSA یا RSA-PSS ڈیجیٹل دستخطوں پر کارروائی کرتے وقت حملہ آور کوڈ کے نفاذ کا باعث بن سکتی ہے۔ DER انکوڈنگ کا طریقہ (ممتاز انکوڈنگ رولز)۔ مسئلہ، کوڈ نام BigSig، 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، ای میل کلائنٹس اور PDF ناظرین کو سپورٹ کرتے ہیں جو ڈیجیٹل دستخطوں کی تصدیق کے لیے NSS CERT_VerifyCertificate() کال کا استعمال کرتے ہیں۔

LibreOffice، Evolution اور Evince کا ذکر کمزور ایپلی کیشنز کی مثالوں کے طور پر کیا گیا ہے۔ ممکنہ طور پر، یہ مسئلہ Pidgin، Apache OpenOffice، Suricata، Curl، Chrony، Red Hat ڈائریکٹری سرور، Red Hat سرٹیفکیٹ سسٹم، Apache HTTP سرور کے لیے mod_nss، اوریکل کمیونیکیشنز میسجنگ سرور، اوریکل ڈائرکٹری سرور انٹرپرائز ایڈیشن جیسے پروجیکٹس کو بھی متاثر کر سکتا ہے۔ تاہم، خطرات Firefox، Thunderbird اور Tor Browser میں ظاہر نہیں ہوتے ہیں، جو تصدیق کے لیے NSS میں شامل ایک علیحدہ mozilla::pkix لائبریری کا استعمال کرتے ہیں۔ Chromium پر مبنی براؤزرز (جب تک کہ وہ خاص طور پر NSS کے ساتھ نہ بنائے گئے ہوں)، جو 2015 تک NSS استعمال کرتے تھے، لیکن پھر بورنگSSL میں تبدیل ہو گئے، وہ بھی اس مسئلے سے متاثر نہیں ہوتے ہیں۔

خطرہ secvfy.c فائل سے vfy_CreateContext فنکشن میں سرٹیفکیٹ کے تصدیقی کوڈ میں خرابی کی وجہ سے ہے۔ خرابی اس وقت ہوتی ہے جب کلائنٹ سرور سے سرٹیفکیٹ پڑھتا ہے اور جب سرور کلائنٹ سرٹیفکیٹس پر کارروائی کرتا ہے۔ DER-encoded ڈیجیٹل دستخط کی تصدیق کرتے وقت، NSS دستخط کو ایک مقررہ سائز کے بفر میں ڈی کوڈ کرتا ہے اور بفر کو PKCS #11 ماڈیول میں منتقل کرتا ہے۔ مزید پروسیسنگ کے دوران، DSA اور RSA-PSS دستخطوں کے لیے سائز کو غلط طریقے سے چیک کیا جاتا ہے، جو VFYContextStr ڈھانچے کے لیے مختص کردہ بفر کے اوور فلو کا باعث بنتا ہے اگر ڈیجیٹل دستخط کا سائز 16384 بٹس سے زیادہ ہو (بفر کے لیے 2048 بائٹس مختص کیے گئے ہیں، لیکن یہ چیک نہیں کیا گیا ہے کہ دستخط بڑا ہو سکتا ہے))۔

کمزوری پر مشتمل کوڈ کا پتہ 2003 سے لگایا جا سکتا ہے، لیکن 2012 میں ری فیکٹرنگ ہونے تک اسے کوئی خطرہ نہیں تھا۔ 2017 میں، RSA-PSS سپورٹ کو لاگو کرتے وقت یہی غلطی ہوئی تھی۔ حملے کو انجام دینے کے لیے، ضروری ڈیٹا حاصل کرنے کے لیے کچھ کلیدوں کے وسائل سے بھرپور جنریشن کی ضرورت نہیں ہے، کیونکہ ڈیجیٹل دستخط کی درستگی کی جانچ کرنے سے پہلے اسٹیج پر اوور فلو ہوتا ہے۔ اعداد و شمار کا وہ حصہ جو حدود سے باہر جاتا ہے میموری کے علاقے میں لکھا جاتا ہے جس میں افعال کی طرف اشارہ ہوتا ہے، جو کام کرنے والے کارناموں کی تخلیق کو آسان بناتا ہے۔

خطرے کو گوگل پروجیکٹ زیرو کے محققین نے نئے مبہم جانچ کے طریقوں کے ساتھ تجربہ کرتے ہوئے دریافت کیا تھا اور یہ اس بات کا ایک اچھا مظاہرہ ہے کہ کس طرح ایک وسیع پیمانے پر آزمائشی معروف پروجیکٹ میں معمولی کمزوریوں کا طویل عرصے تک پتہ نہیں چل سکتا:

• NSS کوڈ کو ایک تجربہ کار سیکورٹی ٹیم کے ذریعہ برقرار رکھا جاتا ہے جو جدید ترین جانچ اور خرابی کے تجزیہ کی تکنیکوں کا استعمال کرتی ہے۔ NSS میں کمزوریوں کی نشاندہی کرنے کے لیے اہم انعامات ادا کرنے کے لیے کئی پروگرام موجود ہیں۔
• NSS گوگل کے oss-fuzz اقدام میں شامل ہونے والے پہلے منصوبوں میں سے ایک تھا اور اس کا تجربہ Mozilla کے libFuzzer پر مبنی fuzz ٹیسٹنگ سسٹم میں بھی کیا گیا تھا۔
• لائبریری کوڈ کو متعدد بار مختلف جامد تجزیہ کاروں میں چیک کیا گیا ہے، بشمول 2008 سے Coverity سروس کے ذریعے نگرانی کی جا رہی ہے۔
• 2015 تک، NSS گوگل کروم میں استعمال کیا جاتا تھا اور موزیلا سے آزادانہ طور پر گوگل ٹیم کی طرف سے اس کی تصدیق کی گئی تھی (2015 سے، کروم نے بورنگ ایس ایس ایل میں تبدیل کیا، لیکن NSS پر مبنی پورٹ کے لیے سپورٹ باقی ہے)۔

اہم مسائل جن کی وجہ سے مسئلہ طویل عرصے تک پتہ نہیں چلا:

• NSS ماڈیولر لائبریری اور فزنگ ٹیسٹنگ مجموعی طور پر نہیں بلکہ انفرادی اجزاء کی سطح پر کی گئی۔ مثال کے طور پر، ڈی کوڈ کرنے کے لیے DER اور پروسیسنگ سرٹیفکیٹس کو الگ سے چیک کیا گیا تھا - fuzzing کے دوران، ایک سرٹیفکیٹ حاصل کیا جا سکتا تھا جو زیربحث کمزوری کو ظاہر کرنے کا باعث بنتا، لیکن اس کا چیک تصدیقی کوڈ تک نہیں پہنچا اور مسئلہ نہیں ہوا۔ خود کو ظاہر کرتا ہے.
• فزنگ ٹیسٹنگ کے دوران، NSS میں اسی طرح کی پابندیوں کی عدم موجودگی میں آؤٹ پٹ سائز (10000 بائٹس) پر سخت پابندیاں لگائی گئی تھیں (عام موڈ میں بہت سے ڈھانچے کا سائز 10000 بائٹس سے زیادہ ہو سکتا ہے، اس لیے مسائل کی نشاندہی کرنے کے لیے مزید ان پٹ ڈیٹا کی ضرورت تھی) . مکمل تصدیق کے لیے، حد 224-1 بائٹس (16 MB) ہونی چاہیے، جو TLS میں منظور شدہ سرٹیفکیٹ کے زیادہ سے زیادہ سائز کے مساوی ہے۔
• فز ٹیسٹنگ کوڈ کوریج کے بارے میں غلط فہمی۔ کمزور کوڈ کا فعال طور پر تجربہ کیا گیا تھا، لیکن فزرز کا استعمال کرتے ہوئے جو ضروری ان پٹ ڈیٹا تیار کرنے سے قاصر تھے۔ مثال کے طور پر، fuzzer tls_server_target نے تیار شدہ سرٹیفکیٹس کا ایک پہلے سے طے شدہ سیٹ استعمال کیا، جس نے سرٹیفکیٹ کے تصدیقی کوڈ کی جانچ کو صرف TLS پیغامات اور پروٹوکول کی حالت میں تبدیلیوں تک محدود رکھا۔

ماخذ: opennet.ru