التفاصيل الفنية لتحطم فايرفوكس التمديد الأخيرة

عن المؤلف. إريك ريسكورلا - المدير الفني لمجموعة فايرفوكس في موزيلا

في الآونة الأخيرة ، وقع حادث في Firefox عندما توقفت معظم الإضافات (الامتدادات ، الإضافات) عن العمل. هذا بسبب خطأ من جانبنا: لم نلاحظ أن إحدى الشهادات ، التي تُستخدم للتوقيع على الوظائف الإضافية ، قد انتهت صلاحيتها ، مما أدى إلى انقطاع الغالبية العظمى منهم. الآن وقد أصلحنا المشكلة وتمت استعادة معظم الإضافات ، أود أن أقول بالتفصيل ما حدث ولماذا وكيف تم إصلاحه.

للرجوع اليها: التمديدات وتوقيعها

على الرغم من أن العديد من المستخدمين يستخدمون Firefox كما هو خارج الصندوق ، إلا أن المتصفح يدعم أيضًا آلية امتداد قوية. يضيفون ميزات خارجية إلى Firefox تعمل على توسيع الميزات التي نقدمها افتراضيًا. يوجد حاليًا أكثر من 15000 وظيفة إضافية لمتصفح فايرفوكس: من حظر الإعلانات إلى إدارة مئات علامات التبويب .

يتطلب Firefox توقيع جميع الوظائف الإضافية المثبتة رقميًا . يهدف هذا المتطلب إلى حماية المستخدمين من الإضافات الضارة عن طريق طلب الحد الأدنى من معايير التحقق من قبل موظفي Mozilla. قبل أن نقدم هذا المطلب في عام 2015 ، واجهنا مشاكل خطيرة مع الامتدادات الخبيثة.

يعمل التوقيع من خلال "شهادة الجذر" المثبتة مسبقًا من Firefox. يتم تخزينه دون اتصال في وحدة أمان الأجهزة (HSM) . كل بضع سنوات ، يتم استخدامه للتوقيع على "شهادة وسيطة" جديدة ، يتم تخزينها عبر الإنترنت ويتم استخدامها في عملية التوقيع. عندما يتم تقديم الامتداد للتوقيع ، نقوم بإنشاء "شهادة كيان نهائي" جديدة مؤقتة وتوقيعها بشهادة وسيطة. ثم يتم استخدام شهادة الوجهة لتوقيع الامتداد. بصريا ، يبدو مثل هذا:



يرجى ملاحظة أن كل شهادة لها "موضوع" (تنتمي إليه الشهادة) و "ناشر" (موقّع). في حالة شهادة الجذر ، هذه شهادة واحدة ، ولكن بالنسبة للشهادات الأخرى ، فإن الناشر هو الذي قام بالتوقيع عليها.

النقطة المهمة هنا هي أن كل وظيفة إضافية موقعة بشهادتها الخاصة بالكائن النهائي ، ولكن جميع الإضافات تقريبًا لها نفس الشهادة المتوسطة (تم توقيع العديد من الإضافات القديمة جدًا بواسطة رابط وسيط آخر). هذا هو المكان الذي نشأت فيه المشكلة: لكل شهادة تاريخ انتهاء ثابت. قبل هذه النافذة أو بعدها ، لن يتم قبول الشهادة ، ولا يمكن تحميل الامتداد الموقع بواسطة هذه الشهادة على Firefox. لسوء الحظ ، انتهت صلاحية الشهادة الوسيطة التي استخدمناها في 4 مايو بعد الساعة 1:00 بالتوقيت العالمي ، وعلى الفور لم يتم التحقق من كل وظيفة إضافية موقعة من هذه الشهادة ولم يمكن تحميلها إلى Firefox.

على الرغم من انتهاء صلاحية جميع الإضافات في حوالي الساعة الواحدة صباحًا ، إلا أن العواقب لم يتم الشعور بها على الفور. والسبب هو أن Firefox لا يتحقق باستمرار من الإضافات للتأكد من صحتها. يتم فحصها كل 24 ساعة تقريبًا ، ويختلف وقت التحقق لكل مستخدم. نتيجة لذلك ، واجه بعض الأشخاص مشاكل على الفور ، بعضها في وقت لاحق. لقد تعلمنا في Mozilla لأول مرة حول المشكلة في حوالي الساعة 6 مساءً بتوقيت المحيط الهادي يوم الجمعة 3 مايو ، وقمنا على الفور بتشكيل فريق لتصحيح الموقف.

