سمح التسرب الأخير لـ "المفتاح الذهبي" من Microsoft إلى جانب وجود وضع التصحيح بتعطيل التمهيد الآمن على أجهزة Windows. واصل القراءة!
لم تعد أنظمة التشغيل المستندة إلى Windows هي الخيار الافتراضي والأفضل في مشهد الأجهزة المحمولة. لقد وجدت طبيعة المصدر المفتوح لنظام Android العديد من المعجبين في الشركات المصنعة للمعدات الأصلية، ونتيجة لذلك، يستخدم عدد أقل وأقل من الهواتف نظام التشغيل Windows هذه الأيام.
ولكن إذا كنت من بين أولئك الذين ما زالوا يستخدمون جهاز Windows في حياتهم اليومية، فهناك بعض الأخبار لك. جيد أو سيئ، يعتمد ذلك على موقفك وتفسيرك لحالات استخدام هذا الخبر.
كما أفادت آرس تكنيكا و السجل مع الأخبار الصادرة من أ موقع الويب الذي من المحتمل أن يسبب لك الصداع (لا أمزح)، عدد قليل من المطورين (@never_released و @TheWack0lian) اكتشفوا أن الباب الخلفي الذي اخترعته Microsoft لأغراض تصحيح الأخطاء قد فتح إمكانيات تعطيل التمهيد الآمن على أجهزة Windows.
التمهيد الآمن وما هو؟
عند تشغيل جهاز يعمل بنظام Windows لأول مرة، يتم تنفيذ إجراء التمهيد بهذا الترتيب العام: UEFI (واجهة البرامج الثابتة القابلة للتوسيع الموحدة، والتي تعد بديلاً لنظام BIOS) -> مدير التمهيد -> محمل التمهيد -> شبابيك. UEFI هو المكان الذي توجد فيه وظيفة التمهيد الآمن. كما يوحي الاسم مع
الإقلاع الآمن, يهدف إلى تحسين الأمان من خلال طلب التوقيعات الرقمية في الخطوات التالية. بشكل أساسي، إذا لم يتم توقيع أداة تحميل التشغيل باستخدام المفاتيح التي تتوقع UEFI أن تكون معها، فلن يكتمل إجراء تشغيل جهازك.يعد Secure Boot ميزة اختيارية، لكن Microsoft جعلت تمكينها إلزاميًا للحصول على شهادة Windows من Windows 8 وما بعده. كان السبب هنا هو أن Secure Boot سيجعل من الصعب على مؤلفي البرامج الضارة إدخال تعليمات برمجية في إجراء التمهيد. ومع ذلك، كان أحد الآثار الجانبية للتمهيد الآمن هو أنه جعل الأمر معقدًا بعض الشيء للتمهيد المزدوج على أجهزة Windows، مثل إما أن يكون نظام التشغيل الثاني وجميع متطلباته المسبقة بحاجة إلى التوقيع رقميًا، أو يجب أن يكون التمهيد الآمن كذلك عاجز. هناك الكثير من المشكلات الأخرى المتعلقة بهذا الأمر، وسيعرف أصحاب التشغيل المزدوج المتمرسون عنها أكثر مما أستطيع شرحه في فقرة.
الآن، هناك بعض الأجهزة التي لا يمكن للمستخدم تعطيل Secure Boot عليها حتى لو أراد ذلك. هذا هو المجال الذي يتم فيه تضييق موضوعنا بشكل كبير من جميع أجهزة Windows (بما في ذلك أجهزة سطح المكتب) إلى أجهزة Windows محددة مثل أجهزة Windows Phone وأجهزة Windows RT وبعض أجهزة Surface وحتى هولولنس. تحتوي أجهزة المستخدم النهائي هذه على تم قفل التمهيد الآمن، بمعنى أن لا يمكن للمستخدم النهائي تعديل أو تعطيل الجوانب المتعلقة بالتمهيد الآمنوبالتالي، لا يمكنهم لمس نظام التشغيل بطرق غير مصرح بها من قبل Microsoft للمستخدم النهائي.
ولكن لأغراض التطوير الرسمي المستمر، يحتاج Secure Boot إلى التخفيف قليلاً. على الأجهزة التي تم قفل Secure Boot عليها، توجد سياسات التمهيد الآمن التي يمكن أن تساعد في التطوير المعتمد دون الحاجة إلى تعطيل Secure Boot. كما ذكر المستخدمون الباحثون، يتم تحميل ملف سياسة التمهيد الآمن هذا بواسطة مدير التمهيد في وقت مبكر من عملية التمهيد لنظام التشغيل Windows. يمكن أن تحتوي ملفات السياسة أيضًا على قواعد التسجيل والتي بدورها لديها القدرة على احتواء تكوينات السياسة نفسها من بين أشياء أخرى. مرة أخرى، يجب توقيع ملف السياسة، كما توجد أحكام أخرى موجودة للتأكد من أن Microsoft فقط هي التي يمكنها توفير هذه التغييرات.
ويعتمد عنصر التوقيع أيضًا على ما يسمى معرف الجهاز، والذي يتم استخدامه عند التقديم. سأدع منشور المدونة يقوم بالشرح هنا، نظرًا لوجود بعض الأجزاء غير الواضحة بالنسبة لي:
يوجد أيضًا شيء يسمى DeviceID. إنها أول 64 بت من تجزئة SHA-256 المملحة، من بعض مخرجات UEFI PRNG. يتم استخدامه عند تطبيق السياسات على Windows Phone وWindows RT (يقوم mobilestartup بتعيينه على Phone وSecureBootDebug.efi عند تشغيله لأول مرة على RT). على الهاتف، يجب أن تكون السياسة موجودة في مكان محدد على قسم EFIESP مع اسم الملف بما في ذلك الشكل السداسي لمعرف الجهاز. (مع Redstone، تم تغيير هذا إلىUnlockID، الذي تم تعيينه بواسطة bootmgr، وهو مجرد مخرج UEFI PRNG الأولي).
بشكل أساسي، يتحقق bootmgr من السياسة عند تحميلها، وإذا كانت تتضمن معرف الجهاز، الذي لا يتطابق مع معرف الجهاز الخاص بالجهاز الذي يعمل عليه bootmgr، فسوف يفشل تحميل السياسة. أي سياسة تسمح بتمكين التوقيع على الاختبار (يستدعي MS سياسات إلغاء قفل جهاز البيع بالتجزئة / RDU هذه، و تثبيتها هو إلغاء قفل الجهاز)، ومن المفترض أن يتم قفله بمعرف الجهاز (UnlockID على Redstone و فوق). في الواقع، لدي العديد من السياسات (موقعة بواسطة شهادة إنتاج Windows Phone) مثل هذه، حيث تكون الاختلافات الوحيدة هي معرف الجهاز المضمن والتوقيع. إذا لم يتم تثبيت سياسة صالحة، يلجأ bootmgr إلى استخدام السياسة الافتراضية الموجودة في موارده. هذه السياسة هي التي تمنع تمكين التوقيع على الاختبار، وما إلى ذلك، باستخدام قواعد BCD.
هذا هو الجزء الذي تصبح فيه الأمور مثيرة للاهتمام. أثناء تطوير Windows 10 v1607، أنشأت Microsoft نوعًا جديدًا من سياسة التمهيد الآمن (يشار إليها باسم SBP من الآن فصاعدًا للإيجاز) لأغراض الاختبار الداخلي وتصحيح الأخطاء. تعتبر هذه السياسة "تكميلية" بطبيعتها مع عدم وجود معرف الجهاز، وتؤدي إلى دمج إعداداتها في سياسة التمهيد الحالية. يقوم Boot Manager بتحميل الأنواع القديمة من SBP، ثم يتحقق من توقيعه وأصالته، ثم يقوم بتحميل سياسات التمهيد الإضافية هذه. المشكلة هنا هي أنه لا يوجد أي تحقق إضافي على السياسة التكميلية نفسها. كما أن مديري التمهيد الأقدم من Windows 10 v1511 لا يعرفون بوجود الطبيعة التكميلية لهذه السياسات، وبالتالي، تتفاعل كما لو أنهم قاموا بتحميل سياسة صحيحة وموقعة تمامًا. مرة أخرى، كان من المحتمل أن يكون هذا السلوك للتطوير الداخلي، لذا لم يكن من المفترض أن يضطر المطورون إلى التوقيع على كل إصدار من إصدارات نظام التشغيل وتغييرات طفيفة يتعين عليهم إجراؤها على الجهاز.
تتم الإشارة إلى SBP هذا على أنه "المفتاح الذهبي" لأنه يبطل بشكل أساسي الغرض من التحقق من التوقيع. تم شحن SBP هذا عن غير قصد إلى أجهزة البيع بالتجزئة، وإن كان في حالة غير مفعلة. عثر المطورون على SBP وأعلنوا النتائج التي توصلوا إليها. الآن، يمكن أن يكون SBP وجدت طافية على شبكة الإنترنت، مع استخدام هذا الرمز البريدي الخاص لتثبيت SBP على أجهزة Windows RT.
ماذا يعني هذا؟
إذا قمت بتحميل SBP إضافي، فيمكنك تمكين التوقيع الاختباري لنظام التشغيل Windows للسماح لك بتحميل برامج التشغيل غير الموقعة. علاوة على ذلك، نظرًا لأن هذه السياسات تدخل حيز التنفيذ قبل مرحلة Boot Manager في إجراء التمهيد، فيمكنك تعريض أمان الطلب بأكمله للخطر وتشغيل تعليمات برمجية غير مصرح بها (قراءة الموقعة ذاتيًا). وهذا يفتح الكثير من الاحتمالات للمستخدمين الذين يعتزمون تعديل أجزاء من Windows بما يتجاوز الترخيص ولمنشئي البرامج الضارة على حدٍ سواء.
يركز مؤلفو هذه النتيجة على مفارقة الفشل الذريع برمته. قامت Microsoft بتأمين التشغيل الآمن على أجهزة معينة لإبعاد التغييرات غير المصرح بها، ولكنها قامت بعد ذلك بإنشاء باب خلفي للسماح لها بمواصلة التطوير وتصحيح الأخطاء. لكن هذا الباب الخلفي يمهد الطريق لتعطيل Secure Boot على جميع الأجهزة التي تعمل بنظام Windows، مما يجعل المحنة برمتها بلا معنى.
لا يقتصر الأمر على المستخدمين الراغبين في تثبيت توزيعات Linux (وربما Android) على الأجهزة اللوحية التي تعمل بنظام Windows فقط الهواتف، يمكن أيضًا أن يكون لدى المستخدمين غير الراغبين مجموعات تمهيد ضارة مثبتة إذا قاموا بتهديد الوصول الفعلي إلى أجهزة الكمبيوتر الخاصة بهم جهاز. في حين أن الأول هو شيء يمكننا القفز عليه في الهواء، فإن الأخير لا يغرس الكثير من الثقة حقًا. إنه يسير في كلا الاتجاهين، ويوضح لنا لماذا يعتبر الأمن سيفًا ذا حدين. علاوة على ذلك، فإن SBP عالمي بطبيعته، مما يسمح باستخدامه على أي جهاز بغض النظر عن بنيته المعمارية. إنه ليس مفيدًا بشكل خاص لحالات أجهزة الكمبيوتر المكتبية حيث يمكن إيقاف تشغيل Secure Boot بسهولة، ولكنه ذو نطاق هائل للأجهزة التي لا يمكنك العبث فيها باستخدام Secure Boot.
إذن، ما هو الحل؟
أصدرت Microsoft بعض التصحيحات، لكن المطورين يصرون على أن المشكلة لم يتم حلها بالكامل. يمكنك التحقق من هذه التصحيحات (MS16-094 و MS16-100) ثم اقرأ على مشاركة مدونة نفسها حول سبب عدم حل المشكلة. إذا كانت صحيحة، فلن يكون لهذه المشكلة حل أو تصحيح في الأفق، على الرغم من أن ذلك لن يمنع Microsoft من محاولة وضع المزيد من الحواجز على الطريق.
ماذا بعد؟
هناك عالم من الإمكانيات، وبعضها قيد الإنشاء في منتديات Windows الخاصة بنا. يمكنك الاطلاع على منتدياتنا على تطوير واختراق ويندوز فون 8 ومنتدياتنا ل Windows 8 وWindows RT وتطوير السطح والقرصنة. يمكنك أيضا العثور على خيوط التعليمات لبعض الأجهزة، حيث يناقش المستخدمون الآخرون نفس الشيء.
يعد وجود هذا الباب الخلفي لتصحيح الأخطاء وتسريب SBP أمرًا مهمًا ليس فقط بالنسبة للطرف الثالث تطوير أجهزة Windows المقفلة، فإنها تظهر لنا أيضًا تذكيرًا قاتمًا بما يمكن أن يحدث إذا كان مقصودًا تم ترك الأبواب الخلفية. وقد تحول التركيز الأخير على الأمن نحو وكالات التحقيق التي تضغط من أجل استخدام مثل هذه الأبواب الخلفية للمساعدة في تحقيق أغراضها القانونية. ولكن عاجلا أم آجلا، هذه الأساليب سوف تقع في الأيدي الخطأ. وما يُراد استخدامه كأداة لمكافحة الجريمة والمساعدة في تحقيق العدالة، سيصبح أداة للجريمة نفسها في يوم من الأيام.
ما هي أفكارك حول تسرب Debug SBP؟ هل تشعر أن "المفاتيح الذهبية" مثل هذه يجب أن تكون موجودة؟ اسمحوا لنا أن نعرف في التعليقات أدناه!