ایتھریم کلائنٹس میں ایک خرابی کو درست کیا گیا جو ETH انعامات کو دوبارہ ہدایت کر سکتی تھی
Teku اور Besu کے اپڈیٹس باہری بنیادی ڈھانچے کی حفاظت کی اہمیت پر روشنی ڈالتے ہیں
اکتوبر 2026 کے آخر میں، ethereum کنسنسس کلائنٹ Teku اور ایکزیکیشن کلائنٹ Besu نے بھارتی کمپنی eMudhra سے متعلقہ مخرب سرٹیفیکیٹ اتھارٹی کلیدوں سے جڑی ایک کمزوری کو بند کرنے کے لیے سیکورٹی ریلیزز جاری کیں۔ یہ خامی اس بات کا باعث بن سکتی تھی کہ جو حملہ آور کچھ HTTPS کنکشنز کو انٹر سیپٹ کرتے، وہ ویلیدیٹرز کے ذریعہ استعمال ہونے والی باہری سروسز کا دعویٰ کر سکتے اور بلاک انعامات کو دوبارہ ہدایت کر سکتے یا حساس دستخط حاصل کر سکتے۔ محققین نے پایا کہ eMudhra کے آٹھ درمیانی سرٹیفیکیٹ اتھارٹیز کی پرائیویٹ کلیدیں ناکافی رینڈومنس کے ساتھ تخلیق کی گئی تھیں، جس سے ان کلیدوں کو عوامی سرٹیفکیٹس سے ہی بحال کیا جا سکتا تھا۔ چونکہ دونوں کلائنٹس کے ذریعہ استعمال ہونے والے جاوا رن ٹائمز ڈि�فالٹ طور پر سرٹیفکیٹ ریووکیشن کا جائزہ نہیں لیتے، اس لیے کچھ ڈاکر امیجز اور نصب شدہ نظاموں میں براؤزرز اور بڑے آپریٹنگ سسٹمز کے انفرادی طور پر انہیں بلاک کرنے کے باوجود متاثرہ چینز پر اعتماد جاری رہا۔ HTTPS اینڈ پوائنٹس سے بچنے والے ڈیفالٹ مین نیٹ Teku کانفگریشنز متاثر نہ ہوئے، اور ڈوولپرز نے کوئی تصدیق شدہ استعمال نہیں بتایا۔
پیچز نے اپڈیٹ شدہ ڈاکر ایمیجز سے ملوث جڑوں پر بھروسہ ختم کر دیا ہے، جبکہ انفرادی بائنریز چلانے والے آپریٹرز کو اپنے مقامی جاوا بھروسہ اسٹورز کو الگ سے حل کرنا ہوگا۔ یہ واقعہ یہ ظاہر کرتا ہے کہ باہری بنیادی ڈھانچے کے انحصار کس طرح اسٹیکنگ آپریشنز کے لیے تنگ لیکن اعلیٰ اثر والے خطرات پیدا کر سکتے ہیں، حتیٰ کہ جب مرکزی پروٹوکول محفوظ رہے۔ ٹیکو اور بیسو کی تیز رفتار پاسندگی سے ثابت ہوتا ہے کہ ایتھریم کی کلائنٹ کی تنوع اور فعال سیکورٹی عملداریاں سرٹیفکیٹ سے متعلق خطرات کو اس سے پہلے روک سکتی ہیں کہ وہ ویلیدیٹر انعامات کو بڑے پیمانے پر متاثر کریں، شرط یہ ہے کہ آپریٹرز دستیاب اپڈیٹس لاگو کریں اور اپنے باہری کنکشن کنفگریشنز کا جائزہ لیں۔
ایمudhra انٹرمیڈیٹ کلیدز میں کمزور رینڈومنس نے قابل واپسی خصوصی مواد پیدا کیا
تحقیق کاروں نے 17 اکتوبر، 2026 کو پایا کہ eMudhra کے آٹھ درمیانی سرٹیفیکیٹ اتھارٹیز کے پرائیویٹ کلیدیں بہت کم اینٹروپی کے ساتھ تخلیق کی گئی تھیں۔ یہ کلیدیں عوامی سرٹیفکیٹس سے دوبارہ حاصل کی جا سکتی تھیں، ایک حالت جو اپریل 2025 میں کلید تخلیق کے موقع پر موجود تھی۔ آٹھوں میں سے چھ درمیانی TLS کنکشنز کو سپورٹ کرتے تھے، جبکہ دو کوڈ سائننگ سے متعلق تھے۔ جب پرائیویٹ مواد معلوم ہو گیا، تو حملہ آور وہ فراڈولنٹ سرٹیفکیٹس جاری کر سکتا تھا جنہیں متاثرہ اتھارٹیز پر بھروسہ کرنے والے سافٹ ویئر درست سمجھتے۔ eMudhra نے 18 اکتوبر کو درمیانی سرٹیفکیٹس منسوخ کر دیے۔ بڑے پلیٹ فارمز نے جلد ردعمل دیا: براؤزرز اور آپریٹنگ سسٹمز نے 17 اکتوبر سے 20 اکتوبر تک سرٹیفکیٹس بلاک کرنا شروع کر دیے، اور مائیکروسافٹ نے 26–27 اکتوبر کو ونڈوز اور ایج کے مزید اپڈیٹس جاری کئے جنہوں نے اپنی ٹرسٹ لسٹس سے متعلقہ رُوٹس ختم کر دیے۔ کرپٹوگرافک خرابی خود ایتھریم پروٹوکول کا مسئلہ نہیں تھا، لیکن یہ اہم تھا کیونکہ Teku اور Besu اپنے نوڈس کے ذریعہ بنائے جانے والے تمام HTTPS کنکشنز کے لیے جاوا سرٹیفکیٹ تصدیق پر انحصار کرتے ہیں۔ جاوا کا ڈفالٹ روایتِ منسوخ چیکس نظر انداز کرنا کچھ نصب و تنصیبات کو براؤزر ماحول کے مقابلے میں لمبے عرصے تک متاثر رکھا۔ اس واقعہ نے یہ ظاہر کیا کہ ایک واحد سرٹیفکیٹ اتھارٹی کا آپریشنل غلط عمل معیاری TLS ٹرسٹ اسٹورز پر انحصار کرنے والے خصوصی انفراسٹرکچر میں کس طرح پھیل سکتا ہے۔
کلیدوں کی واپسی کے لیے جٹل کریپٹو اینالسس کی ضرورت نہیں تھی؛ ناکافی تصادفیت نے عوامی سرٹیفکیٹس کے جائزہ لینے کے بعد ان کی حاصل کرنا آسان بنادیا۔ مائیکروسافٹ کی 26 اکتوبر کی اطلاع نے تصدیق کی کہ ان کلیدوں کا استعمال کرکے ایسے سرٹیفکیٹس بنائے جا سکتے ہیں جو ایک معتبر ادارے سے آنے والے لگ رہے ہوں، جس سے ویب سائٹس یا سروسز کی شناخت کا دھوکہ دینا ممکن ہو سکتا ہے۔ ایتھریم آپریٹرز کے لیے عملی نتیجہ یہ تھا کہ اگر کوئی ویلیدیٹر کانفگریشن HTTPS اینڈ پوائنٹس، ریموٹ بیکن نوڈز، باہری سائنرز، بلاک بِلڈرز یا ریلےز پر انحصار کرتی ہو تو اگر بنیادی جاوا رن ٹائم ابھی بھی متاثرہ چین پر اعتماد کرتا ہو تو وہ جعلی سرٹیفکیٹ قبول کر سکتی ہے۔ ایتھریم کلائنٹس کے ذریعہ استعمال کی جانے والی پیر-ٹو-پیر نیٹ ورکنگ متاثر نہیں ہوئی کیونکہ یہ ان سرٹیفکیٹ اتھارٹies پر انحصار نہیں کرتی۔ قابل واپسی والی کلیدوں اور غیر منسوخ جاوا ویریفکیشن کے امتزاج نے ایک ایسا وقت تشکیل دیا جس میں نیٹ ورک کے راستے پر موجود مین-این-ذ-مڈل حملہ آور کلائنٹ سافٹ وئیر کو ایک معقول شناخت پیش کرسکتا تھا۔ کلائنٹ ٹیمز نے صرف بنیادی جاوا اپڈیٹس کا انتظار نہ کرتے ہوئے اپنے ڈاکر تصاویر سے متعلقہ رُوٹس کو ختم کردیا، تاکہ جو آپریٹرز تازہ تصاویر ڈاؤن لوڈ کرینگے وہ مضبوط ٹرسٹ اسٹور حاصل کرسکین۔ یہ متعدد طبقات والی پاسدارانہ پالسی، CA پر منسوخی، پلे�ٹ فارم بلاکس، اور کلائنٹ خاص تصاویر کے اپڈیٹس نے زائد تر سٹیکنگ سیناریوز کے لئے عملی حملے کے سطح کو محدود کردیا۔
کیسے جعلی سرٹیفکیٹس بلاک پریپوزل اور فی ریسیپینٹ کے رویے کو تبدیل کر سکتے ہیں
ٹیکو کی سیکیورٹی مشورہ نے مخصوص حملوں کے راستے بیان کیے جو اس صورت میں ممکن ہو جاتے ہیں جب حملہ آور کلائنٹ کے ذریعہ قبول کیے جانے والی جھوٹی سرٹیفکیٹ پیش کر سکے۔ ایک سیناریو میں ایک ریموٹ بیکن نوڈ کا دھوکہ دینا شامل ہے جسے ویلیدیٹر تعاون کے لیے استعمال کرتا ہے۔ اگر کنکشن کو انٹرcept کر لیا جائے اور جھوٹی سرٹیفکیٹ قبول کر لی جائے، تو ویلیدیٹر اپنے پیش کرنے والے بلاک کے بارے میں مانیپولیٹڈ معلومات حاصل کر سکتا ہے۔ اس صورت میں، کلائنٹ ایسا بلاک بنائے اور دستخط کر سکتا ہے جس کا فی-ریسیپینٹ اکاؤنٹ حملہ آور کے قبضے میں ہو، نہ کہ آپریٹر کا مقررہ اکاؤنٹ۔ بلاک میں شامل ٹرانزیکشن فیز اور کوئی بھی ترجیحی ٹپس پھر حملہ آور کو جائیں گے۔ مشورہ نے باہری دستخط سروسز کو بھی ظاہر کیا، جو ویلیدیٹر کلیدز کو الگ رکھتی ہیں اور درخواست پر دستخط واپس کرتی ہیں۔ ایک حملہ آور جو اس قسم کے دستخط کرنے والے کا دھوکہ دے سکے، حساس آپریشنز، بشمول ان انعامات کے جہاں جانے والے چینجز کے لیے استعمال ہونے والے دستخط حاصل کر سکتا ہے۔ ٹیکو نے باہری سائنر کے معاملے کو زیادہ سنگین تر ترتیب دیا، حالانکہ بعض سیٹ اپس میں مچوال TLS توثیق سے اثر صرف سروس انکار تک محدود رہتا ہے، دستخط کا compromis نہیں۔
مکمل طور پر اظہار کیے گئے کنکشن کی قسمیں ایکزیکیشن کلائنٹس، بلاک بیلڈرز، ریلےز، اور ویلیڈیٹر کنفیگریشن ڈیٹا فراہم کرنے والی سروسز شامل ہیں۔ ہر صورت میں بنیادی خطرہ ایک جیسا ہے: کلائنٹ سافٹ ویئر جعلی سرٹیفکیٹ کو قانونی سمجھتا ہے اور اس لیے اسے ایک پیشکش شدہ بلاک کے مواد یا کلیدوں کے استعمال کو تبدیل کرنے والے ڈیٹا یا ہدایات قبول کر لیتا ہے۔ یہ کمزوری عام حالات میں ویلیڈیٹر کے سائننگ کلید تک براہ راست رسائی نہیں دیتی؛ بلکہ یہ ویلیڈیٹر کے جو برونی سروسز استعمال کرتا ہے، ان کی مکملیت کو خراب کر دیتی ہے۔ چونکہ ethereum بلاک انعامات اور فees پیشکش شدہ بلاک میں شامل پتے کے مطابق ادا کی جاتی ہیں، اس لیے پیشکش کے وقت کامیاب دھوکہ دہی سے پہلے سے کمائے گئے فنڈز کو منتقل کئے بغیر ہی قدر کو منحرف کیا جا سکتا ہے۔ ان راستوں کا استعمال کرنے کی کوئی رپورٹ نہیں ہوئی ہے، اور اس کنفگریشن میں HTTPS URL نہ ہونے والے ڈि�فالٹ مین نیٹ Teku انسٹالیشنز متاثرہ سیٹ سے باہر رہتے ہیں۔ تفصیلی مناظر تاہم واضح طور پر ظاہر کرتے ہیں کہ کلائنٹ ٹیم نے اس مسئلے کو فوری Docker-imag اپڈیٹس کی ضرورت قرار دیا، حالانکہ بنیادی پروٹوکول اور پیر-ٹو-پیر لیرز مسلسل رہے۔
Teku 26.10.3 ڈاکر ٹرسٹ اسٹورز سے متاثرہ ریٹس کو ختم کر دیتا ہے
Teku نے 27 اکتوبر، 2026 کو eMudhra سے متعلق ایکسپوژر کو حل کرنے کے لیے ورژن 26.10.3 جاری کیا۔ ریلیز نوٹس میں کہا گیا ہے کہ Docker امیجز اب emSign ECC Root CA – G3، emSign Root CA – G1، emSign Root CA – G2، یا AAA Certificate Services رُوٹس پر بھروسہ نہیں کرتے۔ ان رُوٹس کو OpenJDK نے انٹرمیڈیٹ اتھارٹیز کے compromis ہونے کے بعد ہٹا دیا تھا؛ Teku کے ذریعہ استعمال کیے جانے والے Eclipse Temurin بیس امیجز میں ابھی تک متعلقہ فکس شامل نہیں ہوا تھا۔ نئے امیجز کو شپ کرکے Teku ٹیم نے یقینی بنایا کہ نئے ٹیگز کو پول کرنے والے آپریٹرز کو ایک Java رن ٹائم ملے جس کا ٹرس اسٹور متاثرہ مواد کو شامل نہیں کرتا۔ ریلیز کے ساتھ جاری کردہ مشورہ میں زور دیا گیا ہے کہ اگر کوئی ڈیفالٹ مین نیٹ نوڈ HTTPS URLز کو کنفگر نہیں کرتا تو اس کے لیے کوئی اقدام درکار نہیں۔ ایکسپوژر صرف ان کنفگریشنز تک محدود ہے جو بیکن کوآرڈینیشن، باہری سائننگ، بِلڈرز، یا مشابہ سروسز کے لیے جان بوجھ کر ریموٹ HTTPS اینڈ پوائنٹس سے جڑتے ہیں۔
قدیمی ڈاکر ایمیجز چلانے والے آپریٹرز، جن میں 26.10.2 تک کے ٹیگز شامل ہیں، اب بھی ایک رن ٹائم استعمال کر رہے ہیں جو متاثرہ رُوٹس پر اعتماد کرتا ہے۔ موجودہ کنٹینر کے اندر کا رن ٹائم خود بخود اپڈیٹ نہیں ہوتا جب آپ ہوسٹ جاوا انستالیشن اپڈیٹ کرتے ہیں، اس لیے آپ کو نیا ایمیج پل کرنا ہوگا۔ ٹیکو نے مزید بتایا کہ جاوا 26 کا خاتمہ ہو چکا ہے اور اس کے لیے کوئی پچ شدہ بِلڈ دستیاب نہیں ہوگا؛ اب بھی اس ورژن پر کام کرنے والے آپریٹرز کو موجودہ لمبے مدتی سپورٹ رلیز، جاوا 25، پر منتقل ہونے اور متعلقہ -jdk25 ایمیج ٹیگز استعمال کرنے کی تجویز کی جاتی ہے۔ اس لیے رلیز میں سرٹیفکیٹ رُوٹ کو ختم کرنے کے ساتھ ساتھ رن ٹائم ورژن مینجمنٹ پر ہدایات بھی شامل ہیں۔ چونکہ یہ تبدیلی صرف ڈاکر ایمیجز کے ٹرسٹ اسٹور تک محدود ہے، اس لیے کنسنسس کا رویہ اور ویلیدیٹر کلید کا انتظام وہی رہتا ہے۔ اس اپڈیٹ کو ایک تجویز کردہ سکیورٹی اقدام کے طور پر پیش کیا گیا ہے، نہ کہ ایک فوری کنسنسس اپگریڈ، جو متاثرہ کنفگریشنز کے تنگ دائرے کو ظاہر کرتا ہے۔
Besu 26.10.2 پیرلل سرٹیفیکیٹ ٹرس ایڈجسٹمنٹس لاگو کرتا ہے
بیسو، جو ایکو سسٹم کے ایک ہی وسیع گروپ کے ذریعے برقرار رکھا جاتا ہے، نے 26 اکتوبر، 2026 کو ورژن 26.10.2 جاری کیا، جس میں اپنے ڈاکر امیجز میں وہی روت ریموولز لاگو کیے گئے۔ متوازی وقت اور مطابقت پذیر سرٹیفکیٹ ہدف کا مطلب ہے کہ جاوا پر مبنی ethereum کلائنٹ اسٹیک کے درمیان eMudhra واقعہ کے بارے میں متناسق علم تھا۔ ایکزیکشن کلائنٹس کنسنسس کلائنٹس اور باہری سروسز کے ساتھ پیلوزڈ کنسٹرکشن اور ٹرانزیکشن شامل کرنے کے لیے تعامل کرتے ہیں؛ ان کے ذریعہ برقرار رکھے گئے کوئی بھی HTTPS مواصلات کے راستے وہی سرٹیفکیٹ ویریفکیشن قواعد پر عمل کرتے ہیں جو ٹیکو کو متاثر کرتے ہیں۔ اپنے امیجز سے متاثرہ اتھارٹیز کے لیے ٹرس کو ختم کرکے، بیسو اس کے ڈاکر توزیعات پر انحصار کرنے والے آپریٹرز کے لیے متعلقہ حمل کا سطح بند کردیتا ہے۔
ٹیکو کی طرح، بیسو اپڈیٹ خودکار طور پر الگ طور پر منیج کیے جانے والے جاوا رن ٹائم کا استعمال کرنے والے مستقل بائنری انسٹالیشنز کو درست نہیں کرتا۔ اس زمرے کے آپریٹرز کو اپنے لوکل ٹرس اسٹورز یا جاوا ورژن کو الگ سے چیک اور اپڈیٹ کرنا ہوگا۔ دونوں کلائنٹس کی جوڑی جاری کرنے سے یہ ظاہر ہوتا ہے کہ ایتھریم نوڈ سافٹ ویئر اسٹیک کے کنسنس اور ایکزیکشن دونوں پہلوؤں نے جاوا سرٹیفیکیٹ ہینڈلنگ پر مشترکہ انحصار کو تسلیم کیا ہے۔ کیونکہ بہت سے پروڈکشن والیڈیٹرز ایک کنسنس کلائنٹ جیسے ٹیکو اور ایک ایکزیکشن کلائنٹ جیسے بیسو دونوں چلا رہے ہوتے ہیں، اس لیے ایک ساتھ اپڈیٹس سے نوڈ جوڑے کے دونوں طرف متاثرہ رُوٹس پر باقی رہنے والے ٹرس کے امکانات کم ہوتے ہیں۔ جاری ہونے سے پہلے کسی بھی استعمال کا رپورٹ نہ ہونا یہ ظاہر کرتا ہے کہ عملی ونڈو محدود تھا، تاہم مسلسل پچس نے ایتھریم پروٹوکول کے باہر ایک معلوم کرپٹوگرافک خرابی کے خلاف موزوں سختی کو ظاہر کیا ہے۔
جاوا کی ڈیفالٹ عدم تجدید چیکنگ کی وجہ سے مدت طویل رہی
ایک مرکزی تکنیکی تفصیل یہ ہے کہ جاوا سرٹیفیکیٹ تصدیق ڈیفالٹ طور پر منسوخی کی حالت کی جانچ نہیں کرتی۔ یہاں تک کہ جب eMudhra نے درمیانی سرٹیفیکیٹس منسوخ کر دیے اور بڑے پلیٹ فارمز نے انہیں بلاک کر دیا، تو جاوا رن ٹائم جس میں اب بھی متعلقہ روٹس یا درمیانی سرٹیفیکیٹس اپنے ٹرسٹ اسٹور میں موجود تھے، وہ ان اداروں کے ساتھ چین بنانے والے سرٹیفیکیٹس کو قبول کرتا رہا۔ OpenJDK نے اصلاحات جاری کیں جن میں پہلے متاثرہ درمیانی سرٹیفیکیٹس بلاک کیے گئے اور بعد میں چار متعلقہ روٹس کو ختم کر دیا گیا۔ تاہم، پرانے Temurin یا OpenJDK بِلڈز والے ڈاکر امیجز میں یہ اصلاحات خودبخود نہیں ملیں۔ پلیٹ فارم لیول منسوخی ار embedded جاوا رن ٹائمز کے رویے کے درمیان یہ فرق ہی وہ وجہ ہے جس نے کلائنٹ خاص امیجز کو اپڈیٹ کرنے کی ضرورت پیدا کردی۔
ایتھریم آپریٹرز کے لیے، اس کا اثر عملی ہے، نہ کہ نظریہ۔ ایک ویلیدیٹر جس کی ترتیب میں دور دراز خدمات کے لیے HTTPS اینڈ پوائنٹس شامل ہیں، وہ اپنے استعمال کیے جانے والے جاوا رن ٹائم کے اعتماد کے فیصلوں کو ورثہ میں پاتا ہے۔ اگر وہ رن ٹائم اپ ڈیٹ نہیں کیا گیا ہے یا پچ شدہ تصویر سے تبدیل نہیں کیا گیا، تو کلائنٹ اب بھی جعلی سرٹیفکیٹ کو قبول کرنے کو تیار رہتا ہے۔ میچل ٹی ایل ایس یا پنڈ کردہ سرٹیفکیٹس اچھی طرح سے ڈیزائن کردہ سیٹ اپس میں خطرے کو کم کر سکتے ہیں، لیکن بہت سے پروڈکشن ترتیبات معیاری ٹرس اسٹور تصدیق پر انحصار کرتے ہیں۔ اس لیے ٹیکو اور بیسو رلیزز اس بات کا عملی تذکرہ فراہم کرتے ہیں کہ کنٹینرائزڈ نوڈ سافٹ ویئر اپنے الگ سرٹیفکیٹ اسٹور رکھتا ہے جو ہوسٹ سسٹم سے مستقل ہوتا ہے۔ جو آپریٹرز ڈاکر تصویروں کو انجان بکس کے طور پر سمجھتے ہیں، وہ اس تفصیل کو تب تک نظر انداز کر سکتے ہیں جب تک کہ کوئی بیرونی واقعہ اپ ڈیٹ کرنے پر مجبور نہ کر دے۔ یہ واقعہ اس بات کا بھی اہم پہلو ظاہر کرتا ہے کہ جاوا بنیادی ایتھریم کلائنٹس چلانے پر اوپر سٹریم جاوا سکورٹی مشوروں پر نظر رکھنا کتنا قدرتی ہے۔
ڈیفالٹ مین نیٹ کنفیگریشنز نے پرائمری اٹیک سرفیس سے بچاء کیا
ٹیکو کی مشورت واضح طور پر یہ کہتی ہے کہ ایک ڈیفالٹ مین نیٹ نوڈ جس کے کنفیگریشن میں کوئی HTTPS URL نہیں ہے، اسے متاثر نہیں ہوا ہے اور اس کے لیے کوئی اقدام درکار نہیں۔ زیادہ تر والیڈیٹرز جو مقامی طور پر کنسینسس اور ایگزیکشن کلائنٹس چلاتے ہیں، بغیر ریموٹ سائننگ یا ریموٹ بیکن اینڈ پوائنٹس کے، اس شرط میں آتے ہیں۔ Ethereum کے ذریعہ استعمال کیے جانے والے پیر-ٹو-پیر دریافت اور گوسپ پروٹوکولز eMudhra سرٹیفیکیٹ اتھارٹیز پر انحصار نہیں کرتے، جس سے معیاری سیٹ اپز مزید محفوظ رہتے ہیں۔ خطرہ صرف ان آپریٹرز پر مرکوز ہے جنہوں نے عملی آسانی، سائننگ کلیدز کے جغرافیائی تقسیم، یا تھرڈ پارٹی بلاک بِلڈنگ سروسز کے ساتھ اندراج کے لیے عمدہ طور پر باہری HTTPS منابع شامل کیے ہیں۔ پورے نیٹ ورک کے اثر کا جائزہ لینے کے لیے یہ تمایز اہم ہے۔ کیونکہ مین نیٹ والیڈیٹرز کا زیادہ تر حصہ اس قسم کے کنفیگریشنز کے تحت کام کرتا ہے جو کبھی متاثرہ سرٹیفکیٹ چینز سے رابطہ نہیں کرتے تھے، اس لیے تھیورٹیکل حملے کا رقبہ پچھلے اپڈیٹس سے پہلے بھی محدود رہا۔
گاہک ٹیموں کا فیصلہ کہ اپڈیٹ شدہ تصاویر کو شپ کیا جائے، ان آپریٹرز کے ایک ذیلی مجموعے کے لیے تحفظ فراہم کرتا ہے جو ریموٹ سروسز استعمال کرتے ہیں اور یقینی بناتا ہے کہ مستقبل کی تصاویر کو مین نیٹ سے مضبوط بنیاد سے شروع کیا جائے۔ جو ٹیسٹ نیٹ کنفیگریشنز HTTPS کے ذریعے ابتدائی حالت ڈاؤن لوڈ کرتی ہیں، انہیں ممکنہ طور پر خطرے میں بتایا گیا، جس سے ثابت ہوتا ہے کہ وہی سرٹیفکیٹ منطق مین نیٹ کے باہر بھی لاگو ہوتا ہے۔ کسی بھی نیٹ ورک کے آپریٹرز جو HTTPS بُوت strap یا ریموٹ اینڈ پوائنٹس پر انحصار کرتے ہیں، انہیں اکتوبر 2026 کے اجرا کو اپنے ماحول کے لیے ضروری سمجھنا چاہیے۔ ڈیفالٹ اور غیر ڈیفالٹ کنفیگریشنز کے درمیان واضح تقسیم نے مشورے کو ویلیدیٹر سیٹ کے بڑے حصے کے لیے درست اور آرام دہ بنایا۔
بیرونی دستخط کنندگان اور دور کے بیکن نوڈس سب سے زیادہ خطرناک راستوں کی نمائندگی کرتے ہیں
ٹیکو نے جن سیناریوز کا ذکر کیا، ان میں باہری دستخط سروسز کی شدت زیادہ تھی۔ یہ سروسز ویلیڈیٹر کے پرائیویٹ کلیدز کو آف لائن یا خصوصی ہارڈویئر میں رکھتی ہیں اور نیٹ ورک کنکشن کے ذریعے دستخط کے درخواستوں کا جواب دیتی ہیں۔ اگر حملہ آور جعلی سرٹیفکیٹ پیش کرکے دستخط کرنے والے کا دعویٰ کر سکے، تو ویلیڈیٹر کلائنٹ وہ دستخط قبول کر سکتا ہے جو آپریٹر نے کبھی منظور نہیں کیے، جن میں فی ریسیپینٹ سیٹنگز تبدیل کرنا یا ایگزٹ شروع کرنا بھی شامل ہے۔ متبادل TLS توثیق کو لاگو کرنے والے ترتیبات کا اثر صرف سروس انکار تک محدود ہوتا ہے، کیونکہ حملہ آور توثیق شدہ ہینڈشیک مکمل نہیں کر سکتا۔ جہاں متبادل توثیق موجود نہ ہو، قابل استعمال دستخط حاصل کرنے کا خطرہ زیادہ ہوتا ہے۔ ریموٹ بیکن نوڈس متعلقہ لیکن الگ خدشہ پیدا کرتے ہیں۔
ایک ویلیڈیٹر جو کچھ تنظیم کے فرائض کو ایک دور کے بیکن اینڈ پوائنٹ کو سونپ دیتا ہے، اس اینڈ پوائنٹ پر اپنے فرائض، بلاک کے مواد، اور نیٹ ورک کی حالت کے بارے میں معلومات کے لیے انحصار کرتا ہے۔ اس لیے، ایک کامیاب دھوکہ دہی سے ویلیڈیٹر کے ذریعہ تجویز کیے جانے والے بلاک، بشمول اس بلاک میں ڈالے گئے فی ریسیپینٹ ایڈریس، پر اثر ڈال سکتی ہے۔ بلاک بِلڈرز اور ریلےز مزید HTTPS سطحیں متعارف کراتے ہیں جن کے ذریعہ مانیپولیٹڈ پیلودز داخل کیے جا سکتے ہیں۔ ہر صورت میں، حملہ آور کو پہلے ایک نیٹ ورک پوزیشن حاصل کرنی ہوگی جو انٹرسیپشن کو ممکن بنائے، اور پھر ایک ایسا سرٹیفکیٹ پیش کرنا ہوگا جسے اپڈیٹ نہ ہونے والے جاوا رن ٹائم قبول کرے۔ ضروریات کا یہ ترکیب ناممکن حرفاں کے مجموعے کو تنگ کرتا ہے، تاہم ممکنہ فائدہ، جو ایک کامیاب تجویز سے منسلک فیز کا رجوع ہے، دفاعی اپڈیٹس کو justified کرتا ہے۔ جو آپریٹرز باہری سائنرز یا دور کے انفراسٹرکچر کو برقرار رکھتے ہیں، انہیں صارفین کے اپڈیٹس اور ان لنکس پر توثیق کے طریقوں کا جائزہ لینا دونوں کو ترجیح دینا چاہئے۔
الگ الگ جاوا اپڈیٹ کے فرائض پر مشتمل ہوتے ہیں
ڈاکر صارفین نئے Teku 26.10.3 یا Besu 26.10.2 ایمیجز کو پل کر درستگی کر سکتے ہیں۔ جو آپریٹرز کلائنٹس کو الگ الگ بائنریز یا پیکجز کے طور پر انسٹال کرتے ہیں، وہ ہوسٹ سسٹم پر موجود جاوا رن ٹائم پر منحصر ہیں۔ ان انسٹالیشنز کے لیے، کلائنٹ ریلیزز خود ہوسٹ ٹرسٹ اسٹور کو تبدیل نہیں کرتے۔ اس لیے آپریٹرز کو یہ تصدیق کرنا ہوگا کہ ان کی انسٹالڈ جاوا ورژن میں OpenJDK کے وہ فکس شامل ہیں جو متاثرہ رُوٹس کو ختم کرتے ہیں، یا وہ سرٹیفکیٹ اسٹور کو مینوئل طور پر ایڈجسٹ کریں۔ Teku نے خاص طور پر جاوا 26 کو ختم ہونے والا قرار دیا ہے اور اس میں پچڈ بِلڈ نہیں ملے گا؛ مسلسل سپورٹ اور سیکورٹی اپڈیٹس کے لیے جاوا 25 پر منتقل ہونا ضروری ہے۔ ایتھریم انفراسٹرکچر میں کنٹینرائزڈ اور بیر-میٹل ڈپلوائمنٹس کے درمیان یہ تقسیم عام ہے اور نوڈ آپریٹرز کے لیے ایک عملی چیک لسٹ آئٹم بناتی ہے۔
جاوا کے ورژنز کی فہرست، ٹرسٹ-اسٹور کے مواد کی تصدیق، اور اس بات کی تصدیق کہ کوئی بھی HTTPS اینڈ پوائنٹس غیر قابلِ اعتماد سروسز کی طرف اشارہ نہ کر رہے ہوں، پچ کے بعد کی حداقل صفائی کا حصہ ہیں۔ چونکہ بنیادی کرپٹوگرافک خرابی ethereum کے باہر واقع ہوئی تھی، اس لیے کسی بھی دوسرے جاوا مبنی ٹولنگ کے لیے جو آپریٹر چلا سکتا ہے، وہی جاوا اپڈیٹ کے فرائض لاگو ہوتے ہیں۔ اس لیے کلائنٹ کے مشورے ٹیکو اور بیسو کے لیے مخصوص حل کے ساتھ ساتھ آپریٹر کے پورے سٹیک میں سرٹیفکیٹ ہینڈلنگ کے جائزے کا بھی ایک وسیع تر محرک ہیں۔ ہوسٹ جاوا ماحول کو درست نہ کرنے سے نظریاتی حملوں کے راستے کھلے رہتے ہیں، حتیٰ کہ جب کلائنٹ سافٹ ویئر خود اپڈیٹ ہو جائے۔
پیچز لگنے سے پہلے کوئی تصدیق شدہ استعمال نہیں ہوا
ٹیکو کی مشورت اور اسی دوران کی رپورٹنگ دونوں یہ بات کہتی ہیں کہ کسی بھی خرابی کا استعمال نہیں دیکھا گیا۔ معلوم واقعات کی عدم موجودگی اس بات کے مطابق ہے کہ کامیاب حملے کے لیے درکار شرائط بہت محدود ہیں: ایک اپڈیٹ نہ ہونے والا جاوا رن ٹائم، کسی باہری سروس سے HTTPS کنکشن، اور ایک حملہ آور جو اس خاص کنکشن کو انٹر سیپٹ کر سکے اور جھوٹا سرٹیفکیٹ پیش کر سکے۔ زیادہ تر والیڈیٹرز نے کبھی بھی پہلی دو شرائط کو ایک ساتھ پورا نہیں کیا۔ 17 اکتوبر کو قابل واپسی والے کلیدوں کے علنا اعلان اور کلائنٹ امیج جاری کرنے کے درمیان مختصر وقفہ نے عملی ونڈو مزید تنگ کر دیا۔
مشاہدہ شدہ حملوں کی کمی پچوں کی قیمت کو کم نہیں کرتی۔ سرٹیفکیٹ سے متعلق کمزوریاں ایک موقع پر مبنی دشمن کے ظہور تک خاموش رہ سکتی ہیں۔ ڈاکر ٹرسٹ اسٹورز سے متاثرہ روٹس کو ختم کرکے، کلائنٹ ٹیمز نے اپڈیٹ کرنے والے آپریٹرز کے لیے جعلی سرٹیفکیٹس کو قبول کرنے کو ختم کر دیا۔ اس واقعہ نے باہری کرپٹوگرافک خرابیوں کے Ethereum اسٹیکنگ انفراسٹرکچر سے کس طرح تقاطع ہونے کا ایک لائیو ڈیمو بھی فراہم کیا، جس نے آپریٹرز کو اپنے خود کے انحصار گرافس کا جائزہ لینے پر مجبور کر دیا۔ مستقبل میں سرٹیفکیٹ اتھارٹیز یا زبان رن ٹائمز سے متعلق واقعات کا مقابلہ اسی طرح کلائنٹ لیول پر جوابات کے ساتھ کیا جائے گا، جو تیز اور ہدف مند حل کے نمونے کو مضبوط بنائے گا۔
کیسے سرٹیفیکیٹ سیکیورٹی کے خطرات بلاک چین نیٹ ورکس تک پھیلتے ہیں
ایم ڈرہا واقعہ صرف ایتھریم تک محدود نہیں ہے؛ کوئی بھی سافٹ ویئر جو معیاری TLS ٹرس اسٹورز پر انحصار کرتا ہے، اس کی مصدقہ اداروں کے ساتھ اپنی سیکیورٹی پوزیشن ورثہ میں حاصل کرتا ہے۔ جاوا، گو، یا دیگر زبانوں کے رن ٹائمز کو اپنے اندر شامل کرنے والے بلاک چین کلائنٹس کو اپنے متفقہ تبدیلیوں کی طرح ہی اپسٹریم سرٹیفکیٹ اپڈیٹس کا خیال رکھنا چاہیے۔ اس حقیقت نے کہ جاوا کی ڈیفالٹ ترتیب میں منسوخ کردہ چیکنگ کو نظرانداز کر دیا جاتا ہے، اس نے اثرات کو بڑھا دیا اور کلائنٹ ٹیمز کو اپنے اپنے ٹرس اسٹور تبدیلیوں کو شپ کرنے پر مجبور کر دیا۔ دوسرے ایکو سسٹم جو لمبے عرصے تک چلنے والے رن ٹائمز کو کنٹینرز میں شامل کرتے ہیں، ان کو بھی مشابہ خطرات کا سامنا ہے۔
ایتھریم اسٹیکنگ کے اجتماع کے لیے عملی سبق یہ ہے کہ آپریشنل سیکیورٹی صرف کلید کے انتظام اور کلائنٹ ورژننگ تک محدود نہیں ہے، بلکہ ہر نیٹ ورکڈ کمپوننٹ کے سرٹیفیکیٹ والیڈیشن کے رویے تک پھیلی ہوئی ہے۔ جو آپریٹرز ریموٹ سائننگ، ڈسٹریبیوٹڈ بیکن نوڈس، یا تھرڈ پارٹی ریلےز استعمال کرتے ہیں، وہ اضافی ٹرس باؤنڈریز متعارف کراتے ہیں جن کی نگرانی ضروری ہے۔ CA کی منسوخی، پلیٹ فارم بلاکس، اور کلائنٹ امیج اپڈیٹس کے ذریعے اس خاص خامی کا کامیابانہ تعامل دکھاتا ہے کہ جب ہر لیر جلدی سے جواب دے تو لیرڈ دفاع کام کر سکتے ہیں۔ مسلسل کلائنٹ کی تنوع کا اہمیت برقرار رہتی ہے کیونکہ مختلف امپلیمنٹیشنز مختلف رفتار سے باہری منحصرات کو ظاہر یا کم کر سکتی ہیں، جس سے ایک واحد سرٹیفیکیٹ کے ناکام ہونے سے پورے ویلیدیٹر سیٹ کو ایک ساتھ متاثر ہونے کا امکان کم ہو جاتا ہے۔
validator انفرااسٹرکچر میں حالیہ متوازی فکریں مسلسل احتیاط کی ضرورت کو ظاہر کرتی ہیں
اکتوبر 2026 کا سرٹیفکیٹ پیچ دوسرے ویلیڈیٹر سے متعلق سیکورٹی کی توجہ کے پس منظر میں آیا۔ پہلے کی گئی اطلاعات جن میں اسٹیکنگ سروس انفراسٹرکچر اور فی-ریسیپینٹ ہینڈلنگ شامل تھی، نے بڑے پیمانے پر добخواہ نکلنے اور انعام کے رخ کی نگرانی میں اضافہ کر دیا تھا۔ الگ طور پر، ڈویلپرز نے آنے والے Glamsterdam اپگریڈ کے لیے منصوبہ بند قواعد میں ایک ڈپازٹ راؤٹنگ مسئلہ حل کیا جو کچھ پبلک-کی کالیژن کے تحت اسٹیکنگ ڈپازٹس کو غلط طور پر مختص کر سکتا تھا؛ اس فکس کو مزید جائزہ کے بعد کنسینسس سپیسیفکیشنز میں ضم کر دیا گیا۔ یہ متعدد واقعات یہ ظاہر کرتے ہیں کہ ویلیڈیٹر معاشیات اور آپریشنل سیکورٹی اب بھی اہم توجہ کا مرکز ہیں، جبکہ مرکزی پروٹوکول ترقی جاری رکھتا ہے۔
سرٹیفکیٹ کی خامی کا ماخذ مختلف تھا؛ یہ ایک باہری CA سے نکلی، ایتھریم سپیفیکیشن یا کلائنٹ کنسینسس بگ سے نہیں، لیکن یہی اقتصادی سطح کو چھوا: پریپوزرز کے ذریعہ کمائے گئے فیس اور انعامات کا مقصد۔ اس لیے کلائنٹ کا تیز ردعمل کسی بھی حقیقی راستے کو انعام کے منبع کو بدلنے کے طور پر اولین ترجیح سمجھنے کے ایک وسیع نمونے کے مطابق ہے۔ جو آپریٹرز مختلف کلائنٹ سیٹ اپس برقرار رکھتے ہیں، آن چین فی-ریسیپینٹ ایڈریسز کو مانیٹر کرتے ہیں، اور دونوں کنسینسس اور ایکزیکشن سافٹ ویئر کو تازہ رکھتے ہیں، وہ ایسے باہری شاکس کو برداشت کرنے کے لیے بہتر طور پر تیار ہوتے ہیں۔ eMudhra کے معاملے میں نقصانات کا عدم وجود یہ تصدیق کرتا ہے کہ وقت پر پچنگ اور ترتیب کی پابندی اب بھی مؤثر دفاع ہیں۔
اکتوبر کے اجرا کے بعد ایتھریم نوڈ آپریٹرز کو کیا کرنا ہے
والیڈیٹرز اور نوڈ آپریٹرز کو یقینی بنانا چاہیے کہ وہ ڈاکر کا استعمال کرتے ہوئے Teku 26.10.3 یا اس سے زیادہ اور Besu 26.10.2 یا اس سے زیادہ چلا رہے ہیں، یا بائنریز کا استعمال کرتے ہوئے متعلقہ پچ کردہ جاوا رن ٹائم۔ HTTPS اینڈ پوائنٹس کے لیے کنفیگریشنز کا جائزہ لیا جانا چاہیے؛ جہاں ایسے اینڈ پوائنٹس ضروری ہوں، میچل TLS یا سرٹیفکیٹ پننگ اضافی تحفظ فراہم کرتے ہیں۔ ابھی تک جاوا 26 پر موجود آپریٹرز کو ایک سپورٹڈ ریلیز پر منتقل ہونا چاہیے۔ ٹرسٹ اسٹور اپڈیٹس کے بعد بھی، غیر متوقع فی ریسیپینٹ ایڈریسز کے لیے پرپوزڈ بلاکس کی نگرانی ایک کم لاگت والی تشخیص کا طریقہ بنی رہتی ہے۔ چونکہ بنیادی کلیدز کو دریافت سے پہلے لمبے عرصے تک بحال کیا جا سکتا تھا، اس لیے تاریخی کنکشنز اور سرٹیفکیٹ قبول کرنے والے لاگس کا ایک بار کا جائزہ لینا اضافی یقین دلاتا ہے، حالانکہ کوئی استعمال کرنے کا رپورٹ نہیں ہوا ہے۔
یہ اقدامات زیادہ تر آپریٹرز کے لیے تبدیلی کے بجائے تدریجی ہیں۔ مین نیٹ ویلیڈیٹرز کا اکثریتی حصہ متاثرہ سرٹیفکیٹ چینز سے کبھی رابطہ نہیں کیا، اس لیے وہ اس واقعے کو صرف اس بات کی یاد دہانی کے طور پر محسوس کرتے ہیں کہ کنٹینر امیجز اور جاوا رن ٹائمز کو تازہ رکھا جائے۔ جو لوگ باہری سروسز پر انحصار کرتے ہیں، ان کے لیے پیچز ایک خاص اور پہلے کم سراہی گئی راہ بند کرتے ہیں۔ اپسٹریم سرٹیفکیٹ اور رن ٹائم ایڈوائزرز کے بارے میں آگاہی برقرار رکھنا مستقبل میں مشابہ باہری خرابیوں کے نتیجے میں مشابہ خامیوں کے قائم ہونے کا احتمال کم کرے گا۔ ٹیکو اور بیسو ٹیموں کا منسوب عمل فوری حل فراہم کرتا ہے اور اگلے باہری کرپٹوگرافک واقعے کو ہینڈل کرنے کا ایک ماڈل فراہم کرتا ہے جو ethereum کلائنٹ سافٹ ویئر سے ملتا جلتا ہے۔
اکثر پوچھے جانے والے سوالات
eMudhra سرٹیفکیٹس کے ساتھ بالکل کیا مسئلہ تھا؟
2025 کی کلید سینیچر کے دوران eMudhra کے ذریعہ چلائے جانے والے آٹھ درمیانی سرٹیفیکیٹ اتھارٹیز کی نجی کلیدیں کافی رینڈومنس کے بغیر تیار کی گئیں۔ یہ کلیدیں عوامی سرٹیفکیٹس سے حاصل کی جا سکتی تھیں، جس سے کوئی بھی جو انہیں حاصل کر لے، جھوٹے سرٹیفکیٹس جاری کر سکتا تھا جنہیں سافٹ ویئر اب بھی ان اتھارٹیز کو قبول کرنے کے لیے قابلِ اعتماد سمجھتا تھا۔ درمیانی میں سے چھ TLS کے لیے اور دو کوڈ سائننگ کے لیے استعمال ہوئے۔ eMudhra نے 17 اکتوبر، 2026 کو اس کا پتہ چلنے کے بعد انہیں منسوخ کر دیا، اور بعد میں بڑے پلیٹ فارمز نے متعلقہ مواد کو بلاک کر دیا۔
کیا اس خامی کی وجہ سے کسی بھی ویلیڈیٹر کو ایتھ ریوارڈز کا نقصان ہوا؟
کوئی تصدیق شدہ استعمال یا انعامات کا نقصان رپورٹ نہیں کیا گیا ہے۔ کلائنٹ مشورے اور اسی دوران کی رپورٹس میں یہ بات کہی گئی ہے کہ کوئی حملہ نہیں دیکھا گیا۔ درکار شرائط کا مجموعہ، ایک اپڈیٹ نہ ہونے والا جاوا رن ٹائم اور ایک زخمی باہری سروس سے فعال HTTPS کنکشن، عملی حملے کے سطح کو محدود کرتا ہے، اور پچ کردہ ڈاکر تصویروں کی تیزی سے جاری کردی گئی جس سے خطرہ مزید کم ہو گیا۔
کیا ڈیفالٹ ethereum مین نیٹ نوڈس متاثر ہیں؟
وہ ڈیفالٹ مین نیٹ Teku کنفیگریشنز جن میں کوئی HTTPS URL نہیں ہے، متاثر نہیں ہوتے اور ان کے لیے کوئی اقدام درکار نہیں۔ اسی اصول کو مشابہ Besu سیٹ اپس پر بھی لاگو کیا جاتا ہے۔ خطرہ صرف ان آپریٹرز تک محدود ہے جو بیکن نوڈز، باہری سائنرز، بیلڈرز یا مشابہ سروسز کے لیے ریموٹ HTTPS اینڈ پوائنٹس کو جان بوجھ کر کنفیگر کرتے ہیں۔
کیوں جاوا رنٹائمز کو سرٹیفکیٹس کے منسوخ ہونے کے بعد بھی زخمی رہا گیا؟
جیوا ڈیفالٹ طور پر سرٹیفیکیٹ ریوکیشن کی حالت کی جانچ نہیں کرتا۔ یہاں تک کہ جب انٹرمیڈیٹس کو براؤزرز اور آپریٹنگ سسٹمز نے ریوک کر دیا اور بلاک کر دیا، تو جس جیوا انسٹالیشن میں اب بھی اپنے ٹرسٹ اسٹور میں متعلقہ روٹس موجود تھے، وہ ان کے ساتھ چیننگ والے سرٹیفیکیٹس کو قبول کرتا رہا۔ اس لیے، جن کلائنٹ ڈاکر امیجز میں پرانے رن ٹائمز شامل تھے، انہیں واضح طور پر روٹس کو ختم کرنے کی ضرورت تھی۔
ڈاکر ایمیجز استعمال کرنے والے آپریٹرز کو کیا کرنا چاہیے؟
Teku ورژن 26.10.3 یا اس سے زیادہ اور Besu ورژن 26.10.2 یا اس سے زیادہ ڈاؤن لوڈ کریں اور چلائیں۔ یہ تصاویر مُجھے ہوئی جڑوں پر بھروسہ نہیں کرتیں۔ صرف ہوسٹ سسٹم کو اپ ڈیٹ کرنے سے موجودہ کنٹینر کے اندر رن ٹائم اپ ڈیٹ نہیں ہوتا؛ نئی تصویر درکار ہے۔
کلائنٹس کو الگ الگ بائنری کے طور پر چلانے والے آپریٹرز کے بارے میں کیا؟
ان آپریٹرز کو میزبان Java انسٹالیشن کو اپڈیٹ یا دوبارہ کنفیگر کرنا ہوگا تاکہ اس میں OpenJDK کے فکس شامل ہو جائیں اور متاثرہ جڑیں ختم ہو جائیں۔ Java 26 کا خاتمہ ہو چکا ہے اور اسے پچ کیا گیا ورژن نہیں ملے گا؛ Java 25 پر منتقل ہونے کی تجویز کی جاتی ہے۔ کلائنٹ سافٹ ویئر کے اپڈیٹس خود میزبان ٹرسٹ اسٹور کو تبدیل نہیں کرتے۔
عذر: یہ عام مارکیٹ معلومات، جو ممکنہ طور پر تیسری پارٹی، کمرشل یا سپانسرڈ ذرائع سے ہیں، صرف حوالہ اور تعلیمی مقاصد کے لیے فراہم کی گئی ہیں اور یہ مالیاتی یا سرمایہ کاری کی مشورت، پیشکش، دعوت یا ضمانت نہیں ہیں۔ ہم اس کی درستگی، مکملیت، قابلِ اعتمادی اور نتیجے میں ہونے والے کسی بھی نقصان کے لیے ذمہ داری قبول نہیں کرتے۔ سرمایہ کاری/ٹریڈنگ خطرناک ہے؛ ماضی کا اداء مستقبل کے نتائج کی ضمانت نہیں دیتا۔ صارفین کو تحقیق کرنی چاہیے، احتیاط سے فیصلہ کرنا چاہیے اور مکمل ذمہ داری لینی چاہیے۔ مزید تفصیلات کے لیے، براہ کرم KuCoin کے استعمال کی شرائط اور خرابی کا اعلان دیکھیں۔
ڈس کلیمر: یہ صفحہ آپ کی سہولت کے لیے AI ٹیکنالوجی کا استعمال کرتے ہوئے ترجمہ کیا گیا ہے۔ سب سے درست معلومات کے لیے، اصل انگلش ورژن سے رجوع کریں۔