الحد من الضرر

بمجرد فهمنا لما واجهناه ، اتخذنا عدة خطوات لتجنب تدهور الوضع.

أولاً ، أوقفنا التوقيع على إضافات جديدة. في تلك اللحظة كان الأمر معقولًا ، لأن التوقيع وضع شهادة غير صالحة. إذا نظرنا إلى الوراء ، يبدو أنه كان من الممكن ترك هذه الوظيفة ، لكن اتضح أنها تتعارض أيضًا مع تليين "البرامج الثابتة للتاريخ الصعب" ، والتي سنناقشها أدناه (على الرغم من أننا لم نستخدمها في النهاية). لذلك ، من الجيد أننا حافظنا على هذا الخيار. لذلك ، يتم الآن تأخير توقيع إضافات جديدة.

ثانياً ، أصدرنا على الفور حلاً سريعًا يمنع إعادة التحقق من توقيعات الإضافات. كانت الفكرة لحماية المستخدمين الذين لم يتم إعادة اختبارهم بعد. لقد فعلنا هذا قبل أن يكون لدينا أي إصلاح آخر ، وتتم إزالته الآن عندما يتوفر الإصلاح.

العمل الموازي

من الناحية النظرية ، يبدو حل هذه المشكلة بسيطًا: قم بإصدار شهادة جديدة صالحة وإعادة إصدار كل إضافة مع هذه الشهادة. لسوء الحظ ، قررنا بسرعة أن هذا لن ينجح لعدة أسباب:

1. هناك الكثير من الإضافات (أكثر من 15000) ، ولم يتم تحسين الخدمة للتوقيع الشامل ، لذا فإن إعادة تسجيل كل وظيفة إضافية ستستغرق وقتًا أكثر مما أردنا.
   
2. بعد توقيع الوظائف الإضافية ، سيحتاج المستخدمون إلى الحصول على وظيفة إضافية جديدة. يتم استضافة بعضها على خوادم Mozilla ، وسيقوم Firefox بتحديثها في غضون 24 ساعة ، ولكن سيتعين على المستخدمين تحديث أي وظائف إضافية مثبتة يدويًا من مصادر أخرى ، وهذا أمر غير مريح للغاية.

بدلاً من ذلك ، ركزنا على محاولة تطوير إصلاح من شأنه إصلاح الموقف مع تدخل يدوي قليل أو بدون تدخل من المستخدمين.

بعد النظر في عدد من النهج ، اتفقنا بسرعة على استراتيجيتين رئيسيتين قمنا بهما بالتوازي:

1. تصحيح Firefox لتغيير التاريخ المستخدم للتحقق من الشهادة. في هذه الحالة ، ستعمل الوظائف الإضافية الحالية مرة أخرى بطريقة سحرية ، ولكن ستكون هناك حاجة إلى تسليم إصدار جديد من Firefox.
   
2. قم بإنشاء شهادة صالحة جديدة وإقناع Firefox بطريقة ما بقبولها بدلاً من الشهادة الحالية منتهية الصلاحية.

لم نكن متأكدين مما سيكون عليه الأمر بالضبط ، لذلك قررنا تنفيذ العمل بالتوازي مع تنفيذ الأول ، والذي يبدو وكأنه حل عملي. في نهاية اليوم ، أكملنا نشر الإصلاح الثاني - شهادة جديدة ، والتي سأصفها بمزيد من التفاصيل.

شهادة استبدال

كما ذكر أعلاه ، كان هناك خطوتان رئيسيتان لاتباعهما:

1. إنشاء شهادة جديدة صالحة.
   
2. بعد تثبيته في فايرفوكس.

لفهم سبب نجاح ذلك ، تحتاج إلى معرفة المزيد حول كيفية قيام Firefox بالتحقق من الوظائف الإضافية. تأتي الوظيفة الإضافية نفسها في شكل حزمة من الملفات ، والتي تتضمن سلسلة الشهادة المستخدمة للتوقيع عليها. نتيجة لذلك ، يتم فحص الملحق بشكل مستقل إذا كانت شهادة الجذر معروفة ، والتي تم تكوينها في Firefox أثناء الإنشاء. ومع ذلك ، كما قلت ، تم كسر الشهادة الوسيطة ، وبالتالي فإن الوظيفة الإضافية لم تكن قابلة للتحقق منها حقًا.

