Stagefright: الاستغلال الذي غيّر نظام Android

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

في Google I/O 2014، قدمت Google أول دفعة نحو نظام بيئي أكثر أمانًا وملاءمة للمؤسسات من خلال إطلاق برنامج أندرويد للعمل. اعتمد Android For Work أسلوب الملف الشخصي المزدوج لتلبية احتياجات المؤسسات، حيث يمكن لمسؤولي تكنولوجيا المعلومات إنشاء ملف تعريف ملفات تعريف مستخدمين مميزة للموظفين - يركز أحدهما على العمل، ويترك الملفات الشخصية الأخرى شخصية للموظفين يستخدم. ومن خلال استخدام التشفير المعتمد على الأجهزة والسياسات التي يديرها المسؤول، ظلت بيانات العمل والبيانات الشخصية متميزة وآمنة. بعد ذلك، حظي Android For Work بمزيد من الاهتمام في الأشهر اللاحقة، مع التركيز بشكل كبير على أمان الجهاز ضد البرامج الضارة. جوجل خططت أيضا ل

تمكين تشفير الجهاز بالكامل لجميع الأجهزة التي كان من المقرر إصدارها مع Android Lollipop خارج الصندوق، ولكن تم إلغاء ذلك بسبب مشكلات في الأداء مع جعل هذه الخطوة اختيارية لمصنعي المعدات الأصلية لتنفيذها.

إن الدفع نحو نظام Android آمن ليس من عمل Google بالكامل، حيث لعبت Samsung دورًا مهمًا إلى حد ما في هذا من خلالها مساهمات KNOX في AOSP، والذي في نهاية المطاف تعزيز Android For Work. ومع ذلك، تشير الثغرات الأمنية ونقاط الضعف الأخيرة في Android إلى مهمة شاقة عندما يتعلق الأمر بشعبية اعتماد المؤسسات. ومن الأمثلة على ذلك ثغرة Stagefright الأخيرة.

محتويات:

• ما هو Stagefright؟
• ما مدى خطورة Stagefright؟
• ما الذي يجعل Stagefright مختلفًا عن "نقاط الضعف الهائلة" الأخرى؟
• معضلة التحديث
• أندرويد، ما بعد رعب المسرح
• الملاحظات الختامية

ما هو Stagefright؟

بعبارات بسيطة، يعد Stagefright بمثابة استغلال يستخدم مكتبة التعليمات البرمجية لتشغيل الوسائط في Android والتي تسمى libstageefright. يتم استخدام محرك libstagefright لتنفيذ التعليمات البرمجية التي يتم تلقيها في شكل فيديو ضار عبر رسائل الوسائط المتعددة، وبالتالي لا يتطلب الأمر سوى رقم الهاتف المحمول للضحية لتنفيذ هجوم ناجح.

لقد تواصلنا مع خبيرنا الداخلي، ومطور XDA المعترف به، ومسؤول المطورين pulser_g2 لتقديم شرح أكثر تفصيلا.

"بينما أكتب هذا، كان من المقرر شرح استغلال [Stagefright] في BlackHat [وصلة]، على الرغم من عدم توفر شرائح أو تفاصيل ورقة بيضاء حتى الآن.

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

هناك عدد من الأخطاء المختلفة التي تشكل Stagefright، ولها CVE الخاصة بها [نقاط الضعف والتعرضات الشائعة] أرقام للتتبع:

• CVE-2015-1538
• CVE-2015-1539
• CVE-2015-3824
• CVE-2015-3826
• CVE-2015-3827
• CVE-2015-3828
• CVE-2015-3829

لسوء الحظ، لا ترتبط التصحيحات المتوفرة مباشرةً بكل مكافحة التطرف العنيف (كما ينبغي)، لذلك سيكون شرح ذلك أمرًا فوضويًا بعض الشيء.

1. [CVE-2015-1538]

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

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

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

(المرجع: أومنيروم جيريت)

2. [CVE-2015-1539]

يجب أن يكون أقصر "حجم" ممكن للبيانات الوصفية 6 بايت، نظرًا لكونها سلسلة UTF-16. يأخذ الكود حجم القيمة الصحيحة، ويطرح منه 6. إذا كانت هذه القيمة أقل من 6، فإن عملية الطرح سوف "تتدفق" وتلتف، وينتهي بنا الأمر بعدد كبير جدًا. تخيل لو كان بإمكانك العد فقط من 0 إلى 65535، على سبيل المثال. إذا أخذت الرقم 4 وطرحت 6، فلن تتمكن من النزول إلى ما دون الصفر. لذلك عليك العودة إلى 65535 والعد من هناك. وهذا ما يحدث هنا!

