سنجیدہ سیکورٹی: GnuTLS OpenSSL کی پیروی کرتا ہے، ٹائمنگ اٹیک بگ کو ٹھیک کرتا ہے۔

گزشتہ ہفتے، ہم نے ایک گروپ کے بارے میں لکھا میموری مینجمنٹ کیڑے جو مقبول OpenSSL انکرپشن لائبریری کی تازہ ترین سیکورٹی اپ ڈیٹ میں طے کی گئی تھیں۔

ان میموری کیڑے کے ساتھ، ہم نے ڈب کیے گئے بگ کی بھی اطلاع دی۔ CVE-2022-4304: RSA ڈکرپشن میں ٹائمنگ اوریکل.

اس بگ میں، ایک ہی انکرپٹڈ میسج کو سرور پر بار بار فائر کرنا، لیکن ڈیٹا کو غلط بنانے کے لیے ڈیٹا کے آخر میں پیڈنگ میں ترمیم کرنا، اور اس طرح کسی قسم کے غیر متوقع رویے کو بھڑکانا…

…یہ فرض کرتے ہوئے کہ آپ نیٹ ورک پر ہدف کے قریب ہیں، اس میں مسلسل وقت نہیں لگے گا کہ آپ قابل اعتماد انداز میں اندازہ لگا سکتے ہیں کہ ڈیٹا کی منتقلی کے عمل کے حصے میں کتنا وقت لگے گا۔

تمام ڈیٹا پر یکساں کارروائی نہیں کی جاتی ہے۔

اگر آپ کسی درخواست کو برطرف کرتے ہیں، جواب میں کتنا وقت لگتا ہے، اور نیٹ ورک ڈیٹا کی نچلی سطح پر بھیجنے اور وصول کرنے میں خرچ ہونے والے وقت کو کم کرتے ہیں، تو آپ کو معلوم ہوگا کہ سرور کو درخواست پر کارروائی کرنے میں کتنا وقت لگا۔ .

یہاں تک کہ اگر آپ اس بات کا یقین نہیں کر رہے ہیں کہ نیٹ ورک میں کتنا وقت استعمال ہوتا ہے، تو آپ بہت ساری درخواستوں کو ختم کرکے اور نمونے جمع کرکے راؤنڈ ٹرپ کے اوقات میں تغیرات تلاش کرسکتے ہیں۔

اگر نیٹ ورک یہ فرض کرنے کے لیے کافی قابل بھروسہ ہے کہ نیٹ ورکنگ اوور ہیڈ زیادہ تر مستقل ہے، تو آپ اعداد و شمار کے طریقے استعمال کر سکتے ہیں تاکہ یہ اندازہ لگایا جا سکے کہ ڈیٹا میں تبدیلی کس قسم کی اضافی پروسیسنگ میں تاخیر کا سبب بنتی ہے۔

اس سے، آپ بہت سے لوگ اصل غیر خفیہ کردہ ڈیٹا کی ساخت، یا یہاں تک کہ مواد کے بارے میں کچھ اندازہ لگا سکتے ہیں جسے ہر بار بار درخواست کے اندر خفیہ رکھا جانا چاہیے۔

یہاں تک کہ اگر آپ سادہ متن کا صرف ایک بائٹ نکال سکتے ہیں، ٹھیک ہے، ایسا نہیں ہونا چاہیے۔

نام نہاد وقت کے حملے اس قسم کے ہمیشہ پریشان کن ہوتے ہیں، یہاں تک کہ اگر آپ کو لاکھوں بوگس پیکٹ بھیجنے کی ضرورت پڑسکتی ہے اور ان سب کو سادہ متن کے صرف ایک بائٹ کی بازیافت کا کوئی موقع مل سکتا ہے…

…کیونکہ نیٹ ورک کچھ سال پہلے کے مقابلے میں زیادہ تیز، زیادہ پیش قیاسی، اور بہت زیادہ بوجھ کو سنبھالنے کے قابل ہیں۔

آپ سوچ سکتے ہیں کہ لاکھوں غدار پیکٹوں نے آپ کو اسپام کیا، کہو، اگلا گھنٹہ انگوٹھے کی طرح کھڑا ہوگا۔

لیکن "ایک ملین پیکٹ ایک گھنٹہ معمول سے زیادہ یا کم" بس اب کوئی خاص بڑی تبدیلی نہیں ہے۔

GnuTLS میں اسی طرح کا "اوریکل" بگ

ٹھیک ہے، وہی شخص جس نے OpenSSL میں طے شدہ بگ ٹائمنگ بگ کی اطلاع دی تھی GnuTLS میں ملتا جلتا بگ تقریبا ایک ہی وقت میں.

اس میں بگ شناخت کنندہ ہے۔ CVE-2023-0361.

اگرچہ GnuTLS اتنا مقبول یا وسیع پیمانے پر استعمال نہیں کیا جاتا ہے جیسا کہ OpenSSL، آپ کے پاس شاید آپ کے IT اسٹیٹ میں، یا یہاں تک کہ آپ کے اپنے کمپیوٹر پر بھی بہت سے پروگرام ہیں، جو اسے استعمال کرتے ہیں یا اسے شامل کرتے ہیں، ممکنہ طور پر FFmpeg، GnuPG، Mplayer، QEMU ، Rdesktop، Samba، Wget اور Wireshark۔

ستم ظریفی یہ ہے کہ GnuTLS میں وقت کی خرابی کوڈ میں ظاہر ہوئی جس کے بارے میں سمجھا جاتا تھا کہ پہلے وقت پر حملے کی غلطیوں کو لاگ ان کرنا تھا۔