لكن اتضح أنه عندما يحاول Firefox التحقق من الامتداد ، فإنه لا يقتصر على استخدام الشهادات فقط في الملحق نفسه. بدلاً من ذلك ، يحاول إنشاء سلسلة شهادات صالحة ، بدءًا من شهادة نقطة النهاية ومتابعة الدليل الجذر. الخوارزمية معقدة ، ولكن على مستوى عالٍ ، تبدأ بشهادة الكائن النهائي ، ثم تعثر على شهادة يكون موضوعها مساوياً لناشر شهادة الكائن النهائي (أي شهادة متوسطة). في الحالة البسيطة ، يعد هذا رابطًا وسيطًا يأتي مع الوظيفة الإضافية ، ولكن يمكن أن يكون أي شهادة يعرفها المستعرض. إذا استطعنا إضافة شهادة جديدة صالحة عن بُعد ، فسيحاول Firefox أيضًا إنشاء مثل هذه السلسلة. يوضح الشكل أدناه الموقف قبل وبعد تثبيت شهادة جديدة.



بعد تثبيت شهادة جديدة ، لدى Firefox خياران للتحقق من سلسلة الشهادة: استخدام شهادة غير صالحة قديمة (لن تنجح) أو استخدام شهادة صالحة جديدة (ستنجح). إحدى الميزات المهمة هنا هي أن الشهادة الجديدة لها نفس اسم الموضوع والمفتاح العمومي مثل الشهادة القديمة ، وبالتالي فإن توقيعها على شهادة الكائن النهائي صالح. لحسن الحظ ، فإن Firefox ذكي بما فيه الكفاية لتجربة كلتا الطريقتين حتى يجد طريقة فعالة ، وبالتالي يصبح الامتداد صالحًا مرة أخرى. يرجى ملاحظة أن هذا هو نفس المنطق الذي نستخدمه للتحقق من شهادات TLS ، لذلك هذا رمز مفهومة جيدًا تمكنا من استخدامه (سوف يفهم القراء المألوفون بـ WebPKI أن الشهادات التبادلية تعمل بهذه الطريقة).

إن الشيء العظيم في هذا الإصلاح هو أنه لا يتطلب تغيير أي ملحقات موجودة. عندما نقوم بتثبيت الشهادة الجديدة في Firefox ، فإن الامتدادات ذات الشهادات القديمة ستجتاز الاختبار. إن حيلة تسليم شهادة جديدة في Firefox هي القيام بذلك تلقائيًا عن بُعد ، ثم جعل Firefox يتأكد من جميع الإضافات التي قد تكون معطلة.

نورماندي ونظام البحث

ومن المفارقات أن حل المشكلة كان نوعًا خاصًا من الامتدادات يسمى نظام الإضافة (SAO). لدراسات الجمهور (الدراسات) ، قمنا مسبقًا بتطوير نظام يسمى Normandy ، والذي يمكنه توصيل SAO لمستخدمي Firefox. يتم تنفيذ هذه SAOs تلقائيا في متصفح المستخدم. على الرغم من أنها شائعة الاستخدام للتجريب ، إلا أنها تتمتع أيضًا بوصول واسع إلى واجهات برمجة التطبيقات الداخلية في Firefox. في هذه الحالة ، من المهم أن يتمكنوا من إضافة شهادات جديدة إلى قاعدة بيانات الشهادة التي يستخدمها Firefox للتحقق من الإضافات (ملاحظة فنية: لا نضيف الشهادة بأية امتيازات خاصة ؛ بل تحصل على امتيازاتها عن طريق التوقيع باستخدام شهادة الجذر. نحن فقط نضيفها إلى تجمع الشهادات الذي يمكن أن يستخدمه Firefox ، لذلك لا نضيف شهادة مميزة جديدة في Firefox).

لذلك ، الحل هنا هو إنشاء SAO يقوم بأمرين:

1. يثبت الشهادة الجديدة التي قطعناها على أنفسنا.
   
2. يؤدي المستعرض إلى إعادة التحقق من كل وظيفة إضافية لتنشيط تلك التي قطعت الاتصال.

لكن انتظر ، أنت تقول. لا تعمل الوظائف الإضافية ، فكيف نجعل SAO يعمل؟ حسنًا ، سنوقعها بشهادة جديدة!

وضع كل ذلك معا ... ولماذا وقتا طويلا؟

