گوگل کی تازہ ترین کروم اپ ڈیٹ آ چکی ہے، اور اس بار کمپنی اس کے الفاظ کو نہیں توڑا ہے۔ دو حفاظتی پیچوں میں سے ایک کے بارے میں اس میں شامل ہیں:
گوگل کو معلوم ہے کہ اس کے لیے ایک استحصال CVE-2023-3079 جنگلی میں موجود ہے.
کوئی دو ڈگری کی علیحدگی کا لفظ نہیں ہے، جیسا کہ ہم نے پہلے اکثر گوگل سے دیکھا ہے، یہ کہنا کہ کمپنی کسی استحصال کی "اطلاعات سے آگاہ ہے"۔
اس بار، یہ "ہم خود ہی اس سب سے واقف ہیں"، جس کا اور بھی دو ٹوک ترجمہ "ہم جانتے ہیں کہ بدمعاش اس کا غلط استعمال کر رہے ہیں جیسا کہ ہم بولتے ہیں"، یہ دیکھتے ہوئے کہ بگ رپورٹ براہ راست گوگل کے اپنے تھریٹ ریسرچ گروپ سے آئی ہے۔
ہمیشہ کی طرح، اس کا مطلب یہ ہے کہ گوگل ایک فعال حملے کی تحقیقات کر رہا تھا (چاہے گوگل خود، یا کسی بیرونی تنظیم کے خلاف ہو، ہم نہیں جانتے) جس میں کروم کو پہلے سے نامعلوم سیکیورٹی ہول نے گھیر لیا تھا۔
بگ کی وضاحت اس طرح کی گئی ہے: V8 میں کنفیوژن ٹائپ کریں۔ (سمجھ سے، گوگل اس مرحلے پر اس سے زیادہ نہیں کہہ رہا ہے۔)
جیسا کہ ہم پہلے بیان کر چکے ہیں، a قسم کی الجھن بگ تب ہوتا ہے جب آپ کسی پروگرام کو اعداد و شمار کے ایک ٹکڑے کے ساتھ فراہم کرتے ہیں جس کے بارے میں سمجھا جاتا ہے کہ اسے ایک طرح سے تجزیہ کرنا، درست کرنا، عمل کرنا اور اس پر عمل کرنا ہے…
…لیکن آپ بعد میں ڈیٹا کی مختلف، غیر مجاز، غیر تصدیق شدہ، اور ممکنہ طور پر خطرناک طریقے سے تشریح کرنے کے لیے پروگرام کو دھوکہ دینے کا انتظام کرتے ہیں۔
قسم کے الجھن کے خطرات کی وضاحت کی گئی۔
تصور کریں کہ آپ C میں ایک پروگرام لکھ رہے ہیں۔
C میں، آپ عام طور پر انفرادی طور پر متغیرات کا اعلان کرتے ہیں، اس طرح نہ صرف میموری کو محفوظ کرتے ہیں جہاں انہیں ذخیرہ کیا جا سکتا ہے، بلکہ پروگرام کو یہ اشارہ بھی دیتے ہیں کہ ان متغیرات کو کس طرح استعمال کیا جانا چاہیے۔
مثال کے طور پر:
لمبا لمبا int JulianDayNumber; دستخط شدہ چار* گاہک کا نام؛
پہلا متغیر اعلان فلکیاتی دن کے نمبر کی نمائندگی کرنے والی سادہ پرانی عددی قدر کو ذخیرہ کرنے کے لیے 64 بٹس محفوظ رکھتا ہے۔ (اگر آپ سوچ رہے ہیں تو، یہ دوپہر JDN 23157 ہے - جولین ڈے دوپہر سے شروع ہوتے ہیں، آدھی رات کو نہیں، کیونکہ فلکیات دان اکثر رات کو کام کرتے ہیں، آدھی رات ان کے کام کے دن کے درمیان ہوتی ہے۔)
دوسرا میموری ایڈریس کو ذخیرہ کرنے کے لیے 64 بٹس محفوظ رکھتا ہے جہاں صارف کے نام کی ٹیکسٹ سٹرنگ مل سکتی ہے۔
جیسا کہ آپ تصور کر سکتے ہیں، بہتر ہے کہ آپ ان دونوں اقدار کو آپس میں نہ ملا دیں، کیونکہ ایک ایسا نمبر جو سمجھ میں آتا ہے، اور محفوظ ہے، ایک دن کے نمبر کے طور پر استعمال کرنا، جیسے کہ 23157، تقریباً یقینی طور پر میموری ایڈریس کے طور پر استعمال کرنا غیر محفوظ ہوگا۔
جیسا کہ آپ چلتے ہوئے ونڈوز پروگرام کے اس میموری ڈمپ سے دیکھ سکتے ہیں، استعمال کے لیے مختص کردہ سب سے کم میموری ایڈریس شروع ہوتا ہے۔ 0x00370000، جو اعشاریہ میں 3,604,480 ہے، کسی بھی معقول دن کے نمبر سے بڑا ہے۔
ونڈوز کے ذریعے استعمال ہونے والے اصل میموری ایڈریس وقت کے ساتھ ساتھ تصادفی طور پر مختلف ہوتے ہیں، تاکہ آپ کی میموری کی ترتیب کو بدمعاشوں کے لیے اندازہ لگانا مشکل ہو، لہذا اگر آپ ایک ہی پروگرام کو چلاتے، تو آپ کو قدریں ملیں گی، لیکن اس کے باوجود وہ ایک جیسے ہوں گے:
اور (اگرچہ یہ اوپر کی تصویر کے نیچے سے ہے) رن ٹائم صارف ڈیٹا سیکشن کے میموری ایڈریس جب یہ پروگرام شروع ہوا 0x01130000 کرنے کے لئے 0x01134FFF، 22 جولائی 44631 سے 16 اگست 44687 کی غیر متوقع تاریخ کی حد کی نمائندگی کرتا ہے۔
درحقیقت، اگر آپ ان دو متغیرات کو ملانے کی کوشش کرتے ہیں تو، مرتب کرنے والے کو آپ کو متنبہ کرنے کی کوشش کرنی چاہیے، مثال کے طور پر اس طرح:
JulianDayNumber = CustomerName; کسٹمر کا نام = جولین ڈے نمبر؛ انتباہ: اسائنمنٹ بغیر کاسٹ وارننگ کے پوائنٹر سے انٹیجر بناتی ہے: اسائنمنٹ بغیر کاسٹ کے انٹیجر سے پوائنٹر بناتی ہے
اب، اگر آپ نے کبھی C میں پروگرام کیا ہے، تو آپ کو معلوم ہوگا کہ سہولت کے لیے، آپ متعدد مختلف تشریحات کے ساتھ متغیرات کا اعلان کر سکتے ہیں union مطلوبہ الفاظ، اس طرح:
یونین { long long int JulianDayNumer; دستخط شدہ چار* گاہک کا نام؛ } ڈیٹا؛
اب آپ میموری میں بالکل ایک ہی متغیر کا دو مختلف طریقوں سے حوالہ دے سکتے ہیں۔
اگر آپ لکھیں۔ data.JulianDayNumber، آپ جادوئی طور پر ذخیرہ شدہ ڈیٹا کو ایک عدد کے طور پر بیان کرتے ہیں، لیکن تحریر data.CustomerName کمپائلر کو بتاتا ہے کہ آپ میموری ایڈریس کا حوالہ دے رہے ہیں، حالانکہ آپ اسی ذخیرہ شدہ ڈیٹا تک رسائی حاصل کر رہے ہیں۔
آپ جو کچھ کر رہے ہیں، کم و بیش، مرتب کرنے والے کو یہ تسلیم کر رہا ہے کہ آپ کبھی کبھی اپنے حاصل کردہ ڈیٹا کو تاریخ کے طور پر استعمال کریں گے، اور دوسری بار میموری ایڈریس کے طور پر، اور وہ آپ یہ یاد رکھنے کی ذمہ داری لے رہے ہیں کہ کون سی تشریح کس لمحے لاگو ہوتی ہے۔ کوڈ میں
آپ دوسرا متغیر رکھنے کا فیصلہ کر سکتے ہیں، جسے a کہا جاتا ہے۔ tag (عام طور پر ایک عدد) اپنے ساتھ جانے کے لیے union آپ اس وقت کس قسم کے ڈیٹا کے ساتھ کام کر رہے ہیں اس پر نظر رکھنے کے لیے، مثال کے طور پر:
struct { int tag; یونین { long long int JulianDayNumer; دستخط شدہ چار* گاہک کا نام؛ } ڈیٹا؛ } قدر؛
آپ فیصلہ کر سکتے ہیں کہ کب value.tag کرنے کے لئے مقرر کیا گیا ہے 0، ڈیٹا کو ابھی استعمال کے لیے شروع نہیں کیا گیا ہے، 1 اس کا مطلب ہے کہ آپ تاریخ محفوظ کر رہے ہیں، 2 اس کا مطلب ہے کہ یہ ایک میموری ایڈریس ہے، اور کوئی اور چیز غلطی کی نشاندہی کرتی ہے۔
ٹھیک ہے، بہتر ہے کہ آپ کسی اور کو اس کے ساتھ گڑبڑ نہ ہونے دیں۔ value.tag ترتیب، یا آپ کا پروگرام ڈرامائی طور پر غلط برتاؤ کا خاتمہ کر سکتا ہے۔
اس سے زیادہ پریشان کن مثال کچھ اس طرح ہو سکتی ہے:
ساخت { int tag; // 1 = ہیش، 2 = فنکشن پوائنٹرز یونین { غیر دستخط شدہ چار ہیش[16]؛ // یا تو ایک بے ترتیب ہیش ڈھانچہ ذخیرہ کریں { void* openfunc؛ // یا دو احتیاط سے توثیق شدہ void* closefunc؛ // بعد میں عمل کرنے کے لیے کوڈ پوائنٹرز } توثیق کریں؛ } } قدر؛
اب، ہم میموری کے اسی بلاک کو اوور لوڈ کر رہے ہیں لہذا ہم اسے کبھی کبھی 16 بائٹ ہیش کو ذخیرہ کرنے کے لیے استعمال کر سکتے ہیں، اور کبھی کبھی دو 8 بائٹ پوائنٹرز کو ان فنکشنز کے لیے ذخیرہ کرنے کے لیے جن پر ہمارا پروگرام بعد میں کال کرے گا۔
واضح طور پر، جب value.tag == 1، ہمیں خوشی ہو گی کہ ہمارے سافٹ ویئر کو یونین کے لیے مختص کردہ میموری میں کسی بھی 16 بائٹ سٹرنگ کو ذخیرہ کرنے کی اجازت دی جائے، کیونکہ ہیشز سیوڈورنڈم ہیں، اس لیے بائٹس کے کسی بھی مجموعہ کا اتنا ہی امکان ہے۔
لیکن جب value.tag == 2، ہمارے کوڈ کو بہت زیادہ محتاط رہنے کی ضرورت ہوگی تاکہ صارف کو بعد میں عمل کرنے کے لیے غیر تصدیق شدہ، ناقابل اعتماد، نامعلوم فنکشن ایڈریس فراہم کرنے کی اجازت نہ دے۔
اب تصور کریں کہ آپ اس کوڈ پر ایک قدر جمع کر سکتے ہیں جب کہ ٹیگ 1 پر سیٹ کیا گیا تھا، اس لیے اس کی جانچ اور تصدیق نہیں ہوئی…
…لیکن بعد میں، پروگرام کے اصل میں ذخیرہ شدہ قدر استعمال کرنے سے پہلے، آپ ٹیگ کو 2 میں تبدیل کرنے کے لیے کوڈ کو چال کرنے میں کامیاب ہو گئے۔
اس کے بعد کوڈ آپ کے غیر تصدیق شدہ فنکشن ایڈریسز کو "معلوم اور پہلے سے تصدیق شدہ محفوظ" کے طور پر قبول کرے گا (حالانکہ وہ نہیں تھے) اور اعتماد کے ساتھ پروگرام کے عمل کو میموری میں کسی بدمعاش مقام پر بھیجے گا جسے آپ نے چپکے سے پہلے سے منتخب کیا تھا۔
اور یہی ایک قسم کے کنفیوژن بگ میں ہوتا ہے، اگرچہ ایک متضاد اور آسان مثال کا استعمال کرتے ہوئے،
یادداشت جو استعمال کرنے کے لیے محفوظ ہو گی اگر اسے ایک طرح سے ہینڈل کیا جائے تو اسے متبادل، غیر محفوظ طریقے سے پروسیس کرنے کے لیے پروگرام کو بدنیتی سے پہنچایا جاتا ہے۔
کیا کیا جائے؟
یقینی بنائیں کہ آپ کے پاس Chrome یا Chromium کا تازہ ترین ورژن ہے۔
آپ کروم چاہتے ہیں۔ 114.0.5735.106 یا بعد میں میک اور لینکس پر، اور 114.0.5735.110 یا بعد میں ونڈوز پر۔
مائیکروسافٹ ایج، جو کرومیم پر مبنی ہے، بھی اس بگ سے متاثر ہے۔
مائیکروسافٹ نے اب تک [2023-06-06T16:25:00Z] نے کہا کہ
مائیکروسافٹ جنگل میں موجود حالیہ کارناموں سے واقف ہے۔ ہم سیکیورٹی پیچ جاری کرنے پر سرگرمی سے کام کر رہے ہیں۔
Edge فی الحال ورژن 114.0.1823.37 پر ہے، لہذا کچھ بھی نمبر ہے۔ اس کے بعد Microsoft کے CVE-2023-3079 پیچ کو شامل کرنا چاہیے۔
اپنا ورژن چیک کرنے اور اگر کوئی ایسا ہے جو آپ کو ابھی تک موصول نہیں ہوا ہے تو اسے زبردستی اپ ڈیٹ کرنے کے لیے:
- گوگل کروم تھری ڈاٹ مینو (⋮) > مدد > کروم کے بارے میں۔
- مائیکروسافٹ ایج. ترتیبات اور مزید (…) > مدد اور آراء > مائیکروسافٹ ایج کے بارے میں۔
خوش آمدید.
- SEO سے چلنے والا مواد اور PR کی تقسیم۔ آج ہی بڑھا دیں۔
- پلیٹوآئ اسٹریم۔ ویب 3 ڈیٹا انٹیلی جنس۔ علم میں اضافہ۔ یہاں تک رسائی حاصل کریں۔
- ایڈریین ایشلے کے ساتھ مستقبل کا نقشہ بنانا۔ یہاں تک رسائی حاصل کریں۔
- PREIPO® کے ساتھ PRE-IPO کمپنیوں میں حصص خریدیں اور بیچیں۔ یہاں تک رسائی حاصل کریں۔
- ماخذ: https://nakedsecurity.sophos.com/2023/06/06/chrome-zero-day-this-exploit-is-in-the-wild-so-check-your-version-now/