إذا تم استلام طول أقل من 6، فقد يؤدي ذلك إلى فك تشفير الإطارات بشكل غير صحيح، نظرًا لأن تستخدم عملية byteswap المتغير len16، الذي يتم الحصول على قيمته من عملية حسابية تبدأ بـ (الحجم-6). قد يتسبب هذا في حدوث عملية تبديل أكبر بكثير مما هو مقصود، مما قد يؤدي إلى تغيير القيم في بيانات الإطار بطريقة غير متوقعة.

(المرجع: أومنيروم جيريت)

3. [CVE-2015-3824]

كبيرة! هذا واحد مقرف. هناك العكس تمامًا لهذه المشكلة الأخيرة - تجاوز عدد صحيح، حيث يمكن أن يصبح العدد الصحيح "كبيرًا جدًا". إذا وصلت إلى 65535 (على سبيل المثال) ولم تتمكن من العد أعلى من ذلك، فسوف تتدحرج وتنتقل إلى 0 بعد ذلك!

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

(المرجع: أومنيروم جيريت)

4. [CVE-2015-3826]

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

(المرجع: أومنيروم جيريت)

5. [CVE-2015-3827]

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

(المرجع: أومنيروم جيريت)

هناك أيضًا بعض الإصلاحات (المحتملة) ذات الصلة التي يبدو أنها وصلت إلى [Android] 5.1 أيضًا.

(المرجع: أومنيروم جيريت)

يؤدي هذا إلى إضافة عمليات فحص لإيقاف المشكلات المتعلقة بإصلاح الأمان السابق لإضافة عمليات فحص الحدود، والتي يمكن تجاوزها في حد ذاتها. في لغة C، يتم تخزين الأرقام التي يمكن تمثيلها كـ int مُوقع كـ int مُوقع. وإلا فإنها تبقى دون تغيير أثناء العمليات. في عمليات التحقق هذه، كان من الممكن أن تكون بعض الأعداد الصحيحة موقعة (بدلاً من غير موقعة)، مما قد يقلل من قيمتها القصوى لاحقًا، ويسمح بحدوث تجاوز.

(المرجع: أومنيروم جيريت)

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

(المرجع: أومنيروم جيريت)

وأخيرا، تجاوز عدد صحيح آخر. كما كان من قبل، فهو على وشك أن يتم استخدامه في مكان آخر، ومن الممكن أن يفيض.

(المرجع: أومنيروم جيريت)"

ما مدى خطورة Stagefright؟

وفقا ل مشاركة مدونة تم نشره من قبل شركة الأبحاث الأم، Zimperium Research Labs، ومن المحتمل أن يكشف استغلال Stagefright 95% من أجهزة Android - ما يقرب من 950 مليونًا - تعاني من هذه الثغرة الأمنية لأنها تؤثر على الأجهزة التي تعمل بنظام Android 2.2 و أعلى. ومما زاد الطين بلة، أن الأجهزة التي تسبق إصدار Jelly Bean 4.3 هي في "أسوأ المخاطر" لأنها لا تحتوي على وسائل تخفيف كافية ضد هذا الاستغلال.

فيما يتعلق بالضرر الذي يمكن أن يسببه Stagefright، لاحظpulser_g2:

[blockquote Author="pulser_g2"]"في حد ذاته، فإن Stagefright يمنح حق الوصول إلى مستخدم النظام على الهاتف. سيتعين عليك تجاوز ASLR (التوزيع العشوائي لتخطيط مساحة العنوان) لإساءة استخدامه فعليًا. وما إذا كان قد تم تحقيق ذلك أم لا، فهو غير معروف في الوقت الحالي. يتيح هذا الاستغلال إمكانية تشغيل "تعليمات برمجية عشوائية" على جهازك كمستخدم للنظام أو للوسائط. هؤلاء لديهم إمكانية الوصول إلى الصوت والكاميرا على الجهاز، ويعتبر مستخدم النظام مكانًا رائعًا لبدء استغلال الجذر منه. هل تتذكر جميع عمليات استغلال الجذر المذهلة التي استخدمتها لتجذير هاتفك؟

من المحتمل أن يتم استخدامها بصمت للحصول على الجذر على جهازك! من لديه الجذر يملك الهاتف. سيتعين عليهم تجاوز SELinux، لكن TowelRoot تمكنت من ذلك، كما تمكنت PingPong من ذلك أيضًا. بمجرد حصولهم على الجذر، يصبح كل شيء على هاتفك مفتوحًا لهم. الرسائل والمفاتيح وما إلى ذلك."[/blockquote]عند الحديث عن أسوأ السيناريوهات، لا يلزم سوى رسالة الوسائط المتعددة (MMS) لتوصيل التعليمات البرمجية وتشغيل هذا الاستغلال. المستخدم لا تحتاج حتى لفتح الرسالة نظرًا لأن الكثير من تطبيقات المراسلة تقوم بمعالجة رسائل الوسائط المتعددة مسبقًا قبل أن يتفاعل المستخدم معها. ويختلف هذا عن هجمات التصيد الاحتيالي حيث يمكن أن يكون المستخدم غافلاً تمامًا عن الهجوم الناجح، مما يعرض جميع البيانات الحالية والمستقبلية الموجودة في الهاتف للخطر.