إذن لدينا الآن خطة: لإصدار شهادة جديدة لاستبدال الشهادة القديمة ، وإنشاء وظيفة إضافية للنظام لتثبيتها في Firefox ، ونشرها على نورماندي. بدأنا العمل في حوالي الساعة 6:00 مساءً بتوقيت المحيط الهادئ يوم الجمعة 3 مايو ، وأرسلنا التصحيح إلى Normandy في حوالي الساعة 2:44 صباحًا ، أي أقل من 9 ساعات ، ثم استغرق الأمر من 6 إلى 12 ساعة أخرى قبل أن يستقبله معظم المستخدمين. إنها في الواقع بداية جيدة للغاية ، لكنني رأيت على Twitter سلسلة من الأسئلة ، لماذا لم نتمكن من القيام بذلك بشكل أسرع. هناك عدد من الخطوات التي تستغرق وقتًا طويلاً.

أولاً ، لقد استغرق الأمر بعض الوقت لإصدار شهادة وسيطة جديدة. كما ذكرت أعلاه ، توجد شهادة الجذر في وحدة أمان الأجهزة ، والتي يتم تخزينها في وضع عدم الاتصال. هذه ممارسة أمان جيدة ، نظرًا لأنك نادرًا ما تستخدم شهادة الجذر ، وبالتالي تريد الاحتفاظ بها آمنة. لكن من الواضح أن هذا غير مريح إلى حد ما عندما تحتاج إلى إصدار شهادة جديدة في حالات الطوارئ. في أي حال ، كان على أحد مهندسينا الذهاب إلى مكان آمن حيث يتم تخزين HSM. ثم كانت هناك عدة بدايات خاطئة ، عندما تعذر علينا إصدار الشهادة الصحيحة ، وكانت كل محاولة تستحق اختبارًا لمدة ساعة أو ساعتين ، قبل أن نعرف بالضبط ما يجب القيام به.

ثانيا ، تطوير النظام يستغرق بعض الوقت. من الناحية النظرية ، كل شيء بسيط للغاية ، ولكن حتى البرامج البسيطة تتطلب بعض الحذر ، وأردنا حقًا التأكد من أننا لم نزيد الموقف سوءًا. وقبل إرسال SAO ، كان من الضروري اختباره ، وهذا يستغرق وقتًا ، لا سيما بالنظر إلى أنه يحتاج إلى توقيع. ولكن تم تعطيل نظام التوقيع ، لذلك كان علينا البحث عن الحلول.

أخيرًا ، بمجرد استعداد SAO للشحن ، استغرق الأمر بعض الوقت للنشر. يتحقق عملاء Firefox من تحديثات Normandy كل 6 ساعات ، وبالطبع ، فإن العديد من العملاء غير متصلين ، لذلك لم يتم توزيع التحديث على الفور على جميع مستخدمي Firefox. ومع ذلك ، في الوقت الحالي ، تلقى معظمهم تحديثًا و / أو إصدارًا جديدًا ، والذي أصدرناه لاحقًا.

الخطوات الأخيرة

على الرغم من أن الملحق الإضافي للنظام ، الذي تم نشره من خلال نظام الدراسات ، يجب أن يصحح الموقف بالنسبة لمعظم المستخدمين ، إلا أنه لم يصل إلى الجميع. على وجه الخصوص ، تتطلب عدة أنواع من المستخدمين طريقة مختلفة:

• المستخدمين الذين قاموا بتعطيل القياس عن بعد أو البحث.
  
• مستخدمو Firefox لنظام Android (Fennec) ، حيث لا يوجد لدينا بحث.
  
• مستخدمو الإصدارات اللاحقة من Firefox ESR الذين لا يشتركون في تقارير القياس عن بُعد.
  
• المستخدمون الذين يقفون خلف وكلاء HTTPS MiTM ، لأن أنظمة التثبيت الإضافية الخاصة بنا تفرض مفاتيح لهذه الاتصالات ، والتي تتعارض مع الوكيل.
  
• مستخدمي بنيات فايرفوكس القديمة جدًا ، والتي لا يمكن الوصول إليها من خلال نظام الدراسات.

