OpenVPN ہک اپنی اسکرپٹ کے ساتھ والی فائل کیوں نہیں ڈھونڈ سکتا

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

اجازتوں سے پہلے راستہ جانچیں، کیونکہ غلط فائل پر اجازت کی خرابی پھر بھی غلط فائل ہی ہے۔

نسبتی راستہ فائل کے بجائے عمل کے حوالے سے حل ہوتا ہے

جب اسکرپٹ open("policy.json") کو کال کرتا ہے، کرنل اس نام کو عمل کی موجودہ کارکن ڈائریکٹری کے حوالے سے حل کرتا ہے۔ اسکرپٹ کے اپنے مقام سے کوئی چیز اس تلاش میں شامل نہیں ہوتی۔ OpenVPN ہک اپنی چنی ہوئی ڈائریکٹری سے شروع کرتا ہے، اور cd اختیار اسے بدل سکتا ہے، اس لیے اپنے ہی فولڈر سے ہاتھ سے جانچی گئی اسکرپٹ ڈیمن کے چلانے پر مختلف برتاؤ کرتی ہے۔ ہاتھ کا امتحان پاس ہوتا ہے، خدمت کا چلنا ناکام ہوتا ہے، اور لاگ کی سطر صرف گمشدہ نام کا ذکر کرتی ہے۔

Python اسکرپٹ کے مقام کو __file__ کے طور پر ظاہر کرتا ہے، اور یہی لنگر کرنا ممکن بناتا ہے۔ Path(__file__).resolve().parent / "policy.json" عمل کے بجائے فائل سے راستہ بناتا ہے۔ وہ ایک سطر مراعات میں کچھ بدلے بغیر کارکن ڈائریکٹری کا انحصار ہٹا دیتی ہے۔

راستے کو جان بوجھ کر لنگر کریں، پھر دیکھیں resolve کیا کرتا ہے

resolve() علامتی ربطوں کی پیروی کرتا ہے، اس لیے جو تنصیب ہک کو اس کی جگہ پر ربط کرتی ہے وہ ربط کے ہدف پر لنگر ہوتی ہے، ربط رکھنے والی ڈائریکٹری پر نہیں۔ ورژن والی تعیناتی کے لیے عام طور پر یہی مطلوب ہوتا ہے، اور علامتی ربط کے ساتھ ڈیٹا کی توقع رکھنے والے ترتیب کے لیے یہ غلط ہے۔ فیصلہ کریں کہ تعیناتی کا مطلب کیا ہے، اور پیداوار میں فرق دریافت کرنے کے بجائے اسی کے مطابق کوڈ لکھیں۔ Path(__file__).parent کے بغیر resolve() ربط کی اپنی ڈائریکٹری رکھتا ہے۔

اگر ڈیٹا پروگرام کا نہیں بلکہ مثال کا ہے تو ترتیب سے مطلق راستہ لیں۔ مقام کو سخت کوڈ کرنا ہک کو ایک ہی میزبان ترتیب سے باندھ دیتا ہے۔

چار حدیں ترتیب سے پار کریں

کارکن ڈائریکٹری سے شروع کریں: یونٹ کی WorkingDirectory, OpenVPN کا cd اختیار اور exec سے پہلے ڈائریکٹری بدلنے والے کسی بھی ریپر کا موازنہ کریں۔ پھر حل شدہ مقام کی تصدیق کریں، کیونکہ کسی دوسری تعیناتی میں یکساں نام کی فائل تلاش کا جواب دے کر خرابی چھپا سکتی ہے۔ اگے فائل سسٹم کا نظارہ آتا ہے: chroot یا خدمت کا ماؤنٹ نیم اسپیس میزبان کا مطلق راستہ سیدھا غائب کر سکتے ہیں۔ آخر میں رسائی کی شناخت، جو نظر آنے سے الگ سوال ہے۔

ProtectHome اور PrivateTmp مختلف مقامات چھپاتے ہیں، اور میزبان سے لی گئی ڈائریکٹری فہرست میں دونوں میں سے کوئی نظر نہیں آتا۔ شیل میں root کے لیے موجود راستہ یونٹ کے نیم اسپیس کے اندر نظر نہ آنے والا ہو سکتا ہے، اور اسی لیے خدمت سے باہر وہی کمانڈ جانچنا بہت کم ثابت کرتا ہے۔

خدمت کو وسیع کیے بغیر تلاش درست کریں

راستے کو لنگر کرنا صرف پہلی حد حل کرتا ہے۔ یہ وہ ڈائریکٹری ظاہر نہیں کرتا جو خدمت چھپاتی ہے، اور یہ غیر مراعات یافتہ اکاؤنٹ کو صرف root کے لیے والی فائل تک رسائی نہیں دیتا۔ script-security بڑھانا یہ بدلتا ہے کہ OpenVPN کون سی اسکرپٹیں چلائے گا؛ نسبتی نام کہاں حل ہوتا ہے اس پر اس کا کوئی اثر نہیں۔ پوری خدمت کے لیے کارکن ڈائریکٹری بدلنا مسئلے سے زیادہ وسیع ہے، کیونکہ ہر دوسرا نسبتی سرٹیفکیٹ، لاگ یا معاون راستہ اس کے ساتھ چلتا ہے۔

تنگ درستی کو ترجیح دیں: اسکرپٹ میں طے شدہ راستہ، مثال کے ڈیٹا کے لیے واضح ترتیب کی قدر، اور فائل کی ملکیت جو اس اکاؤنٹ سے میل کھائے جس کے تحت ہک واقعی چلتا ہے۔

حد کا نام لینے والے شواہد درج کریں

مفید ناکامی رپورٹ میں تین چیزیں ہوتی ہیں: وہ درست راستہ جو ہک نے آزمایا، وہ ماحول جس نے اسے پیدا کیا، اور کس حد نے انکار کیا۔ فائل کا مواد انڈیلے بغیر حل شدہ راستہ اور استثنا طبع کریں۔ یہ ثلاثی غلط لنگر کو چھپے ہوئے ماؤنٹ سے اور اجازت کے انکار سے الگ کرتی ہے، اور یہ تین مختلف درستیاں ہیں۔

یہ دعویٰ کہ root ٹرمینل سے فائل پڑھ سکتا ہے ان سوالوں میں سے صرف ایک کا جواب دیتا ہے اور باقی کسی کا نہیں۔ اس کے بجائے خدمت ہی کے سیاق سے جانچیں۔