أوراكل يتعهد أمن جافا أفضل

في ضوء الثغرات الأمنية الحديثة الموجودة في جافا والمخاوف المستمرة بشأن الأمن العام للتكنولوجيا ، وعدت أوراكل - مرة أخرى - بأنها ستعمل على حل المشكلات.

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

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

ماذا عن الصندوق؟

وقال HD Moore ، كبير الباحثين في Rapid7 ومُنشئ إطار اختبار تغلغل Metasploit ، "في مجمل الأمر ، يعد هذا أمرًا جيدًا لجافا ، لكن هذه التغييرات لا تحل المشكلة الأساسية في صندوق حماية Java نفسه". البريد الإلكتروني ل SecurityWatch.

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

وقال مور: "إلى أن تنفذ أوراكل وضع رمل على مستوى العملية ، مثل تلك المستخدمة من قبل Adobe Reader و Google Chrome ، فإن التطبيق الخبيث الذي يحمل توقيعًا صالحًا لا يزال بإمكانه إساءة استخدام عيوب أمان JRE للهروب من صندوق الحماية وتهديد النظام".

التغييرات حتى الآن

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

وقال مور "هذا شيء جيد للأمن".

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

قريباً...

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

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

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

جدول جديد للتحديثات

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

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