لا يمكننا فعل أي شيء مع المجموعة الأخيرة - سيتعين عليهم الترقية إلى الإصدار الجديد من Firefox ، لأن الإصدارات القديمة عادةً ما تكون بها ثغرات أمنية خطيرة غير مسبوقة. نحن نعلم أن بعض الأشخاص ظلوا في الإصدارات القديمة من Firefox لأنهم أرادوا تشغيل ملحقات النمط القديم ، ولكن الكثير منهم يعملون الآن مع إصدارات أحدث من Firefox. بالنسبة للمجموعات الأخرى ، قمنا بتطوير تصحيح لبرنامج Firefox يقوم بتثبيت شهادة جديدة بعد الترقية. تم إصدارها أيضًا كنسخة جديدة من Firefox "منقطة" ، لذلك يجب على الناس الحصول عليها - وربما استلموها بالفعل - من خلال قناة التحديث العادية. إذا كان لديك بنية أساسية ، فعليك انتظار التحديث من جهة الصيانة.

نحن نعترف بأن لا شيء من هذا الكمال. على وجه الخصوص ، في بعض الحالات ، يفقد المستخدمون البيانات المرتبطة بالوظائف الإضافية (على سبيل المثال ، ملحق مثل "حاويات لها حسابات متعددة" ).

لم نتمكن من تطوير تصحيح يتجنب هذا التأثير الجانبي ، لكننا نعتقد أنه على المدى القصير هذا هو الأسلوب الأفضل لمعظم المستخدمين. في المدى البعيد ، سوف نبحث عن أفضل الأساليب المعمارية لحل مثل هذه المشكلات.

الدروس

أولاً ، أود أن أقول إن الفريق قام بعمل رائع هنا: لقد طوروا وأرسلوا الإصلاح في أقل من 12 ساعة من وقت التقرير الأولي. بصفتي الشخص الذي حضر الاجتماع الذي حدث فيه هذا ، يمكنني أن أقول إن الناس عملوا بجد بشكل لا يصدق في موقف صعب وأنه لم يضيع سوى القليل من الوقت.

بالنظر إلى هذا ، من الواضح أن هذا ليس موقفًا مثاليًا ، ولا ينبغي أن يحدث هذا على الإطلاق. من الواضح أننا نحتاج إلى ضبط عملياتنا لتقليل احتمالية حدوث هذه الحوادث وما شابهها ولتسهيل تصحيحها.

في الأسبوع القادم ، سنقوم بإجراء استخلاص معلومات رسمي ونشر قائمة بالتغييرات التي نعتزم إجراؤها ، ولكن الآن ، فيما يلي أفكاري الأولية حول هذا الموضوع. الأهم من ذلك ، ينبغي أن يكون لدينا طريقة أفضل بكثير لمراقبة حالة جميع الأنظمة الموجودة في Firefox والتي تعتبر قنبلة موقوتة محتملة. تحتاج إلى التأكد من أن أيا منهم لا يتوقف فجأة عن العمل. ما زلنا نعمل على التفاصيل هنا ، ولكن على الأقل نحتاج إلى إجراء جرد لمثل هذه الأنظمة.

ثانياً ، نحتاج إلى آلية لتحديث المستخدمين بسرعة ، حتى عندما لا يعمل أي شيء آخر - خاصةً عندما يحدث ذلك. من الرائع أن نكون قادرين على استخدام نظام الدراسات ، لكنه لم يكن الأداة المثالية التي وضعناها موضع التنفيذ ، وكان لها بعض الآثار الجانبية غير المرغوب فيها. على وجه الخصوص ، نعلم أن العديد من المستخدمين لديهم تحديثات تلقائية قيد التشغيل ، لكنهم يفضلون عدم المشاركة في البحث ، وهذا هو التفضيل المعقول (كي لا أقول شيئًا ، لقد قمت بإعداد المتصفح بهذه الطريقة!) ، ولكن في الوقت نفسه ، يجب أن نكون قادرين على الدفع تحديثات. بغض النظر عن الآليات التقنية الداخلية ، يجب أن يكون المستخدمون قادرين على تحديد التحديثات (بما في ذلك الإصلاحات) ، ولكن التخلي عن كل شيء آخر. بالإضافة إلى ذلك ، يجب أن تكون قناة التحديث أسرع. حتى يوم الاثنين ، لا يزال لدينا مستخدمين لم يلتقطوا الإصلاح أو الإصدار الجديد ، والذي من الواضح أنه غير مثالي. لقد عملنا بالفعل على هذه المشكلة ، لكن هذه الحادثة توضح مدى أهميتها.

أخيرًا ، سوف نلقي نظرة أكثر عمومية على بنية أمان الامتداد الخاصة بنا للتأكد من أنها توفر الأمان بشكل صحيح مع الحد الأدنى من مخاطر الفشل.

في الأسبوع القادم سننشر نتائج تحليل أكثر شمولاً لهذا الموقف.