Qubes OS کی isolation ٹوٹی؛ ایک فائل نام dom0 کا اختیار دے سکتا ہے

Qubes ٹیم نے 29 اگست 2026 کو QSB-118 شائع کیا، جس میں تصدیق کی گئی کہ پہلے سے متاثرہ qube مخصوص file-copy error path کے ذریعے dom0 میں arbitrary command چلا سکتی ہے۔ سرکاری QSB-118 bulletin کے مطابق اس سے حملہ آور پوری Qubes OS installation کا اختیار حاصل کر سکتا ہے، تمام releases متاثر ہیں اور Qubes 4.3 کے لیے اصلاحی dom0 package جاری کیا گیا ہے۔

اسی 29 اگست کے اعلان میں بیان کردہ حملہ عام فائل وصولی سے شروع نہیں ہوتا۔ پہلے ایک qube حملہ آور کے قابو میں ہونا چاہیے، پھر صارف کو dom0 سے اسی qube کی طرف qvm-copy-to-vm کے ذریعے فائل بھیجنی ہوتی ہے؛ اس کے بعد target qube کا بنایا ہوا error response malicious filename واپس لا کر کمزوری کو trigger کر سکتا ہے۔

حملے کی تین شرطیں کیا ہیں؟

اس isolation bypass کو سمجھنے کے لیے تین الگ شرطوں کو ایک ہی chain میں دیکھنا ضروری ہے۔ صرف malicious qube کی موجودگی، کسی qube میں انٹرنیٹ سے فائل آنا یا qubes کے درمیان معمول کی نقل و حرکت bulletin میں بیان کردہ dom0 compromise ثابت نہیں کرتی۔

1. حملہ آور پہلے اس destination qube کو compromise کرے یا پہلے ہی اس پر قابض ہو جسے فائل بھیجی جانی ہے۔
2. صارف dom0 میں qvm-copy-to-vm چلا کر اسی متاثرہ destination کو فائل بھیجے۔ حملہ آور خود سے یہ dom0-side action شروع نہیں کر سکتا۔
3. Destination qube منتقلی کی confirmation میں error code کے ساتھ ایسا آخری filename واپس کرے جس میں shell metacharacters موجود ہوں؛ یہ نام dom0 کے error handler تک پہنچ کر command injection پیدا کرے۔

نتیجہ شدید ہے کیونکہ code execution عام qube کے اندر محدود نہیں رہتی بلکہ dom0 میں ہوتی ہے۔ مگر عنوان میں بیان کردہ isolation کی شکست انہی مخصوص شرائط کے تحت ممکن ہے: یہ کسی malicious نام والی فائل کو محض کھولنے یا وصول کرنے والی عمومی خامی نہیں۔

اصل کمزوری فائل کے مواد میں نہیں

qvm-copy-to-vm dom0 سے منتخب qube کو فائل بھیجنے کے لیے qfile protocol استعمال کرتا ہے۔ منتقلی کے اختتام پر target ایک confirmation واپس بھیجتا ہے جس میں checksum، error code اور آخری وصول شدہ فائل کا نام شامل ہوتا ہے۔ Error کی صورت میں dom0 اسی واپس آئے نام کو GUI پیغام میں شامل کرتا ہے۔

نام کو error handler تک بھیجنے سے پہلے موجود sanitization غیر printable حروف اور double quotation mark کو بدلتی تھی، لیکن shell metacharacters کو نہیں روکتی تھی۔ اس کے بعد dom0 کا error-reporting code dialog بنانے کے لیے attacker-controlled متن کو system() سے چلنے والی command میں شامل کرتا تھا؛ یوں filename کا ایک حصہ shell syntax بن سکتا تھا۔

30 اگست کو شائع ہونے والی LavX کی تکنیکی رپورٹ نے بھی اسی chain کی تفصیل دی: نام نامکمل sanitization سے گزرتا ہے، dom0 کے system() call تک پہنچتا ہے اور arbitrary code execution کا راستہ بناتا ہے۔ رپورٹ یہ بھی واضح کرتی ہے کہ qvm-copy-to-vm کا VM-side error reporter execlp() استعمال کرتا ہے، اس لیے ثابت شدہ خامی صرف dom0 والے code path میں ہے۔

تمام releases متاثر، fix Qubes 4.3 کے لیے نامزد

Affected-systems فہرست میں کسی Qubes OS release کو مستثنیٰ نہیں کیا گیا۔ اس کے برعکس patching فہرست مخصوص ہے: Qubes 4.3 کے dom0 کے لیے qubes-core-dom0-linux 4.3.22 وہ package ہے جس میں security fix شامل ہے۔ اس فرق کا مطلب یہ ہے کہ ہر release متاثر ہو سکتی ہے، لیکن bulletin نے ہر release کے لیے الگ اصلاحی package نامزد نہیں کیا۔

ابتدائی bulletin میں 4.3.22 کو security-testing سے مختصر community testing کے بعد current یعنی stable repository میں منتقل کرنے کا منصوبہ درج تھا۔ اب Qubes 4.3 کے current dom0 repository میں qubes-core-dom0-linux 4.3.22 موجود ہے، اس لیے Qubes 4.3 صارف اسے معمول کے stable update راستے سے حاصل کر سکتے ہیں؛ security-testing repository فعال کرنا ضروری نہیں۔

پرانے، غیر معاون یا کسی دوسرے release پر 4.3 کا package دستی طور پر نصب کرنا درست متبادل نہیں۔ اس صورت میں دستیاب supported release اور اس کے repository metadata کے مطابق update یا upgrade درکار ہوگا، کیونکہ “تمام releases متاثر” ہونے کا بیان ایک ہی RPM کو ہر installation کے لیے موزوں نہیں بناتا۔

محفوظ update کیسے حاصل ہوگا؟

Qubes 4.3 پر Applications Menu کے Qubes Tools حصے سے Qubes Update tool کھول کر dom0 کو منتخب کریں اور دستیاب updates نصب کریں۔ Command line استعمال کرنے والے ماہرین dom0 terminal میں qubes-dom0-update چلا سکتے ہیں۔ دونوں صورتوں میں fix templates کے بجائے dom0 package میں آتی ہے، اس لیے صرف template updates مکمل ہونا کافی نہیں۔

براہ راست dnf update یا apt update چلانے کے بجائے Qubes Update tool یا اس کے منظور شدہ command-line equivalent کا استعمال ضروری ہے، کیونکہ معمول کے Qubes update mechanism میں package retrieval اور verification کے حفاظتی انتظامات شامل ہیں۔ Update کے بعد Qubes 4.3 پر نصب qubes-core-dom0-linux version کم از کم 4.3.22 ہونی چاہیے۔

موجودہ صورت حال میں QSB-118 کا patch Qubes 4.3 کے stable repository میں دستیاب ہے اور bulletin نے معمول کی update کے علاوہ کوئی اضافی لازمی user action مقرر نہیں کیا۔ باقی releases کے لیے فیصلہ ان کی support status اور دستیاب اصلاحی packages پر منحصر ہے؛ ثابت شدہ خطرہ بدستور وہی تین مرحلوں والی chain ہے، نہ کہ ہر آنے والی فائل سے خودکار dom0 compromise۔

یہ بھی پڑھیں:

• پاکستانی طلبہ کے لیے ایک سال کا Gemini—معاہدے میں کیا طے ہوا؟
• AI bubble ایک نہیں—نئی تحقیق بتاتی ہے خطرہ کن کمپنیوں میں ہے
• AI bubble ایک ہی منڈی نہیں، تحقیق نے کمپنیوں کے درمیان فرق دکھا دیا