क्या जावा में बफर ओवरफ्लो है?

Question

क्या जावा में बफर ओवरफ्लो है? यदि हाँ, तो आप मुझे परिदृश्य दे सकते हैं?

Comments

कुछ लाइब्रेरी फ़ंक्शंस (मूल कोड में लागू) को बग के लिए जाना जाता है। विशेष रूप से जावा 5 क्षेत्र में 2 डी में बहुत सारे कारनामे, ध्वनि या रंग प्रोफ़ाइल ज्ञात किए गए हैं।

— eckes

Answer 1

चूँकि जावा स्ट्रिंग्स चारपाई पर आधारित हैं और जावा स्वचालित रूप से सरणी सीमा की जाँच करता है, बफर ओवरफ्लो केवल असामान्य परिदृश्य में ही संभव है:

1. यदि आप JNI के माध्यम से मूल कोड कहते हैं
2. जेवीएम में ही (आमतौर पर C ++ में लिखा जाता है)
3. दुभाषिया या जेआईटी संकलक सही ढंग से काम नहीं करता है (जावा बायटेकोड अनिवार्य सीमा जाँच)

Answer 2

जावा और सी # जैसी प्रबंधित भाषाओं में ये समस्याएं नहीं हैं, लेकिन विशिष्ट आभासी मशीनें (जेवीएम / सीएलआर / आदि) जो वास्तव में कोड चलाते हैं।

Comments

असुरक्षित संदर्भ में C # बफर ओवरफ्लो हो सकता है। जावा एक भाषा के रूप में इसे पूरी तरह से मना करता है (आपको

— जेएनआई के

अच्छी बात। असुरक्षित सी # के साथ, आप स्पष्ट रूप से एक आराम से प्रबंधित दुनिया में सैंडबॉक्स नहीं करते हैं।

— ब्रायन रासमुसेन

ठीक है, और यहां तक ​​कि अगर आप कोई असुरक्षित नहीं लिखते हैं या कोई इंटरोप नहीं करते हैं, तो आप एक पुस्तकालय का उपयोग कर सकते हैं जो करता है। तो यह देखने के लिए कुछ है।

— बॉबीशाफ्टो

Answer 3

सभी इरादों और उद्देश्यों के लिए, नहीं।

जावा में सरणी सीमा की जाँच है जो यह जाँच करेगा कि आवंटित सरणी के बाहर के क्षेत्र से डेटा तक पहुँचा नहीं जा सकता है। जब कोई सरणी के आकार से परे क्षेत्र का उपयोग करने की कोशिश करता है, तो एक ArrayOutOfBoundsअपवाद फेंक दिया जाएगा।

यदि बफ़र-ओवररन है, तो यह संभवतः जावा वर्चुअल मशीन में एक बग से है, और यह मेरी जानकारी के लिए है, न कि इच्छित व्यवहार जो जावा लैंग्वेज स्पेसिफिकेशन्स में लिखा गया है और न ही जावा वर्चुअल मशीन स्पेसिफिकेशन्स में।

Answer 4

हां और ना। नहीं, इसमें आप वास्तव में गलत तरीके से अपने आप को एक बफर अतिप्रवाह भेद्यता के लिए नहीं खोल सकते क्योंकि यह एक प्रबंधित मेमोरी मॉडल है। हालांकि, JVM और JDK में बफर ओवरफ्लो कमजोरियां हो सकती हैं। देखिये यह सेक्यूनिया एडवाइजरी:

http://secunia.com/advisories/25295

या पिछले JDK और JRE भेद्यता पर इन पुरानी सलाह को देखें:

