هل تحتوي Java على تجاوزات في المخزن المؤقت؟

Question

هل تحتوي Java على تجاوزات في المخزن المؤقت؟إذا كانت الإجابة بنعم هل يمكنك أن تعطيني السيناريوهات؟

Answer 1

نظرًا لأن Java Strings تعتمد على مصفوفات char وتقوم Java تلقائيًا بالتحقق من حدود المصفوفة، فإن تجاوزات المخزن المؤقت تكون ممكنة فقط في سيناريوهات غير عادية:

1. إذا قمت بالاتصال بالرمز الأصلي عبر JNI
2. في JVM نفسه (مكتوب عادةً بلغة C++)
3. المترجم أو برنامج التحويل البرمجي JIT لا يعمل بشكل صحيح (فحص الحدود الإلزامية لرمز Java الثانوي)

Answer 2

واللغات المدارة مثل جافا و C # لا تملك هذه المشاكل، ولكن الأجهزة الظاهرية الخاصة (JVM / CLR / الخ) والتي في الواقع تشغيل التعليمات البرمجية يجوز.

Answer 3

لجميع المقاصد والأغراض، لا.

حدود فحص التي سوف تأكد من أن البيانات لا يمكن الوصول إليها من منطقة خارج مجموعة المخصصة. عندما يحاول المرء للوصول إلى المنطقة التي هي أبعد من حجم المصفوفة، وهو <وأ href = "http://java.sun.com/javase/6/docs/api/java/lang/ArrayIndexOutOfBoundsException.html" يختلط = " noreferrer "> سيتم طرح استثناء ArrayOutOfBounds.

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

Answer 4

إن تجاوز سعة المخزن المؤقت بالمعنى الدقيق للكلمة المتمثل في الكتابة فوق المكدس أو الكومة نفسها يتطلب إما:

1. خطأ في إطار العمل (كانت هذه الأخطاء موجودة في الماضي وربما تتكرر مرة أخرى)
2. استخدام JNI (لم تعد تستخدم التعليمات البرمجية المُدارة بشكل أساسي)

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

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

Answer 5

نعم و لا.لا، لأنه لا يمكنك حقًا إنشاء ثغرة أمنية في تجاوز سعة المخزن المؤقت عن طريق الخطأ لأنها نموذج ذاكرة مُدارة.ومع ذلك، قد تكون هناك ثغرات أمنية في تجاوز سعة المخزن المؤقت في JVM وJDK.راجع هذا الاستشارة الخاصة بـ Secunia:

http://secunia.com/advisories/25295

أو راجع هذه النصائح القديمة حول العديد من نقاط الضعف السابقة في JDK وJRE:

• الثغرات الأمنية الخاصة بالعدد الصحيح وتجاوز سعة المخزن المؤقت في بيئة تشغيل Java (JRE) أداة تفريغ JAR "unpack200" قد تؤدي إلى تصعيد الامتيازات https://download.Oracle.com/sunalerts/1020225.1.html

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

  صن يعترف مع الشكر ، "regenrecht" العمل مع iDefense VCP (http://labs.idefense.com/vcp/) وكريس إيفانز من جوجل ل استريابها انتباهنا إلى هذه المسائل.

• تم تحديد العديد من نقاط الضعف في Sun Java Development Kit (JDK) وJava Runtime Environment (JRE). https://security.gentoo.org/glsa/200705-23

  ثغرة أمنية غير محددة تتضمن "استخداما غير صحيح للنظام الطبقات" من قبل فريق الأمن فوجيتسو.الاضافه الي ذلك أبلغ كريس إيفانز من فريق أمان Google عن تجاوز عدد صحيح مما أدى إلى تجاوز سعة المخزن المؤقت في محلل ICC المستخدم مع JPG أو BMP الملفات ، واستدعاء open() غير صحيح إلى / dev / tty عند المعالجة بعض ملفات BMP.

Answer 6

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

Answer 7

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

Answer 8

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

وعلى سبيل المثال ما يلي ليست كافية للتحقق حدود:

/* !! WRONG !! */ 0 <= off && 0 <= len && off+len <= buff.length /* !! WRONG !! */

وIIRC، كان StringBuffer مرة واحدة في خلل من هذا القبيل، ولكن لم يكن هناك أي شيء للاهتمام يمكن أن تفعله معها.

Answer 9

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

Answer 10

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