جیسا کہ آپ کوڈ کے فرق سے دیکھ سکتے ہیں (مختلف) نیچے، پروگرامر کو معلوم تھا کہ کوئی بھی مشروط (if ... then) ڈکرپشن کی خرابی کو چیک کرنے اور اس سے نمٹنے کے لیے استعمال کیا جانے والا آپریشن ٹائمنگ میں تغیرات پیدا کر سکتا ہے، کیونکہ CPUs عام طور پر اس بات پر منحصر ہوتا ہے کہ آپ کا کوڈ "برانچ" کی ہدایات کے بعد کس طرح جاتا ہے۔

(یہ خاص طور پر اس برانچ کے لیے سچ ہے جو اکثر ایک طرف جاتا ہے اور شاذ و نادر ہی دوسری طرف، کیونکہ CPUs کو یاد رکھنے کا رجحان ہوتا ہے، یا کیش، کوڈ جو کارکردگی کو بہتر بنانے کے لیے بار بار چلتا ہے، اس طرح کبھی کبھار لیا جانے والا کوڈ واضح طور پر آہستہ چلتا ہے۔)

لیکن پروگرامر پھر بھی لاگ ان کرنا چاہتا تھا کہ حملہ ہو سکتا ہے، جو ہوتا ہے اگر if (ok) اوپر کا ٹیسٹ ناکام ہو جاتا ہے اور میں شاخیں else { ... } سیکشن پر ایک اقتصادی کینڈر سکین کر لیں۔

اس مقام پر، کوڈ کال کرتا ہے۔ _gnutls_debug_log() فنکشن، جو اپنا کام کرنے میں کافی وقت لے سکتا ہے۔

لہذا کوڈر نے جان بوجھ کر کال داخل کی۔ _gnutls_no_log() میں then { ... } کوڈ کا وہ حصہ، جو "حملے" کو لاگ کرنے کا بہانہ کرتا ہے جب کوئی نہیں ہوتا ہے، تاکہ کوڈ کے کسی بھی سمت میں خرچ ہونے والے وقت کو بڑھانے کی کوشش کی جا سکے۔ if (ok) برانچ ہدایات لے سکتے ہیں.

بظاہر، تاہم، دونوں کوڈ کے راستے اس وقت میں کافی یکساں نہیں تھے جب وہ استعمال کرتے تھے (یا شاید _gnutls_debug_log() مختلف قسم کی غلطیوں سے نمٹنے کے لیے فنکشن اپنے طور پر ناکافی طور پر مطابقت رکھتا تھا) اور حملہ آور دس لاکھ کوششوں کے بعد ڈکرپشن ٹیلٹیلز میں فرق کرنا شروع کر سکتا ہے۔

کیا کیا جائے؟

اگر آپ پروگرامر ہیں: یہاں بگ ٹھیک کرنا آسان تھا، اور "کم زیادہ ہے" کے اصول پر عمل کیا۔

اوپر گلابی رنگ کا کوڈ، جس کے بارے میں یہ سمجھا جاتا تھا کہ حملے کا پتہ لگانے کا بہت مفید ڈیٹا بہرحال نہیں دیا گیا، صرف اس بنیاد پر حذف کر دیا گیا کہ جو کوڈ موجود نہیں ہے وہ غلطی سے مرتب نہیں کیا جا سکتا، چاہے آپ کی تعمیر کی ترتیبات کچھ بھی ہوں…

…اور جو کوڈ مرتب نہیں کیا گیا ہے وہ کبھی نہیں چل سکتا، چاہے حادثہ ہو یا ڈیزائن۔

اگر آپ GnuTLS صارف ہیں: حال ہی میں جاری کردہ ورژن 3.7.9 اور "نئی مصنوعات کا ذائقہ" 3.8.0 مختلف دیگر کے ساتھ اس کو درست کر لیں۔

اگر آپ لینکس ڈسٹرو چلا رہے ہیں تو، آپ کے پاس موجود GnuTLS کے کسی بھی مرکزی طور پر زیر انتظام مشترکہ لائبریری ورژن کے ساتھ ساتھ ان ایپس کے لیے اپ ڈیٹس کی جانچ پڑتال کریں جو اپنا ورژن ساتھ لاتی ہیں۔

لینکس پر، نام کے ساتھ فائلیں تلاش کریں۔ libgnutls*.so ارد گرد پڑی مشترکہ لائبریریوں کو تلاش کرنے کے لیے، اور تلاش کریں۔ gnutls-cli کمانڈ لائن یوٹیلیٹی کی کوئی بھی کاپی تلاش کرنے کے لیے جو اکثر لائبریری کے ساتھ شامل ہوتی ہے۔

آپ چلا سکتے ہیں۔ gnutls-cli -vv کا کون سا ورژن معلوم کرنے کے لیے libgnutls یہ متحرک طور پر منسلک ہے:

 $gnutls-cli -vv gnutls-cli 3.7.9 <-- میرے لینکس ڈسٹرو کو گزشتہ جمعہ (2023-02-10) کی تازہ کاری ملی۔

---

• SEO سے چلنے والا مواد اور PR کی تقسیم۔ آج ہی بڑھا دیں۔
• پلیٹو بلاک چین۔ Web3 Metaverse Intelligence. علم میں اضافہ۔ یہاں تک رسائی حاصل کریں۔
• ماخذ: https://nakedsecurity.sophos.com/2023/02/13/serious-security-gnutls-follows-openssl-fixes-timing-attack-bug/