• जावा रनटाइम एनवायरनमेंट (JRE) में अनगर और बफर ओवरफ्लो वल्नरेबिलिटीज (JRE) "अनपैक 200" JAR अनपैकिंग यूटिलिटी मे लीड टू एस्कलेशन ऑफ़ प्रिविलेज्स https://download.oracle.com/sunalerts/10325.1.html

  "अनपैक 200" JAR अनपैकिंग यूटिलिटी का उपयोग करके एप्लेटिंग एप्लेट्स और जावा वेब स्टार्ट एप्लिकेशन के साथ जावा रनटाइम एनवायरनमेंट (JRE) में इंटर्जर और बफर ओवरफ्लो कमजोरियां एक अविश्वसनीय एपलेट या एप्लिकेशन को एस्केलेटर की अनुमति दे सकती हैं। उदाहरण के लिए, एक अविश्वसनीय एपलेट स्वयं को स्थानीय फ़ाइलों को पढ़ने और लिखने की अनुमति दे सकता है या उन स्थानीय अनुप्रयोगों को निष्पादित कर सकता है जो उपयोगकर्ता के लिए पहुंच से बाहर हैं।

  सूर्य इन मुद्दों को हमारे ध्यान में लाने के लिए iDefense VCP ( http://labs.idefense.com/vcp/ ) और क्रिस इवांस के साथ काम करने के लिए धन्यवाद, "रेगेनचैट" के साथ स्वीकार करता है ।

• सन जावा डेवलपमेंट किट (JDK) और जावा रनटाइम एनवायरनमेंट (JRE) में कई कमजोरियों की पहचान की गई है। https://security.gentoo.org/glsa/200705-23

  फुजित्सु सुरक्षा दल द्वारा एक अनिर्दिष्ट भेद्यता को "सिस्टम कक्षाओं का गलत उपयोग" बताया गया था। इसके अतिरिक्त, Google सुरक्षा टीम के क्रिस इवांस ने एक पूर्णांक ओवरफ़्लो की सूचना दी जिसके परिणामस्वरूप JC या BMP फ़ाइलों के साथ ICC पार्सर में बफर ओवरफ़्लो हुआ, और कुछ BMP फ़ाइलों को संसाधित करते समय एक गलत खुला () कॉल / / dev / tty।

Answer 5

स्टैक या हीप को ओवरराइट करने के सख्त अर्थ में एक बफर ओवरफ्लो या तो आवश्यकता होगी:

1. ढांचे में एक बग (ये अतीत में अस्तित्व में है और फिर से अच्छा हो सकता है)
2. जेएनआई का उपयोग (अनिवार्य रूप से अब प्रबंधित कोड का उपयोग नहीं करता है)

एक बफर इस अर्थ में अतिप्रवाह है कि आपके पास एक बफर का उपयोग करके कोड है और आपका कोड इसे सही तरीके से पार्स करने के लिए जिम्मेदार है लेकिन ऐसा करने में विफल हो सकता है। उदाहरण के लिए, आप एक XML पार्सर लिख सकते हैं और कोई आपको एक विकृत (या वैध लेकिन असामान्य) अनुरोध प्रदान कर सकता है, जो आपके पार्सर के डिजाइन के कारण कुछ पेलोड के साथ पहले से मान्य डेटा को अधिलेखित कर देता है जो आपके एप्लिकेशन को बुरी तरह से व्यवहार करने का कारण होगा।

यह बाद का रूप कम होने की संभावना है, लेकिन एक खराब लिखित एसक्यूएल स्ट्रिंग क्लींजिंग फ़ंक्शन व्यापक रूप से वितरित किया गया था जिसमें एक समस्या थी जैसे कि यह एक आमंत्रित लक्ष्य होगा।

Answer 6

जावा (और। नेट) वर्चुअल मशीनें उस कोड को पकड़ती हैं जो आरक्षित मेमोरी के बाहर लिखने की कोशिश करता है। ऐसे एप्लिकेशन जो इसे सही ढंग से नहीं संभालते हैं, फिर भी सुरक्षा समस्याओं का कारण बन सकते हैं। यदि दुर्भावनापूर्ण उपयोगकर्ता अमान्य इनपुट दर्ज करके अपवादों को ट्रिगर कर सकते हैं तो वे उदाहरण के लिए सेवा हमलों से इनकार कर सकते हैं।

Answer 7

जैसा कि पहले ही बताया जा चुका है, जावा में एक भाषा के रूप में, सभी मेमोरी एक्सेस पर सीमा की जाँच है, और यदि यहां कोई त्रुटि है, तो जेवीएम गलती पर है और कार्यक्रम नहीं। हालांकि, क्या ध्यान दिया जाना चाहिए, जो जावा में मेमोरी लीक के लिए एक समान तर्क है; जबकि स्टैक को लूटना संभव नहीं है, गलत जगह पर एक ArrayOutOfBoundsException, जिसे सही तरीके से नहीं संभाला जाता है, फिर भी आपके सिस्टम को खराब कर सकता है।

Answer 8

यदि आप जावा मूल अंतर (JNI) सुविधा का उपयोग बाहरी कोड को लागू करने के लिए कर रहे हैं, और बाहरी कोड में एक शोषणकारी मुद्दा था, तो आप एक जावा प्रोग्राम में बफर ओवरफ्लो का कारण बन सकते हैं। यह काफी असामान्य है, क्योंकि अधिकांश एप्लिकेशन जेएनआई का उपयोग करने से बचते हैं।

Answer 9

यह एक विधि के लिए संभव है कि वह किसी ऐसी सरणी की वैध प्रविष्टियों में लिख सके, जो उसका इरादा नहीं था, आमतौर पर पूर्णांक अतिप्रवाह के माध्यम से।

उदाहरण के लिए निम्नलिखित सीमा की जाँच करने के लिए पर्याप्त नहीं है:

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

IIRC, StringBufferएक बार एक बग की तरह था, लेकिन कुछ भी दिलचस्प नहीं था जो आप इसके साथ कर सकते थे।

Comments

क्या है सीमा की जाँच करने के लिए पर्याप्त?

— ब्रुक

@ बरोम: 0 <= off && 0 <= len && off <= buff.length-lenमुझे लगता है। मुझे उद्धृत मत करो। यह समान दिखता है, लेकिन कोई संभावित अतिप्रवाह नहीं है (मूल बंद + लेन नकारात्मक हो सकता है और इसलिए स्पष्ट रूप से सरणी की लंबाई से छोटा है)। सुनिश्चित करें कि कोई भी रखरखाव प्रोग्रामर कभी भी इसे स्पष्ट रूप में "tidies" न करें। मुझे पूर्णांक ओवरफ्लो बड़े पैमाने पर भ्रामक लगता है। कुछ समय के लिए इसके बारे में सोचना है, और फिर इस बात पर संदेह है कि मुझे यह गलत लगा है। लेकिन निश्चित रूप से, एक और समीक्षक और मूल प्रोग्रामर होना चाहिए - साथ में कोई रास्ता नहीं है जिससे कोई त्रुटि हो सकती है! (नहीं)

— टॉम हैटिन -

मुझे यह थोड़ा घूरना था लेकिन आप सही हैं। ऑफ + लेन ओवरफ्लो और रैप कर सकता है ... सी। जावा में , जब तक मैं गलत नहीं हूं - आपको इससे पहले एक ओवरफ्लो अपवाद मिलेगा, है ना?

— ब्राम

नहीं। इंटेगर अंकगणित चुपचाप चारों ओर घूमता है। C # में एक "मोड" है, जहां एक अपवाद को अतिप्रवाह पर फेंक दिया जाता है, लेकिन मुझे नहीं लगता कि इसका उपयोग बहुत अधिक किया गया है (यदि आप इसका उपयोग करने के लिए सोचते हैं, तो आप शायद वैसे भी सही चीजें करने के लिए सोचेंगे)।

— टॉम हॉकिन -

Answer 10

JAVA की प्रमुख विशेषताओं में से एक सुरक्षा है। व्याख्या की गई भाषाओं में लिखे गए प्रोग्राम बफर अतिप्रवाह शोषण के लिए प्रवण नहीं होते हैं, लेकिन आप हमेशा इंटरप्रेटर में एक बफर अतिप्रवाह का कारण बन सकते हैं। हालांकि यह मुश्किल होगा। इसी तरह पायथन भी एक व्याख्या की गई भाषा है और बफर अतिप्रवाह से सुरक्षित है।