ما الذي يجعل Stagefright مختلفًا عن "نقاط الضعف الهائلة" الأخرى؟

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

تتطلب عمليات الاستغلال الأقدم مثل Android Installer Hijacking وFakeID بالإضافة إلى عمليات استغلال الجذر مثل TowelRoot وPingPong تفاعل المستخدم في مرحلة ما حتى يتم تنفيذها. في حين أنها لا تزال "مآثر" في حقيقة أن الكثير من الضرر يمكن أن ينشأ إذا تم استخدامها بشكل ضار، تظل الحقيقة أن Stagefright من الناحية النظرية، لا يلزم سوى رقم هاتف الضحية لتحويل هاتفه إلى حصان طروادة، وبالتالي فقد حظي باهتمام كبير في الآونة الأخيرة أيام.

ومع ذلك، فإن Android ليس تحت رحمة هذا الاستغلال تمامًا. تناول المهندس الرئيسي لأمن Android، Adrian Ludwig، بعض المخاوف في ملف مشاركة جوجل+:

[blockquote Author="Adrian Ludwig"]"هناك افتراض شائع وخاطئ بأن أي خطأ برمجي يمكن أن يتحول إلى استغلال أمني. في الواقع، معظم الأخطاء غير قابلة للاستغلال، وهناك العديد من الأشياء التي قام بها Android لتحسين هذه الاحتمالات...

قائمة ببعض تلك التقنيات التي تم تقديمها منذ إصدار Ice Cream Sandwich (Android 4.0). هنا. وأشهرها يسمى التوزيع العشوائي لتخطيط مساحة العنوان (ASLR)، والذي اكتمل بالكامل في Android 4.1 مع دعم PIE (الملفات التنفيذية المستقلة عن الموضع) وهو الآن موجود على أكثر من 85% من Android الأجهزة. تجعل هذه التقنية من الصعب على المهاجم تخمين موقع التعليمات البرمجية، وهو أمر مطلوب لبناء استغلال ناجح...

لم نتوقف عند ASLR، بل أضفنا أيضًا NX وFortifySource وRead-Only-Relocations وStack Canaries والمزيد."[/blockquote]

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

معضلة التحديث

عند الحديث عن التحديثات، من الجيد أن نرى أن مصنعي المعدات الأصلية يتحملون مسؤولية أمان المستخدمين، كما وعد الكثيرون بذلك تحسين عملية التحديث خصيصًا لدمج الإصلاحات والتصحيحات الأمنية لبرامج استغلال مثل Stagefright.

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

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

لمرة واحدة، تزود شركات الاتصالات أيضًا بالتحديثات. سبرينت لديه أصدر بيانا أن بعض الأجهزة قد تلقت بالفعل تصحيح Stagefright، مع جدولة المزيد من الأجهزة للتحديث. وقد حذت AT&T حذوها أيضًا عن طريق إصدار التصحيح لبعض الأجهزة. أصدرت Verizon أيضًا تصحيحات، على الرغم من أن هذا طرح بطيء يعطي الأولوية للهواتف الذكية المتطورة مثل Galaxy S6 Edge وNote 4. تلقى T-Mobile Note 4 تحديث تصحيح Stagefright أيضًا.

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

باعتبارك مستخدمًا قويًا لـ XDA، يمكنك أيضًا ذلك قم بإجراء تعديلات على دعامة البناء الخاصة بك لتعطيل Stagefright. هذه ليست طريقة كاملة ومؤكدة لإنقاذ نفسك من Stagefright، ولكن يمكنك استغلال فرصك لتقليل احتمالية نجاح الهجوم إذا كنت عالقًا في إصدار Android قديم. هناك أيضًا حلول ROM مخصصة، حيث يقوم معظمها بمزامنة المصادر مع AOSP على أساس منتظم، وبالتالي، سيتم دمج إصلاحات Stagefright. إذا كنت تقوم بتشغيل rom يعتمد على AOSP، فمن المستحسن بشدة أن تقوم بالتحديث إلى إصدار أحدث من ROM الذي يتضمن تصحيحات Stagefright. يمكنك استخدام هذا التطبيق للتحقق مما إذا كان برنامج التشغيل اليومي الحالي الخاص بك متأثرًا بـ Stagefright.

أندرويد، ما بعد رعب المسرح

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

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

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

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

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

الملاحظات الختامية

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

هل هاتفك عرضة لـ Stagefright؟ هل تعتقد أن هاتفك سيحصل على تصحيح Stagefright؟ اسمحوا لنا أن نعرف في التعليقات أدناه!